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.
