Outlook Assistant: why it is not safe to use
We found documented destructive email actions and local OAuth token storage, so we recommend caution and tighter deployment controls.
What we found
Our review did not find hidden instructions, hardcoded secrets, obfuscation, privilege escalation, or undisclosed network fetches in the inspected repo. The skill appears to communicate only with disclosed Microsoft OAuth and Microsoft Graph endpoints for the Outlook account a user connects.
The reason for a warning verdict is narrower. This skill supports destructive Outlook actions, including operations that could modify or remove mailbox content if used carelessly. The repository does document safeguards such as destructive annotations, dry-run support, recipient checks, rate limits, and allowlists, which is a positive sign. We also found that OAuth tokens are stored locally on the user’s machine at `~/.outlook-assistant-tokens.json`. We did not find evidence of broader credential harvesting, but local token storage can still matter on shared or weakly secured systems.
What to do instead
Use this skill only for accounts and environments where mailbox changes are expected and controlled. Prefer dry-run and allowlist features, limit granted Outlook permissions to the minimum needed, and secure the host where local tokens are stored. If you need lower operational risk, prefer a read-only mail integration or a workflow that requires explicit confirmation before destructive actions run.
Source: https://github.com/littlebearapps/outlook-assistant
We report what our security review found at the time we checked, with the goal of keeping people safe. Projects change; if a maintainer has since fixed this, we are glad to recheck it. Email hello@agentpod.com.