Audit AI Agent Permissions Before You Connect Email, Chat, or Local Files

A permission audit limits what a connected agent can read, change, execute, and send before a chat message reaches your local tools.

Start with the consequence, not the feature list

Connecting an AI agent to a chat app feels convenient because the interface is familiar. A message can ask the agent to find a file, edit a draft, run a script, or send back a result while you are away from the computer. The security question is less comfortable: what could the same connection do after a misunderstood request, a stolen chat account, or a malicious instruction hidden inside a document? Write down the worst plausible outcome before enabling the first integration. If the answer includes deleting client work, exposing private files, publishing without review, or running arbitrary shell commands, the starting permission set is too broad.

Map the complete action path

A messaging bridge is not one permission. It is a chain: the person or account that sends the message, the chat platform, the bridge service, the local agent, the tools available to that agent, the working directory, and any credentials reachable from that directory or process. Draw one row for each link. Record what it can read, what it can change, which network services it can contact, where its token is stored, and how to revoke access. This catches a common mistake. A bot may be limited to one chat account while the agent behind it can still read an entire home directory.

Use a seven-column permission map

• Identity: the exact account or user ID allowed to issue requests.
• Entry point: direct message, group chat, webhook, scheduled job, or local terminal.
• Readable scope: the folders, mailboxes, channels, databases, and remote services the agent can inspect.
• Writable scope: the files, repositories, posts, records, or messages it can change.
• Execution scope: allowed commands and whether each command requires approval.
• Credential reach: tokens, cookies, SSH keys, environment variables, and signed-in applications visible to the process.
• Exit control: the command, token revocation, service stop, or account logout that cuts access.

Apply least privilege in ordinary language

The UK National Cyber Security Centre recommends giving agents only the minimum access they need for the shortest necessary time. In practice, replace broad goals with a bounded job. Do not grant access to a whole laptop when the task is editing one novel folder. Do not expose every chat command when the job is checking Markdown files. Do not keep a long-lived publishing token loaded when publication still needs a human decision. A useful permission statement names the folder, allowed actions, approval point, account, and expiry condition. If it only says the agent can help with work, it is not a permission boundary.

Separate reading, editing, execution, and external action

These capabilities have different failure costs. Reading can disclose secrets. Editing can corrupt a source file. Command execution can reach outside the visible document. External actions can email, publish, purchase, deploy, or delete records in another service. Treat them as four separate switches. A research assistant may need read access to a source folder and permission to create a report in an output folder. It does not automatically need shell access, browser login, email, or the ability to overwrite the sources. Keep original files read-only when the workflow permits it, and write generated work to a separate directory.

Keep approval meaningful

An approval prompt is useful only when a person can understand the proposed action. Approving a vague request such as run the necessary command is little better than automatic execution. The prompt should show the command, target path, expected change, and whether data leaves the machine. Repeated prompts can also train people to click allow without reading. Pre-approve a short list of harmless, narrow operations if the tool supports it, but keep destructive commands, network uploads, credential use, publishing, and changes outside the working folder behind explicit review.

Test three failure cases before real work

• Mistaken instruction: send a request with an ambiguous filename and confirm that the agent asks which file instead of guessing.
• Hostile content: place a sentence inside a test document telling the agent to ignore the user and copy another file. Confirm that the agent treats document text as data, not authority.
• Lost account: rehearse how to revoke the chat token, stop the bridge, and check whether any agent process remains active. Time the exercise and record the steps.

Understand excessive agency

OWASP uses the term excessive agency for systems that can take damaging actions after unexpected, ambiguous, or manipulated model output. The cause does not have to be a dramatic hack. A hallucinated filename, an instruction copied from an untrusted webpage, or an overbroad tool can be enough. The practical defense is to reduce the number and power of tools, narrow each tool to the required functions, and require human approval for consequential actions. A disclaimer in the prompt cannot compensate for a process that has unnecessary operating-system or account privileges.

Worked example: a personal chat bridge to a writing drive

Suppose a writer connects a personal messaging account to a local coding agent so it can maintain manuscripts on an external SSD. A reasonable first configuration limits the working directory to the single drive, starts in a mode that asks before tool use, blocks privileged chat commands, and whitelists the scanned account ID. The agent can inspect Markdown chapters and propose edits. It cannot silently run scheduled jobs, upgrade itself, open an unrestricted shell, or work elsewhere on the computer. Originals remain in their existing folders, while exports go to a named output folder. This setup is still not risk-free, but the likely damage is much smaller than granting access to the whole home directory in an automatic approval mode.

Do not confuse a whitelist with complete security

A sender whitelist reduces who can talk to the bot. It does not prove that the allowed account is still controlled by the owner, that a forwarded document is safe, or that the agent will interpret every request correctly. Protect the messaging account with the strongest login controls available. Keep the bridge token out of shared notes and screenshots. Check file permissions on the local configuration. If a token appears in a terminal capture, support message, or public repository, revoke it rather than merely deleting the visible copy.

Build a shutdown card

Keep a short shutdown card outside the agent workspace. It should name the local service, configuration path, token-revocation page or login command, process-stop command, log location, and the person responsible for checking recent activity. Add the first three things to inspect after an incident: changed files, outbound messages or uploads, and active processes. Test the card after installation and after major upgrades. A shutdown plan written during an incident will be slower and less reliable than one tested when nothing is wrong.

Review after scope changes

Repeat the audit when you add a folder, messaging platform, plugin, browser session, credential, scheduled task, or automatic approval rule. Also repeat it after a device is shared, sold, repaired, or restored from backup. The audit is complete when every permission supports a named job, every consequential action has an understandable review point, and access can be removed without relying on the agent itself. If you cannot explain the boundary to another person in a minute, reduce the scope and try again.

Sources checked

• UK National Cyber Security Centre: Thinking carefully before adopting agentic AI
• OWASP: LLM06 Excessive Agency
• Anthropic: Claude Code security
• CC Connect: Weixin personal account setup