Agent Access Model (AAM) reviss access control for AI agents. It reduces risk by limiting capabilities at the level of each operation.
The modern Zero Trust model, shaped around BeyondCorp, assumed a readable subject: a person with a device acting at a limited speed. This assumption begins to break down with the emergence of AI agents. An agent performs tasks quickly, in parallel, and often with broad access to data. Under such conditions, classic mechanisms—SSO, device posture, conditional access—cease to provide precise control. They do not explicitly deny access. They “silently” grant more rights than necessary and retain them longer than required. This creates a risk of data exfiltration at machine speed.
The key issue is the mismatch in the form of the subject. An agent is neither a user nor a service account in the classic sense. It is ephemeral, launched for a specific task, and should disappear along with it. However, security infrastructure relies on long-lived credentials and infrequent rotation. As a result, tokens outlive the task itself and remain in memory, logs, or the environment. Meanwhile, anomaly detection and rate limiting are configured for human activity and fail to respond in time.
The Agent Access Model proposes changing the point of control. Instead of complicating each decision, the model reduces the very “surface of capabilities” of the agent. The basic rule is simple: do not trust the task run as a whole. Each action is authorized separately, considering three factors: who the agent is, what task is permitted, and what state has already accumulated in the task execution graph. This state acts as a limiter. It can only narrow access but cannot expand it.
Implementation is built around short-lived, task-bound tokens. Existing standards are used: OAuth 2.0 Token Exchange for issuing limited tokens and DPoP for binding the token to the client key. Such a token cannot be reproduced without the key, which remains in runtime (harness). This reduces the risk of replay attacks. At the same time, the token encodes context: agent, initiator, and specific task.
Next, the Task-Scoped Access Engine comes into play. It makes decisions on each request. Unlike classic systems, the task becomes part of the policy. Permissions are defined through task templates. For example: access to specific tables and the ability to send results to a specific channel. Upon execution, the system intersects this template with user rights and resource policies. This results in a “capability ceiling” that cannot be exceeded.
A critical element is enforcement outside the model. Prompts are not considered a security boundary. Control is implemented at two points: in the harness, which intercepts tool calls, and at the network layer, which restricts outgoing traffic. This eliminates classic attacks through prompt injection, where the model can be convinced to violate rules. If an action is not permitted at the system level—it will not be executed.
Additionally, a Trust Ratchet mechanism is introduced. It makes trust a state that can only deteriorate. For example, after reading sensitive data, the system automatically restricts possible transmission directions. This reduces the risk of leakage before data leaves the system. Importantly, the rules for such transitions are predefined and transparent to the operator.
The architecture is complemented by logging actions (Agent Activity Log) and a grant review loop. This allows for adapting task templates based on actual behavior without expanding the rights of already executed tasks. Thus, the system remains manageable even with a large number of short-lived agents.
The result is a stricter and more predictable access control model for AI agents. It does not make each decision “smarter,” but simplifies the decisions themselves by reducing permissible actions. Performance metrics are not provided in the original material, but architecturally, this appears as an evolutionary development of Zero Trust towards action-level control and machine-speed enforcement.