The Agent Access Model (opens in new tab)

BeyondCorp established that access should depend on identity and device health rather than network location. The post argues that this human-centered model is inadequate for ephemeral, fast-moving, and highly composable software agents. It proposes the Agent Access Model (AAM), which limits an agent’s capability to a specific task, evaluates every action against evolving task state, and enforces controls in the execution harness and network rather than relying on prompts.

The Shift from Humans to Agents

• Traditional Zero Trust assumes a legible human principal:
  • A person uses a small number of devices.
  • Activity occurs at human speed.
  • Access decisions can be evaluated over time using SSO, device posture, and risk scoring.
• Agents have a different operating model:
  • A task-scoped run is ephemeral and ends when its work is complete.
  • A long-lived service may execute many independent tasks.
  • Agents can access databases, source control, logs, ticketing systems, documents, and other systems in rapid succession.
• Least privilege must therefore become real-time and task-specific rather than a periodic policy review.

Why Human-Oriented Controls Fail

• Durable credentials outlive ephemeral work
  • Service-account keys and broad scopes may remain available after a task ends.
  • Credentials can persist in memory, logs, or environment variables.
  • Agent credentials should expire with the task and typically live only for minutes.
• Machine-speed activity bypasses slow detection
  • An agent can read sensitive data and transmit it externally before human-tuned anomaly or DLP systems react.
  • Preventive controls must operate inline at tool-call and network boundaries.
• Prompts cannot enforce security boundaries
  • Instructions such as “do not access production” can be overridden by malicious content or unsafe model behavior.
  • Intent may inform risk decisions, but enforcement must occur in the harness and network layer.
• Authority can disappear across delegation chains
  • Agents may call tools that invoke other agents and APIs.
  • Existing identity and delegation mechanisms struggle to preserve the original human, task, and permissions across multiple hops.

The Agent Access Model

• AAM’s central rule is: do not trust the task execution graph; authorize every action.
• Each action is evaluated against:
  • The agent’s identity.
  • The human or system principal it acts for.
  • The authorized task.
  • Resources already accessed by the task execution graph.
• Accumulated task state can only reduce remaining capabilities; authorization for one action does not automatically authorize later actions.
• AAM complements systems such as Beyond Zero by shrinking the capability set that authorization engines must evaluate and recording the agent, principal, and task behind each decision.

AAM’s Five Principles

• Short-lived, bound credentials
  • Credentials are minted for a specific task, expire with it, and are sender-constrained.
  • A stolen token cannot be replayed without the harness-held proof key.
• Enforcement outside the prompt
  • The harness mediates tool calls.
  • The network mediates packets.
  • Prompts communicate intent but are not security boundaries.
• Exceptional human oversight
  • Human approval is reserved for genuinely consequential decisions.
  • Requiring approval for every step causes fatigue and habitual clicking.
• Evidence-based grant review
  • Captured activity reveals whether task templates are too broad or too narrow.
  • Approved policy changes apply only to future tasks and never expand the permissions of an active task.
• One-way capability reduction
  • A declared protected event triggers the Trust Ratchet.
  • Capabilities are removed across the task execution graph according to policy.
  • Removed authority can return only through a newly authorized task.

Reference Architecture

• AAM describes a reference architecture with:
  • Four active controls governing the task.
  • An Agent Activity Log that records evidence.
  • A Grant Review Loop that uses that evidence to improve future grants.
• The architecture is intended to define security guarantees and component responsibilities rather than prescribe a specific wire-level implementation.
• At dispatch, the Agent Identity Broker issues a verifiable, short-lived credential scoped to the task.
• The credential identifies:
  • The agent.
  • The principal on whose behalf it acts.
  • The authorized task.
• It must expire no later than the task itself and be sender-constrained to prevent token-only replay.

A practical implementation should treat each agent run as a bounded, independently authorized execution graph. Enforce permissions inline at the harness and network layers, use short-lived task-bound credentials, continuously reduce capability when risk changes, and use audit evidence to refine future grants without widening permissions during an active task.