Write the Mandate: A One-Page Template for Delegating Authority to an Agent

The inventory tells you what is running. The mandate tells each thing on it what it may do. Most organizations have an implicit version of the second document already — it lives in the permissions of whatever account the agent runs under, which is another way of saying the agent inherits the authority of the last person who configured it. The mandate is the act of making that authority explicit, bounded, and time-limited, on a page a CFO, a CISO, and a vendor can all sign.

Finance has written mandates for centuries: powers of attorney, discretionary trading authority, investment policy statements, delegation-of-authority matrices. None of those documents was long. The discipline was never in the length; it was in forcing the grantor to answer a short list of uncomfortable questions before the money moved. That is exactly what an agent mandate does, and it is why it fits on one page.

Download the template: Agent Mandate — One-Page Template (PDF). Twelve fields, one signature block, no software required.

The twelve fields

1. Agent identity. Name, vendor or building team, version, and the credential it runs under. A named service identity, never a shared human login — if it runs as a person, the mandate is a fiction.

2. Owner. The human accountable for the agent’s continued use. Owners are people, not teams, because a review needs someone who can say yes, no, or stop.

3. Purpose and outcome. What the agent is for, stated as an outcome with a baseline — the ticket resolved within policy, the invoice posted correctly — so the mandate ties to the value conversation and the pricing conversation that follows it.

4. Permitted actions. The verbs, explicitly: read, draft, send, file, approve, pay, provision. Everything not listed is prohibited. Coarse verbs are the failure mode — “manage the inbox” is not a permission, “draft replies for human send” is.

5. Data reach. Which systems and which classes of data the agent may read and change, down to the data element where the stakes justify it. This is the field that turns a modest assistant into a material risk when it is left blank.

6. Counterparties. Who or what the agent may transact with — merchants, vendors, internal systems, other agents. A closed list, extended by amendment, not by discovery.

7. Limits. Per-action cap, aggregate cap, velocity, and time window, written together. A per-action cap alone is a loophole at machine speed; the aggregate and the rate are what make the ceiling real.

8. Autonomy level. Suggests, drafts, acts with approval, acts alone — one word that determines how much verification the agent’s output needs, and therefore how much it costs to run responsibly.

9. Escalation. The thresholds that route a decision to a human, and which human. Amount, confidence, novelty, and counterparty class are the usual triggers.

10. Revocation semantics. What happens to work already in flight when the mandate is withdrawn. The default is fail safe — the transaction stops — and the exceptions are written here, not improvised during an incident. Real-time access without real-time revocation is a blast radius, not a control.

11. Evidence. Where the record of each decision lives — what mandate applied, what matched, what was released — and how long it is kept. Captured at the moment of the action, not reconstructed afterward. That evidence layer is the half of this I’ve been working on in the open, in a proposed OCSF extension for recording authorization decisions at the data element.

12. Approval and expiry. Who approved the mandate, on what date, against what system state, when it expires, and the material changes — new model, new data source, wider scope, more autonomy, a vendor incident — that force reassessment before then.

Three rules that keep the page honest

Write the aggregate before the cap. Operators reach for the per-transaction limit because it feels like control. Agents live in the aggregate. Start there.

Write revocation before the wallet. If you cannot describe what stops when authority ends, you have not finished designing the authority. This matters most where the agent moves money — the subject of the fifth essay.

Separate identity from authority. The credential says who; the mandate says what. Rotate and revoke them independently, and never let the first imply the second.

How the page gets used

Three places, and it earns its keep in all of them. Procurement: no AI contract closes without a mandate attached, which quietly ends the era of buying capability without buying its limits. The inventory: every row links to its mandate, so the list you built last month becomes the index to the authority you have actually granted. Review: reassessment happens by trigger, with the quarterly attestation as the backstop — and the mandate is the document the reviewer signs, or refuses to.

For vendors, the mandate is the other half of outcome pricing: you cannot invoice an outcome you were not authorized to produce, and a customer who can hand you a mandate is a customer who can sign an outcome-based contract.

What to do now

Write one this week. Pick the agent with the widest data reach on your inventory. Fill the twelve fields. The blanks are the findings.

Attach it to procurement. Make the template a required exhibit on every AI purchase from here on.

Link every inventory row to a mandate. A row without one is a row running on inherited authority.

Rehearse revocation once. Withdraw a mandate on a low-stakes agent and watch what stops. Fix what didn’t.

Put the evidence field first in every review. A mandate with no record of what the agent actually did is a promise, not a control.

This is the second piece in the Operator Edition of Field Notes on the Agentic Enterprise. Previous: The Agent Inventory. Next: “The Three Measures: An AI ROI Scorecard That Survives the J-Curve.”