AI AGENTS • PERMISSIONS • MONEY
AI Agent Permissions: What Should an Agent Be Allowed To Do?
An AI agent becomes dangerous or useful partly through the permissions around it. Reading a calendar is not the same as editing it. Drafting an email is not the same as sending it. Comparing prices is not the same as paying. The permission model should make those differences explicit.
Start with read, write and irreversible actions
A useful first split is read-only versus write access. Reading a file, calendar or account can expose private information, but writing changes state. Sending a message, deleting a record, changing permissions or paying money adds consequences that may affect other people or be difficult to reverse.
Do not bundle those rights together simply because the same app supports them. An agent that needs to summarise email usually does not need permission to delete every message. An agent that prepares a payment does not automatically need permission to authorise it.
Least privilege means enough access for the task and no more
Security guidance uses the principle of least privilege because broad credentials increase the blast radius of a mistake or compromise. The NCSC specifically warns against unrestricted access to sensitive data and critical systems and recommends keeping agent scope tightly bounded.
For personal use, that can mean giving access to one folder rather than the whole drive, one calendar rather than every account, or one payment method with a low limit rather than the primary bank account.
Credentials are authority, not just technical plumbing
API keys, OAuth tokens, authenticated browser sessions and stored passwords can let an agent act as the user. If those credentials carry broad rights, the agent inherits them. Security problems therefore arise even when the model itself never 'knows' the password in plain text.
Use separate identities for agents where services support them. Prefer short-lived tokens and narrowly scoped grants. Revoke access when a project ends instead of leaving an old agent connected indefinitely.
High-impact actions need approval gates
OWASP guidance recommends explicit authorisation for sensitive operations. A practical rule is to require confirmation before actions that are financial, destructive, externally visible or difficult to undo. Paying, publishing, sending, deleting, granting access and changing security settings all belong in that category.
Approval should show the human what is about to happen in concrete terms: recipient, amount, file, merchant, message or permission change. 'Approve agent action' is too vague to be meaningful.
Sandboxing controls where an agent can act
The NCSC recommends controlling the agent's environment and restricting network, compute, credentials and data access. A sandbox makes the boundary technical rather than relying on the model to remember instructions about what it should not touch.
For higher-risk tasks, allowlists can restrict which domains or APIs the agent can reach. Separate workspaces can keep personal and business information apart. The goal is to make forbidden actions impossible or difficult even if the model is manipulated.
Logs make mistakes investigable
If an agent can change real systems, keep a record of what tool it called, which identity it used, what data it accessed and what result came back. Without an audit trail, a user may know something went wrong but have no way to reconstruct the sequence.
Logging is especially important in multi-step workflows because the final action may be caused by an error several steps earlier. Good logs make rollback, incident response and improvement possible.
A stop button must actually stop the authority
Telling an agent 'stop' in chat is not the same as revoking the credentials it is using. A robust design needs a control that prevents new actions at the tool or platform layer. That may mean disabling the worker, revoking a token, pausing a queue or blocking network access.
For household users, know where connected-app permissions can be removed and where payment authority can be disabled. Emergency control should not depend on winning an argument with the model.
Review permissions like you would review direct debits
Access that made sense three months ago may no longer be needed. Periodically check which agents and apps can see email, cloud storage, calendars, contacts, payment details or business systems. Remove dormant connections and reduce rights that are broader than the current task.
The safest agent setup is not a one-time configuration. It is a maintained list of delegated authority, with the same discipline people apply to financial mandates, account access and shared keys.
Continue from here
Evidence baseline
- UK NCSC — Thinking carefully before adopting agentic AI
- OWASP — AI Agent Security Cheat Sheet
- Google Developers — Agent protocols and payment authorisation
The UK NCSC, NIST and OWASP all emphasise least privilege, bounded access, human oversight and strong control of credentials for agentic systems.
Permission should be specific to the object as well as the action
It is not enough to say an agent may 'edit files'. Which files matters. A safer permission might allow edits only inside one project folder, only to documents the agent created, or only after producing a preview. The same principle applies to calendars, contacts, cloud systems and administrative tools.
Narrow object scope stops a legitimate tool from becoming a route into unrelated data. It also makes mistakes easier to recover because the agent cannot silently modify everything reachable by the user's account.
Time limits reduce forgotten authority
Permissions can expire automatically after a task or work session. Short-lived credentials and temporary grants are valuable because users routinely forget to revoke access after the original need disappears.
For high-impact tools, combine time limits with explicit re-authorisation. That forces a fresh decision before an old agent regains the ability to pay, publish, delete or change security settings months later.
Use different approval rules for different action classes
Reading a status page, drafting a message, sending it, deleting records and moving money should not share one blanket approval setting. Group actions by consequence and set stricter controls as reversibility falls. A read-only lookup may run automatically, while publishing, deleting, changing account access or paying a new recipient should stop for explicit confirmation.
This keeps everyday automation useful without letting a low-risk permission quietly become authority over high-impact actions.