How much access should an AI agent have?
An agent should get only the access its current task needs, for only as long as the task runs, and that rule matters most once it can read your email, browse the web, and spend your money.
An AI agent should have access to exactly what its current task needs, for only as long as the task runs, under an identity that is not yours, with a human approving anything that cannot be undone. This is the same least-privilege rule security teams have applied to software for decades, and agents need it more than most software because they decide their own next step.
- An AI agent should get the minimum access its current task requires, for the shortest time the task needs, and lose that access automatically when the task ends.
- Agents are riskier than ordinary apps because they chain actions across systems and read untrusted content, and OWASP lists prompt injection as the top risk for applications built on language models.
- Instructions in a prompt are not a permission system, and Microsoft's security team warns that relying on prompts instead of hard authorization boundaries invites prompt injection and workflow drift.
- Irreversible actions such as payments, deletions, sending messages, and accepting terms should require explicit human approval every time.
- Permissions hold best when they are enforced by the system underneath the agent rather than by the agent's own judgment.
The short answer
Give an agent its own identity, the smallest set of permissions that lets it finish the task, and an expiry on anything elevated. Require your approval for actions you cannot take back. Log everything it does so you can answer what happened and under whose authority.
In demos and early setups, agents are often given the owner's logged-in browser, main email account, and a saved card, because that is the fastest way to get something working. Microsoft's security team describes the same pattern inside companies. An agent gets a broad role because the first use case looks harmless, the workflow grows, access grows with it, and nobody goes back to tighten it.
Why an agent is riskier than an app
A normal app does what its code says. An agent decides what to do next based on what it reads, and it often reads content written by people you have never met: web pages, inbound email, shared documents, search results. If any of that content contains instructions, the agent may follow them.
OWASP calls this prompt injection and ranks it first on its list of risks for language model applications. The indirect version is the one that matters for agents, where instructions hidden in a website or file get processed as part of the task. OWASP lists the possible results plainly, including disclosure of sensitive information, unauthorized access to functions available to the model, and executing arbitrary commands in connected systems.
The second risk is combination. Microsoft points out that an agent with access to email, files, a ticketing system, and a code repository may look low risk at each integration while the combination lets it take actions nobody authorized as a whole. Every permission you add widens what a single bad instruction can reach.
Telling it not to is not a control
The most common safety measure is a sentence in the system prompt telling the agent never to send email without asking, never to delete files, and never to spend money. Those instructions help the model behave. They cannot stop it, because the same channel that carries your rules also carries every web page and document the agent reads.
OWASP and Microsoft land in the same place. OWASP says to handle privileged functions in code instead of handing them to the model, and to restrict the model's access to the minimum necessary. Microsoft warns that relying on prompts instead of hard authorization boundaries invites prompt injection and workflow drift. An instruction in the prompt can be overridden by other text in the same prompt, so it does not restrict what the agent can do.
Rules that hold
Here is what we would insist on before giving any agent real access. Each rule is enforced outside the agent's own reasoning.
- The agent gets its own accounts and credentials, never your personal login, so its actions are attributable and its access can be revoked without locking you out.
- Permissions are scoped to the task, such as read access to one inbox label instead of the whole mailbox, and elevated access expires when the task ends.
- Anything irreversible needs a person to approve it at the moment it happens. Anthropic's computer use guidance names financial transactions and agreeing to terms of service as examples.
- The agent runs in an isolated environment with network access limited to the sites the task requires.
- Every action is logged with what was done, under which permission, and what changed, and you have tested that you can shut the agent off quickly.
An agent held to these rules can still do most useful work, and you can leave it running without watching it, which is the reason to have one.
Where permissions should live
Look at where each rule is enforced today. Identity lives with an identity provider, scopes live in each app's settings, approvals live in whatever chat tool the agent happens to use, and logs are scattered across all of them. The agent sits on top, and every integration trusts it a little.
On a regular computer, the operating system is the layer that decides who is logged in, what each program may reach, and what gets recorded. That is where an agent's authority belongs too. It is why we build ERIKA as an operating system: accounts, credentials, and permissions live inside a governed system boundary instead of in loose prompt text, and actions leave records that can be inspected or rolled back. The longer version is in why ERIKA is an operating system, not an app.
If you are running a computer use agent today, you can apply every rule above with the tools you have. It takes more work than it should, because the computer underneath was built to trust whoever is sitting at the keyboard.