An AI agent’s boundaries are not written in the prompt. They are written in the permission model. The practical rule Meta published in November 2025, the Agents Rule of Two, states that an agent should satisfy at most two of three properties: processing untrusted input, accessing sensitive data, and changing state or communicating externally. An agent that satisfies all three can be turned into a data-exfiltration tool by a single piece of injected text. A working permission model operates in four layers — identity, tool, argument and budget — and marks irreversible actions for human approval in advance.
Why a prompt is not a security control
The most common instruction we find in projects we inherit reads something like: do not delete customers, do not send email without approval, do not expose internal information. That sentence sits in the system prompt and feels like protection. It is not.
A prompt is a statistical suggestion, not a permission. It competes for the model’s attention against every other piece of text in the context — including text that arrived from outside. The moment the agent reads an email, a web page, a customer-uploaded file or a tool result, that text sits in the same space as your instructions. This is the whole idea behind prompt injection, and it is why you cannot phrase your way out of the problem.
The correct separation is simple: the prompt defines intent, the permission model defines capability. What the agent cannot technically do, it will not do — no matter how convincingly it is persuaded that it should.
Quick test: if your only defence against a destructive action is a sentence in a prompt, you do not have a defence. You have a polite request.
The Rule of Two: the most practical framework published so far
On 1 November 2025 Meta published an unusually simple framework for designing safer agents. It identifies three properties and holds that an agent in a single session should satisfy at most two of them.
| Property | What it means | Typical example |
|---|---|---|
| A. Untrusted input | The agent reads content someone else controls | Inbound email, forms, web pages, uploaded documents |
| B. Access to sensitive data | The agent can read private data or internal systems | CRM, payroll, internal knowledge base, mailbox |
| C. State change or external communication | The agent can write, send or publish | Sending email, calling an external API, updating a record, charging |
The danger lives in the combination of all three. An agent that reads an inbound email (A), pulls customer data from the CRM (B) and can send email out (C) becomes an exfiltration machine the moment someone sends it a message with a hidden instruction. The attacker does not need to break anything; they need to write text.
Meta itself stresses that the rule is not a finish line. It does not protect against agent mistakes, against injections that merely produce misinformation in the response, or against over-broad permissions inside the two axes you kept. It is a tool for reducing the worst-case scenario, not a substitute for defence in depth.
How to break the combination in practice
In most cases you do not have to give up capability; you have to split it across two agents or two stages. These are the three patterns that work.
| Pattern | What gets split | When to use it |
|---|---|---|
| Reader and executor | One agent reads untrusted input and returns only a structured summary; a second agent acts on that summary against real systems | Email processing, forms, customer documents |
| Human signature | The agent satisfies all three properties but the C action passes through human approval | When the process genuinely cannot be split |
| Closed output channel | The agent can only write to destinations on a fixed allowlist | Internal reporting, record updates, draft generation |
The second pattern is the most common, and it is also the one that decays: approval that becomes a reflex stops being a control. Where exactly to place the approval point, and how to keep it meaningful, is covered in our human-in-the-loop guide.
A permission model in four layers
Agent permission is not a binary question of system access. It is built in four layers, and every layer you skip opens an entire class of failures.
| Layer | The question it answers | What happens when it is missing |
|---|---|---|
| Identity | On whose behalf the agent acts | Actions attributed to an anonymous service account; no audit trail, no reconstruction |
| Tool | Which actions exist for it at all | The agent discovers capability it was never designed to have, such as deletion through a generic update tool |
| Argument | What it may run that action against | Right tool, wrong scope — an update applied to every record instead of one |
| Budget | How much, how fast, and until when | A loop that runs hundreds of steps or thousands of calls before anyone notices |
The argument layer is the one most often forgotten, and the one that causes most of the real damage. An agent granted permission to update an order status with no scope limit can update every order. The simple rule: every writing tool validates its arguments server-side, not in instructions to the model.
Prompt injection and tool misuse: what has already happened
In December 2025 OWASP published its Top 10 risks for agentic applications. The risk labelled ASI02, Tool Misuse and Exploitation, describes exactly the case where an agent uses an authorised tool destructively — and the mitigation it recommends is granular permissions and strict validation of arguments before execution. This is not a theoretical recommendation.
A concrete example: CVE-2025-59528 in Flowise, a low-code platform for building agentic applications, stemmed from unsafe handling of CustomMCP configuration data and allowed injection and execution of arbitrary JavaScript. The vulnerability was not in the model. It was in the layer between the model and the tools — precisely the place most teams treat as plumbing.
The specification itself is moving in the same direction: the stable revision of Model Context Protocol dated 28 July 2026 lists authorization hardening as one of its headline changes, alongside the move to a stateless protocol. Anyone building a tool layer today starts from a better baseline than a year ago, but the baseline is not a substitute for your own decisions.
What an agent never does alone
The following list is industry-independent. These are actions where the cost of a mistake exceeds the cost of friction.
- Moving money. Charging, crediting, refunding, changing payment terms.
- Communicating externally on behalf of the company. Customer email, messages, publishing — drafting yes, sending no.
- Deletion or any irreversible action. Anything without an undo button.
- Changing permissions. An agent that can widen its own permissions is not an agent, it is a hole.
- Acting at wide scope. Bulk updates, database exports, system configuration changes.
- Decisions with legal or regulatory consequence. Denying a claim, classifying an employee, quoting a binding price.
What an agent is allowed to read is a separate and equally important question — the classification of information you may feed into a model is covered in our enterprise data classification guide.
What it looks like when it is done right
A good permission model is boring. It looks like a table: every tool has an owner, a risk level, an allowed argument range, a daily call ceiling, and a flag for whether it requires approval. That table is written before the first prompt and reviewed on every change.
Three tests worth running on any agent before production: attempt to inject an instruction through every untrusted input channel and confirm it never reaches a writing tool; run every writing tool with an out-of-range argument and confirm it is rejected server-side; and run the agent against an impossible goal and confirm it stops at the budget ceiling rather than continuing. The full method for these tests is in our evals guide, and the structure everything sits on is explained in Anatomy of a Business AI Agent.
Frequently asked questions
What is Meta’s Rule of Two?
A security framework published by Meta in November 2025 holding that an agent in a single session should satisfy at most two of three properties: processing untrusted input, accessing sensitive data, and the ability to change state or communicate externally. Combining all three turns a single prompt injection into a data leak.
Can prompt injection be prevented entirely?
Not with the methods available today. Any text that enters the context competes for the model’s attention, including text from external sources. The defence is therefore not prevention but damage limitation: minimal permissions, separation between reading input and performing actions, and human approval for irreversible steps.
What is the difference between user permissions and agent permissions?
User permissions are checked once at login and assume human judgement throughout the session. Agent permissions must be checked on every call, at the tool level and at the argument level, because there is no human judgement between steps. In practice that means server-side validation rather than reliance on instructions to the model.
How do you restrict an agent without making it useless?
Split rather than block. A reader agent that returns a structured summary, plus an executor agent that acts only on that summary, preserves the full business capability while eliminating the dangerous combination. Where splitting is impossible, add an approval point on the outbound action only.
Who should own the permission model?
Whoever carries the consequences if a wrong action goes out — usually the business process owner, not the development team. The technical team implements it, but deciding which actions are irreversible and which require approval is a business decision.
Continue reading
Running MCP in the Enterprise: Gateways, Least Privilege and 200,000 Exposed Servers – Where permission boundaries are actually enforced once the agent talks to real tools.
The EU AI Act Timeline Moved. The Deadline That Matters Did Not. – What the regulator expects you to disclose, and by when.