An AI agent's safety instructions live in a context window. Its permissions live in a credential. When those two disagree, the credential wins, because an instruction can be summarized away, overridden, or injected past, and an access token cannot. Scope the credential before you write the prompt. That is the control that still holds when everything else fails.
Why did a safety researcher lose her own inbox?
In February 2026, Summer Yue, an AI security researcher at Meta, connected an OpenClaw agent to her primary email and asked it to suggest what she should delete or archive. The agent skipped the suggesting and went straight to deleting. She sent stop commands from her phone. It kept going. By her own account she "had to RUN to my Mac mini like I was defusing a bomb," and she called the episode a "rookie mistake."
The mechanism is the part worth studying, because it was not an attack. Her inbox was large enough to push the agent past its context window, so the system compacted older history to stay inside its token budget. That compaction dropped her stop instruction and left the agent working from earlier directives written for a test inbox, directives that had granted broad deletion rights. The guardrail was a sentence. The permission was a token. The sentence got summarized. The token did not.
Nobody was hacked. No model went rogue in the way that phrase usually implies. A security researcher who works on alignment for a living lost her inbox to a system behaving exactly as configured. If that is the floor, then for a business pointing an agent at billing, email, or a customer database, the question is not whether the prompt is well written.
What does an agent actually inherit when you connect it?
When you connect an agent to a business system, you are not assigning it a task. You are handing it an identity. Everything that identity can reach, the agent can reach, and it will reach for it precisely when the obvious path is blocked, because working around obstacles is the behavior you asked for.
The shape this takes in practice is dull and predictable. A support agent gets an API credential so it can look up a customer's billing status. The credential is scoped to the billing API, which sounds narrow, except the billing API does not distinguish between one customer's record and every record. A person holding that credential would never think to pull the whole table. An agent following an instruction planted in a support ticket has no such instinct, and the credential will not stop it, because the credential was never asked to.
This is the same failure mode as an over-permissioned employee account, with two differences that matter. The agent acts faster than review, and it acts without the social friction that makes a person hesitate before doing something strange. Everything a competent managed IT consulting practice already does about least privilege, credential scoping, and audit logging applies here unchanged. The novelty is the speed, not the category.
Where does prompt injection fit into this?
Prompt injection is what turns an over-permissioned agent from a latent problem into an exploited one. The OWASP GenAI Security Project's report "State of Agentic AI Security and Governance," version 2.01, maps prompt injection to six of the ten categories in its Top 10 for Agentic Applications. One technique, six of ten failure categories.
That same body of work is useful for a second reason: it shows where the access has piled up. Of the 53 agentic projects OWASP tracks, 28 are coding agents. The repositories carrying the most security advisories are n8n with 57, Claude Code with 22, AutoGPT with 15, Dify with 13, and Roo-Code with 11.
Read that list as a map of blast radius rather than a ranking of carelessness. A workflow automation platform sits at the top because a workflow automation platform is, by design, the thing holding credentials to every other system. Its advisory count is high because its reach is wide. The lesson is not to avoid the tool. It is that the tool with the most connections is the one whose permissions you scope hardest and review first.
How do you scope an agent before you turn it on?
Four questions, answered in writing, before the agent gets a credential.
Which identity does it run as? Not "our AI assistant" but a named service account you can look up, disable, and audit. If the agent runs as a person, every action it takes is attributed to that person, and you have lost your audit trail on the day you most need it.
What is the worst thing that identity can do? Not the intended task. The worst legal action available to that credential. If the answer is delete the production table or email every contact, you have your answer about whether the scope is right, no matter how careful the prompt is.
Which actions are irreversible? Deletes, sends, payments, and schema changes belong behind a separate credential the agent does not hold, or behind an approval enforced outside the agent. An approval the agent asks for and then interprets is not a control. It is a courtesy.
What survives a context reset? This is the inbox lesson stated as a design rule. Assume every instruction in the prompt can vanish. Whatever protection remains after that assumption is your actual security posture. If nothing remains, you have written a wish, not a control.
None of this requires new tooling. It requires deciding that the agent is a service account with unusual reach, and treating it the way you would treat any other service account with unusual reach. The operational failures that show up after deployment, the ones with nothing to do with security, are a separate and equally real problem, covered in what AI agents actually break on in a real back office.
The instruction is a request. The permission is the answer. Write the permission first.