An agent contract is a policy definition that states what an AI agent may do, what data it may access, and how far its reasoning may extend. It functions as a least-privilege boundary for autonomy and gives security teams something concrete to enforce and audit.
Expanded Definition
An agent contract is the operational boundary that translates an AI agent’s intended purpose into enforceable policy. It defines permitted actions, data scopes, tool access, escalation paths, and any reasoning or delegation limits that should not be crossed. In practice, the contract sits between a model’s raw capability and the organisation’s control expectations, so it is closer to a governance object than a prompt. That distinction matters because agents can be autonomous, persistent, and able to invoke tools, which creates risk beyond ordinary application logic.
Definitions vary across vendors, but the security view is consistent: an agent contract should be explicit, machine-readable where possible, and auditable by security and platform teams. This aligns closely with the control mindset reflected in the NIST AI Risk Management Framework and the application-focused guidance in the OWASP Agentic AI Top 10. The contract is not the same as a model policy, a prompt template, or a runtime allowlist on its own; it should bind all three together where possible.
The most common misapplication is treating an agent contract as documentation only, which occurs when teams write behavioural rules but do not enforce them at runtime.
Examples and Use Cases
Implementing an agent contract rigorously often introduces friction for product teams, because tighter constraints can reduce automation flexibility and increase approval overhead, requiring organisations to weigh agent autonomy against blast-radius reduction.
- A customer-support agent is allowed to read case metadata and draft responses, but the contract blocks payment changes, credential resets, and outbound email to non-approved domains.
- An internal research agent can query approved knowledge sources and summarise findings, but the contract prevents it from exporting sensitive documents or calling external tools not listed in policy.
- A software-development agent may open pull requests and run tests, but the contract denies direct production deployment unless a human approver authorises the release path.
- A security triage agent can enrich alerts from SIEM and EDR, but the contract limits it to read-only access and forbids any ticket closure without analyst review, consistent with control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls.
- An externally facing AI assistant is constrained to a narrow data domain and approved retrieval sources, reflecting the governance emphasis in the NIST AI Risk Management Framework and the tool-use risks described by the OWASP Top 10 for Agentic Applications 2026.
Why It Matters for Security Teams
Agent contracts matter because agentic systems fail differently from conventional software. If the contract is vague, an agent may infer permission from context, chain tools in unsafe ways, or reach beyond the data it was meant to handle. That creates policy drift, over-collection, and unauthorised action paths that are hard to detect after the fact. For security teams, the contract becomes the reviewable artefact that ties identity, privilege, data access, and operational scope into one control surface.
This is especially important where agents act on behalf of users or services, because the contract should limit not only what the model can say, but what it can actually do. The threat models emerging in MITRE ATLAS adversarial AI threat matrix and the agentic patterns discussed in the CSA MAESTRO agentic AI threat modeling framework both reinforce the need for bounded autonomy. Where contracts are weak, agents can become convenient paths for over-privileged access, especially when they are connected to secrets, tickets, or enterprise workflows.
Organisations typically encounter the need for an agent contract only after an agent has accessed the wrong dataset or executed an unsafe action, at which point the boundary becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF frames governance and risk controls for bounded, accountable AI behaviour. | |
| OWASP Agentic AI Top 10 | OWASP covers agentic application risks that contracts are meant to constrain. | |
| NIST CSF 2.0 | PR.AC | Access control outcomes align with restricting agent permissions and tool reach. |
| NIST SP 800-53 Rev 5 | AC-3 | AC-3 defines enforcement of approved access and actions, which contracts operationalise. |
| CSA MAESTRO | MAESTRO addresses threat modeling for agentic systems and their control boundaries. |
Define ownership, limits, monitoring, and review for each agent contract under AI risk governance.
