Agent identity architectures: Delegated, bounded, and autonomous

This is the second post in a series that follows 1Password’s response to NIST’s call for input on how those principles should apply to agents. In our last post on agent identity, we introduced why the ability to reason makes agents fundamentally different from traditional machine workloads, why it breaks the assumptions traditional identity and access management was built on, and why real-time attestation establishes agent identity at runtime. This post maps those principles to production agent profiles The agents running in your environment aren’t all the same and neither are the risks they carry. A CI/CD pipeline runner and a long-running autonomous coding agent have fundamentally different access needs, threat surfaces, and identity requirements. Traditional IAM has been successful at governing login for humans and machine workloads with predictable behavior, but controlling non-deterministic agentic systems require unique authority models that a single identity architecture cannot fully govern. An agent that starts with access to a QA database may determine mid-task that it needs production access to complete its task, and the architecture governing it has to respond in real time without over-provisioning. That sort of dynamic authorization looks different depending on the type of agent that’s running, who authorized it, and what it has access to. At 1Password, we’ve mapped the AI agent architectures we see in production into delegated, bounded, and autonomous authority models, each with variants for local and remote deployments. In this post, we’ll explore the distinct threat models and required controls to secure all six profiles at your organization. The three agent authority models The authority model describes who or what the agent is acting on behalf of, and what accountability chain that creates. Delegated authority: The agent acts on behalf of a named human. The human's identity is the delegation subject, and the agent's actions must be traceable back to it. Bounded authority: The agent acts on behalf of a system or workflow. No human subject is in the chain; instead, the agent is scoped to a defined operational boundary. Autonomous authority: The agent acts toward a goal with minimal or no human oversight. It may spawn sub-agents, evolve its access needs over time, and operate across systems its initiator did not explicitly plan for. For each model, deployment in a developer's machine, a local sandbox, or an on-device browser, introduces a different set of attestation and threat challenges than in a remote environment like a Kubernetes cluster, a managed cloud sandbox, or a CI/CD platform. That distinction drives a significant portion of the protocol choices in each profile. Delegated authority A delegated agent is an extension of a human, it inherits the human's permissions and intentions within an explicitly scoped boundary. The challenge is not just proving that the agent has authorization; it’s proving whose authorization it has in a way that is cryptographically verifiable and auditable at the delegation level. Every action a delegated agent takes must be traceable back to a human who authorized it and must be able to answer what scope was granted and the steps it took. Logging actions under a service account fails this requirement entirely. Use cases include: IDE coding agents: Cursor, Claude Code, Codex, GitHub Copilot running in a developer's local environment, acting on behalf of the developer to read repositories, write code, and call external APIs. Browser copilots: Claude for Chrome, ChatGPT Atlas, and similar tools that act on behalf of a user within their browser session and SaaS applications. Workplace assistants: Sales, RevOps, and support agents that draft documents, schedule meetings, query CRM systems, and take actions within the user's existing SaaS permissions. Delegated / local A local delegated agent is an AI agent running on a user’s own machine that acts on their behalf, where the human remains the authorizing principal but the agent executes autonomously within a delegated scope. Local delegated agents are the most common deployment pattern and carry the highest attestation risk profile. When a coding agent runs in a developer's IDE, it executes under the same OS user account as the developer. Without additional controls, any other process running under that account could impersonate the agent. Malicious code, a compromised package, or an attacker payload injected via a prompt can all claim to be the legitimate agent when presenting credentials to an authorization server. This was documented in a production environment, where indirect prompt injection turned a long-lived local agent session into an attack vector. The Workload Identity Broker is an intermediary security service that replaces static API keys and passwords with ephemeral, policy-driven credentials. It’s common in cloud-hosted environments, such as CI/CD workloads, but typically isn’t available

Extras afișat conform termenilor RSS ai publicației · 200 cuvinte · textul integral și figurile sunt pe site-ul publicației