What a Mission Contract is — and why it matters
A Mission Contract is a structured governance document that defines the authorised scope of an AI agent's operation. It is not a technical configuration file. It is a governance record that expresses human decisions about purpose, boundaries, and accountability in a form that can be evaluated, audited, and updated.
The Mission Contract matters for three reasons. First, it makes the governance design explicit: an agent that has no Mission Contract operates without a defined scope, which means no one has decided what it is not allowed to do. Second, it creates a baseline for policy evaluation: when the agent takes an action, that action can be checked against the contract. Third, it creates an accountability record: when something goes wrong, the Mission Contract shows what the agent was authorised to do and who authorised it.
Regulatory basis
The concept draws on the EU AI Act's requirements for technical documentation (Article 11) and post-market monitoring (Article 72), and on the GOVERN function of the NIST AI Risk Management Framework. None of these frameworks use the phrase "Mission Contract" — this is a practitioner framework that synthesises their requirements into an operational document.
The 8 required fields
Every Mission Contract must contain these eight fields. A contract missing any of them is incomplete — the missing field represents a governance gap that cannot be compensated for by the other seven.
Field 01
Agent identity
The agent's name, version, provider, deployment environment, and a unique identifier. If the agent has multiple instances, each instance should have its own identity record to enable accurate incident attribution.
Field 02
Purpose statement
A plain-language statement of what the agent is for. Must be specific enough that a policy engine can determine whether a given action is within it. "Process invoices under €5,000 for confirmed suppliers" is a purpose statement. "Help with finance tasks" is not.
Field 03
Allowed capabilities
An exhaustive list of action types the agent is authorised to perform: read, write, execute, email, API calls, database queries. Each capability should name the specific scope — not "database access" but "read from invoices table, write to payments_draft table."
Field 04
Prohibited actions
An exhaustive list of actions the agent is explicitly prohibited from performing, regardless of instruction. Prohibitions should be stated in terms of specific action types and resources — not general principles. "May not modify payments_final" is a prohibition. "Must act ethically" is not.
Field 05
Autonomy level
The autonomy level (A1–A5) assigned to each action type, and the conditions under which the agent must escalate to a human. Where the EU AI Act or other regulation constrains the autonomy level, this must be noted in the contract.
Field 06
Human sponsor
The name, role, and contact details of the named human who is accountable for the agent's operation. Not a team or a department — a specific person who can be reached when something goes wrong, including outside business hours.
Field 07
Approval thresholds
The specific thresholds above which human approval is required before the agent can proceed. Financial thresholds, volume thresholds, risk thresholds. These must be testable — the policy engine must be able to evaluate a pending action against them at runtime.
Field 08
Expiry and review date
Mission Contracts must be time-bounded. An agent whose contract has expired should not operate until it is renewed. A review date prompts the human sponsor to reconsider whether the scope remains appropriate as the deployment context changes.
An example Mission Contract
The following is a representative Mission Contract for an invoice processing agent deployed at a Nordic finance company. All names, thresholds, and identifiers are illustrative.
MISSION CONTRACT · INVOICE PROCESSOR AGENT · NORDIC FINANCE AS
Agent: invoice-processor-v2 · Claude Sonnet · Production
Mission ID: MIS-2026-0041
Purpose: Review and approve invoices under €5,000 for suppliers on
the confirmed vendor list. Flag invoices above threshold or
from unrecognised suppliers for human review.
Allowed:
→ Read: invoices table, vendors table, payment_history table
→ Write: invoices.status (approved_draft only)
→ Email: internal finance team ([email protected])
Prohibited:
✗ Write to payments_final (any)
✗ Approve invoices above €5,000 autonomously
✗ Contact external suppliers directly
✗ Access payroll or personal data tables
Autonomy: A2 — autonomous within approved vendor list + €5,000
threshold; human confirmation for all exceptions
Human sponsor: Per Nansen · Finance Director · [email protected]
Expiry: 2027-03-31 · Review: 2026-12-31
This is an example for illustrative purposes. The vendor list, threshold, and personnel details are fictional.
The Mission Contract lifecycle
A Mission Contract is not a one-time document. It has a lifecycle that matches the lifecycle of the agent it governs.
Creation
Written before deployment
The Mission Contract is written before the agent is deployed. The human sponsor reviews and approves it. It is version-controlled from the first commit — the initial version is the governance baseline against which all future changes are measured.
Registration
Associated with the governance infrastructure
The contract is registered with the governance infrastructure. The agent's identity and contract are associated, so every action the agent takes can be checked against the current version of its contract in real time.
Operation
Policy engine evaluates every action
The policy engine evaluates agent actions against the contract in real time. Approved actions proceed. Actions outside scope are blocked or routed for human approval. Every evaluation is logged as an evidence record.
Review
Human sponsor assesses continued appropriateness
At the review date, the human sponsor assesses whether the scope remains appropriate. Usage data, incident records, and performance metrics inform the review. The sponsor may renew without change, amend, or terminate.
Amendment
Version-controlled and re-approved
Changes to scope, capabilities, or thresholds are documented as a new version. The previous version is retained in the audit trail. An amended contract must be re-approved by the human sponsor before the updated scope takes effect.
Expiry
Agent stops — or contract is renewed
At expiry, the agent stops operating until the contract is renewed. If the agent is decommissioned, the contract is marked inactive and retained for the audit period specified by applicable regulation.
Common errors in Mission Contract design
Error 01
Vague purpose statements
"Help the finance team" describes a department, not a purpose. A purpose statement must be specific enough that a policy engine can determine whether a given action is within it. If the statement cannot be evaluated algorithmically against a proposed action, it is not a purpose statement — it is a label.
Error 02
Omitted prohibitions
Many contracts list what the agent is allowed to do but do not list what it is prohibited from doing. The implicit assumption is that anything not explicitly allowed is prohibited — but this assumption is not always enforced technically. Explicit prohibitions are more reliable than implicit ones. List them.
Error 03
No named human sponsor
A team email address is not a human sponsor. When an incident occurs at 3am, "contact the finance team" does not produce an accountable human. The sponsor must be a specific named person with a reachable contact method — name, role, and direct contact, not a group inbox.
Error 04
No expiry date
A contract with no expiry date can silently become outdated as the deployment context changes. Mandatory review dates force the human sponsor to reconsider whether the scope remains appropriate. Without them, contracts accumulate technical debt.
Error 05
Thresholds that cannot be evaluated at runtime
An approval threshold must be something the policy engine can evaluate against a pending action. "Significant financial impact" is not a threshold — it is a judgement. "€5,000 or above" is a threshold. If the policy engine cannot evaluate it in milliseconds without human input, it is not a threshold.