An agent permission manifest is a document signed by someone with authority. It lists everything one agent may do. Which systems it may touch. Which actions it may take. How much it may spend or commit alone. Which cases go to which named person. A component the agent cannot edit reads it before every action. Anything it does not name is refused.
In one sentence: your agent's job description, written so a machine can enforce it and your auditor can read it.
Where it comes from
Phones solved this for apps. On Android, an app declares the permissions it needs. The system guards "restricted data, such as system state and users' contact information" and "restricted actions, such as connecting to a paired device and recording audio"1. Install-time permissions appear in the app store before you install. Runtime permissions, "also known as dangerous permissions", need a prompt at the moment of use1. The docs are blunt: "Don't assume that these permissions have been previously granted"1. Instead, "check them and, if needed, request them before each access"1.
That is the model. Declare up front. Show the human before they commit. Check at the moment of use. Treat the dangerous ones differently.
Least privilege is the older principle underneath. NIST's AC-6 control allows "only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks"4. An agent is a process acting for users. The manifest is where you write down what "necessary" means for it.
What it actually is
A usable manifest has five sections. The names are ours. The shape is what matters.
| Section | Question it answers | Example (illustrative, AP) |
|---|---|---|
| Scope | Which systems and data may it touch? | The ERP's AP module, the PO table, the supplier master (read only), the AP mailbox |
| Role | As whom does it act? | Its own service identity, not a person's login |
| Limits | What may it do alone, and how much? | Payments up to 250.00 to suppliers known 90+ days. Up to 40 a day. A cap on model spend per run |
| Review | Which cases wait, and for whom? | Over the limit, or bank details first seen within 30 days: hold for the AP lead, cover the controller, 4 business hours |
| Seal | What does each run leave behind? | A record naming the manifest version, the facts, the decision, the approver |
Two things make this a manifest rather than a policy document.
Default deny. It lists what is allowed. It never tries to list what is forbidden, because that list is endless. Changing supplier bank details is in neither Limits nor Review. So the request is refused, whoever asks, and the refusal is recorded. OWASP gives the failure this prevents. A developer grants read access to documents, and the extension they picked "also includes the ability to modify and delete documents"3. A default-deny manifest never granted the delete.
Enforcement outside the model. The control plane reads the manifest, not the agent. The agent proposes an action. The control plane compares it with the file. A cleverly worded invoice can persuade the agent. It cannot persuade the comparison.
A manifest versus a capability file
The word "manifest" now covers two different documents. The difference matters when a vendor shows you one.
Microsoft's Security Copilot agents use a manifest with three top-level keys: Descriptor, AgentDefinitions and SkillGroups. It "defines metadata about the tool set (plugin) and specifies how each tool should be invoked"2. That is a capability file. It tells the platform what the agent can do.
A permission manifest says what the agent may do. It also says what happens when it tries something else. The builder writes the first. The person accountable for the process signs the second. You want both. Know which one you are reading.
What it is good at, and what it is not
Good at. Making authority explicit before go-live. Your conversation with risk happens over a document, not a demo. It survives change: swap the model and the manifest still holds. It answers your auditor's first question, "what was it allowed to do?", with a versioned file instead of a meeting.
Not good at. Judging the case. It can say hold anything over 250.00. It cannot say whether this 2,400.00 is right. That is your approver's job. Nor does it save you from a limit set too high. Allow 9,999 per payment and it will allow four hundred of them.
A common mistake. Writing it per agent, not per action. "The AP agent needs approval above 10,000" skips reading, matching, emailing suppliers and scheduling. Each carries a different risk. Write one row per action. The approval policy page shows the table.
What to check
- /01
Is it default deny? Ask what happens when the agent requests something not in the file. You want "refused and recorded". Not "the prompt tells it not to".
- /02
Who signs it, and who can change it? The person accountable for the process. Changes need a second name.
- /03
Is it versioned? Does every run record the version in force?
- /04
Does the Role name its own identity? An agent on a borrowed login makes the record lie about who acted.
- /05
Do the Limits cover both kinds of money? What the run costs, and what it commits you to.
- /06
Does Review name a person, a cover and a time limit? Or just a channel?
Meta's Rule of Two is a good sanity test for Scope and Limits together. It names three properties: the agent "can process untrustworthy inputs", "can have access to sensitive systems or private data", and "can change state or communicate externally"5. Meta argues an agent should hold no more than two in one session. One that needs all three "at a minimum requires supervision"5.
Your AP agent reads invoices (untrusted), reads the ERP (sensitive) and schedules payments (changes state). All three. Review is where that supervision gets written down.
Where it is going
Our view: manifests become a procurement document. Today your buyer asks for a security questionnaire and a SOC 2 report. Within two years we expect a third request: the manifest for each agent. Internal audit reviews it before go-live. It is re-signed whenever it changes. The vendors who win will hand you a file you can read, not a settings page you can screenshot.
Gatehouse fit
In Gatehouse the manifest is the rules. One signed document per deployment, versioned like code. The five sections above are its five gates: scope, role, limits, review, seal. The policy engine reads it before each action. Anything it does not name is refused and recorded. Every record carries the version in force. The Gatehouse page shows a simulated manifest and the run it governed.
At a glance
| Category | Controls |
|---|---|
| Also called | Scope manifest, agent policy, permission file |
| Borrowed from | Mobile app permission manifests. Least privilege (NIST AC-6) |
| Key standards or docs | NIST SP 800-53 AC-6. OWASP LLM06:2025. Android permissions overview |
| Typical owner | The process owner writes it. Risk or internal audit reviews. A second name co-signs changes |
| The one test | What happens when the agent asks for something not in the file? |
Sources
- [1]Permissions on Android, Android Developersdeveloper.android.com In text
- [2]Agent manifest, Microsoft Security Copilot developer docslearn.microsoft.com In text
- [3]LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applicationsgenai.owasp.org In text
- [4]NIST SP 800-53 Rev. 5, AC-6 Least Privilege (PDF), September 2020nvlpubs.nist.gov In text
- [5]Agents Rule of Two: A Practical Approach to AI Agent Security, Meta, 31 October 2025ai.meta.com In text
Read next
What is an agent control plane?
An agent control plane checks every action an AI agent wants to take against your rules before it runs, holds the hard ones for a named person, and records the result.
Least privilege for AI agents: how to scope what an agent can touch
Most agents run on a borrowed login with far more access than the job needs. Scope them by action, not by system, and enforce it outside the model.
What is an agent approval policy?
An approval policy decides which agent actions go ahead, which wait for a person, and which never happen. Most teams have a paragraph. You need a table.
