An Agent Security Model is a structured framework for controlling how an AI agent perceives information, makes decisions, invokes tools, accesses resources, communicates with other systems, and changes its environment.
Unlike a conventional application security model, it cannot assume that execution follows a fixed and predictable code path. An agent interprets untrusted context, selects actions probabilistically, and may operate across multiple systems with delegated authority. Security must therefore govern both the software and the agent’s behaviour at runtime.
A robust Agent Security Model separates the system into seven security layers.
Fig. 01 — The seven layers
Agent Security Model
Identity and provenance
- Every agent, user, tool, workload, data source, and peer agent must have a verifiable identity.
- The system must establish which agent is operating, which code and configuration it is running, who authorised it, and where its instructions and dependencies originated.
Context security
- All information entering the agent — including user prompts, emails, documents, web content, retrieval results, tool responses, memories, and agent-to-agent messages — must be treated as potentially hostile.
- Context should be classified, isolated by trust level, checked for manipulation, and prevented from silently overriding higher-authority instructions.
Authority and permission control
- An agent should receive only the authority required for the current task.
- Permissions should be scoped by user, tenant, resource, tool, operation, time, and intent.
- The model should prevent an agent from converting broad access into unintended action simply because an instruction appeared in its context.
Decision and policy enforcement
- Agent decisions must be evaluated against deterministic security policy before execution.
- The language model may propose an action, but it should not be the final authority.
- Policy gates should validate the requested action, parameters, destination, data sensitivity, expected outcome, and whether human approval is required.
Tool and execution security
- Tools must be treated as privileged execution interfaces rather than harmless model extensions.
- Each tool should have a constrained schema, explicit permissions, validated inputs and outputs, execution isolation, rate limits, and protection against command injection, excessive agency, confused-deputy behaviour, and unsafe chaining.
Runtime monitoring and containment
- The system should observe the agent’s behaviour continuously rather than relying solely on pre-deployment testing.
- Controls should detect abnormal tool use, repeated failures, unexpected resource access, privilege escalation, data exfiltration, policy evasion, and deviations from the authorised task.
- The agent must be interruptible, recoverable, and capable of being placed into a restricted or read-only state.
Assurance, audit, and governance
- Every material decision and action should produce an auditable evidence trail containing the actor, instruction, context, policy decision, tool invocation, result, approval, and outcome.
- This supports incident response, regulatory assurance, behavioural analysis, red-team validation, and continuous improvement of the security posture.
- 01
Identity and provenance
- Every agent, user, tool, workload, data source, and peer agent must have a verifiable identity.
- The system must establish which agent is operating, which code and configuration it is running, who authorised it, and where its instructions and dependencies originated.
- 02
Context security
- All information entering the agent — including user prompts, emails, documents, web content, retrieval results, tool responses, memories, and agent-to-agent messages — must be treated as potentially hostile.
- Context should be classified, isolated by trust level, checked for manipulation, and prevented from silently overriding higher-authority instructions.
- 03
Authority and permission control
- An agent should receive only the authority required for the current task.
- Permissions should be scoped by user, tenant, resource, tool, operation, time, and intent.
- The model should prevent an agent from converting broad access into unintended action simply because an instruction appeared in its context.
- 04
Decision and policy enforcement
- Agent decisions must be evaluated against deterministic security policy before execution.
- The language model may propose an action, but it should not be the final authority.
- Policy gates should validate the requested action, parameters, destination, data sensitivity, expected outcome, and whether human approval is required.
- 05
Tool and execution security
- Tools must be treated as privileged execution interfaces rather than harmless model extensions.
- Each tool should have a constrained schema, explicit permissions, validated inputs and outputs, execution isolation, rate limits, and protection against command injection, excessive agency, confused-deputy behaviour, and unsafe chaining.
- 06
Runtime monitoring and containment
- The system should observe the agent’s behaviour continuously rather than relying solely on pre-deployment testing.
- Controls should detect abnormal tool use, repeated failures, unexpected resource access, privilege escalation, data exfiltration, policy evasion, and deviations from the authorised task.
- The agent must be interruptible, recoverable, and capable of being placed into a restricted or read-only state.
- 07
Assurance, audit, and governance
- Every material decision and action should produce an auditable evidence trail containing the actor, instruction, context, policy decision, tool invocation, result, approval, and outcome.
- This supports incident response, regulatory assurance, behavioural analysis, red-team validation, and continuous improvement of the security posture.
The agent may reason, recommend, and propose — deterministic controls govern what it may do.© Tom Mooney · tommooney.co.uk
The seven layers
1 — Identity and provenance
Every agent, user, tool, workload, data source, and peer agent must have a verifiable identity. The system must establish which agent is operating, which code and configuration it is running, who authorised it, and where its instructions and dependencies originated.
2 — Context security
All information entering the agent — user prompts, emails, documents, web content, retrieval results, tool responses, memories, and agent-to-agent messages — must be treated as potentially hostile. Context should be classified, isolated by trust level, checked for manipulation, and prevented from silently overriding higher-authority instructions.
3 — Authority and permission control
An agent should receive only the authority required for the current task. Permissions should be scoped by user, tenant, resource, tool, operation, time, and intent. The model should prevent an agent from converting broad access into unintended action simply because an instruction appeared in its context.
4 — Decision and policy enforcement
Agent decisions must be evaluated against deterministic security policy before execution. The language model may propose an action, but it should not be the final authority. Policy gates should validate the requested action, parameters, destination, data sensitivity, expected outcome, and whether human approval is required.
5 — Tool and execution security
Tools must be treated as privileged execution interfaces rather than harmless model extensions. Each tool should have a constrained schema, explicit permissions, validated inputs and outputs, execution isolation, rate limits, and protection against command injection, excessive agency, confused-deputy behaviour, and unsafe chaining.
6 — Runtime monitoring and containment
The system should observe the agent’s behaviour continuously rather than relying solely on pre-deployment testing. Controls should detect abnormal tool use, repeated failures, unexpected resource access, privilege escalation, data exfiltration, policy evasion, and deviations from the authorised task. The agent must be interruptible, recoverable, and capable of being placed into a restricted or read-only state.
7 — Assurance, audit, and governance
Every material decision and action should produce an auditable evidence trail containing the actor, instruction, context, policy decision, tool invocation, result, approval, and outcome. This supports incident response, regulatory assurance, behavioural analysis, red-team validation, and continuous improvement of the security posture.
The central principle
The agent may reason, recommend, and propose — but deterministic controls must govern what it is allowed to do.
This creates a separation between intelligence and authority. The probabilistic model determines what might be useful; the security model determines what is permitted.
Securing the full lifecycle
A complete implementation secures the whole agent lifecycle, not just the moment of execution:
Discover→Identify→Instruct→Reason→Authorise→Execute→Observe→Verify→Learn
The model is successful when it can answer, for every agent action:
- Which agent performed it?
- Who authorised the agent?
- What objective was it pursuing?
- Which context influenced the decision?
- What permissions were used?
- Which policy allowed the action?
- What data or systems were affected?
- Was the result verified?
- Can the action be reconstructed, contained, or reversed?
Putting it together
In practical terms, an Agent Security Model combines zero-trust identity, least privilege, context isolation, deterministic policy enforcement, secure tool execution, behavioural monitoring, and continuous assurance into a single control architecture for autonomous systems. None of these controls is novel on its own — what is new is that they must now govern an actor that reads hostile data, reasons probabilistically, and holds your credentials while it does so.