Your engineering team has spent two decades building identity and access management for humans. Every employee has an identity. Every identity has roles. Every role has permissions. Every permission is scoped. Every access is logged.
Then you deploy an AI agent. It has no identity. It inherits the permissions of whoever invoked it. Its scope is whatever the agent framework gives it access to. Its actions blend into the invoking user's audit trail. And if you have five agents, they all look the same to your IAM system.
This is not a minor operational gap. It's a governance failure that makes every other control — policy enforcement, decision traces, tool execution control, tenant isolation — structurally incomplete. You cannot enforce policy on an entity that has no identity. You cannot audit actions that aren't attributed. You cannot scope permissions for something your IAM system doesn't recognize as an actor.
Agent identity is the foundation layer. Without it, governed execution is impossible.
The contrast between how enterprises manage human identity and how they (don't) manage agent identity reveals the structural governance gap.
| Capability | Human IAM (Current State) | Agent IAM (Without Governed Runtime) | Agent IAM (With Build Agents) |
|---|---|---|---|
| Identity | Unique employee ID, authenticated at login | No identity — inherits invoker credentials | Unique agent_id registered in Agent Registry |
| Permissions | Role-based, scoped by department and function | Inherits invoker's full permission set — over-permissioned by default | Hybrid ABAC/ReBAC with purpose-bound, task-scoped, time-limited access |
| Audit Trail | Every action attributed to the specific user | Agent actions blend into invoker's trail — agents indistinguishable | Every action attributed to specific agent_id in decision trace |
| Scope Control | Access denied for out-of-scope requests, logged as violation | No scope boundary — agent accesses whatever the framework exposes | Decision-time gate validates scope before execution; commit-time gate enforces at action |
| Delegation | Manager delegates to employee with documented authority chain | No delegation record — nobody knows who authorized the agent | Full delegation chain: who authorized, under what policy, with what constraints, when it expires |
| Intervention | Disable a specific user account without affecting others | No way to target a specific agent — must disable the entire system | Per-agent kill switch, quarantine mode, canary rollout |
Every capability in the "Human IAM" column exists because humans have identity. Every gap in the "Without Governed Runtime" column exists because agents don't. Agent identity isn't a feature — it's the foundation that makes policy enforcement, decision traces, tool execution control, and feedback loops architecturally possible.
FAQ: Can't I use service accounts as agent identities?
Service accounts provide authentication credentials. Agent identity requires ownership, scoped permissions, version history, delegation chains, and task-level access control. Service accounts are a network primitive; agent identity is a governance primitive.
Machine-grade identity means every agent is a registered entity in the system with four identity dimensions:
These four dimensions transform an agent from an anonymous function call into a governed actor within the enterprise's institutional framework — an entity that can be authorized, audited, scoped, versioned, and held accountable through the same governance principles applied to human identities.
FAQ: Does every agent need a full identity, even simple utility agents?
Yes. Governance gaps don't scale by agent complexity — they scale by agent access. A simple utility agent with database write access can cause as much damage as a complex reasoning agent if it has no identity, no scope, and no audit trail.
Build Agents provides an Agent Registry — the central system where every agent is registered as a first-class entity with its own identity, permissions, and audit trail. The Agent Registry is to AI agents what Active Directory or Okta is to human users: the authoritative identity provider.
When an agent is registered, it receives:
When the agent executes, every action is attributed to this identity. The Decision Trace captures the agent_id alongside the request_id, session_id, and tenant_id. There is no ambiguity about which agent took which action.
This is the identity layer that enables every other primitive in the Governed Agent Runtime. Policy enforcement evaluates permissions against the agent_id. Tool execution control scopes access per agent_id. Decision traces attribute every action to the agent_id. Feedback loops measure performance per agent_id. The Agent Registry is the foundational data structure that makes governed execution possible.
FAQ: How does the Agent Registry handle multi-agent workflows?
Each agent in a multi-agent workflow has its own agent_id. The orchestrator agent's identity and its delegation to child agents are recorded in the decision trace, creating a complete multi-agent provenance chain.
Traditional role-based access control assigns roles to users and permissions to roles. A human with the "refund_processor" role can process any refund for any customer at any time. This works for humans because human judgment provides contextual restraint — a refund processor doesn't process fraudulent refunds because they recognize the risk.
Agents don't have this contextual restraint. An agent with a "customer_data_reader" role will read any customer data it can access — regardless of whether the current task requires it. Role-based access is too coarse for agents that operate at machine speed across enterprise systems.
Build Agents implements a hybrid ABAC/ReBAC model that combines:
Together, this enables purpose-bound permissions:
| Dimension | Traditional RBAC | Purpose-Bound (ABAC/ReBAC) |
|---|---|---|
| Data Access | All customer data accessible via role | Only the specific customer's data referenced in this task |
| Duration | Permanent until role revoked | Task duration only — access expires when task completes |
| Scope | Entire resource category | Specific resources required for this specific task |
| Context Awareness | None — same permissions regardless of context | Permissions adjust based on task, tenant, risk level, and runtime conditions |
| Audit Granularity | "User accessed customer data" | "Agent X accessed customer Y's refund history for task Z, authorized by policy V, for 12 seconds" |
This is the tenant isolation and purpose-bound permissions model that prevents the systemic risk failure mode documented in Part 2 — where a shared tool with blanket access created a platform-wide cross-tenant vulnerability.
FAQ: Can I keep my existing RBAC and add ABAC/ReBAC for agents?
Yes. Build Agents integrates with existing IAM infrastructure. Human RBAC remains unchanged. The hybrid model adds agent-specific governance on top of existing enterprise identity systems.
When a manager approves a purchase order, the delegation chain is clear: the manager has the role, the role has the permission, the permission was granted by IT and approved by finance. Every link in the chain is documented.
When an agent approves a purchase order, the delegation chain doesn't exist in most deployments. Who authorized it? The developer who built the agent? The platform team that deployed it? The manager who configured its scope? The VP who approved the automation program? This is the accountability gap documented in Part 2, Failure Mode 4.
Build Agents captures delegation chains as first-class runtime data. Every agent action references:
When an auditor asks "who authorized this agent to process refunds over ₹5,000?" the answer is immediate and complete: this specific policy, configured by this person, approved by this authority, with this scope limitation, valid until this date — all recorded in the decision trace.
This is the implementation of the accountability primitive that the Governed Agent Runtime provides. Delegation chains connect agent identity to institutional authority — closing the governance vacuum between "who configured the agent" and "who approved the output" that Part 2 identified as a structural failure pattern.
FAQ: Do delegation chains add bureaucratic overhead?
No. They are captured automatically by the runtime as a byproduct of policy enforcement. The overhead is in the initial policy configuration, not in ongoing execution. The benefit is instant, complete auditability for every agent action.
Identity-based controls enable operational safety capabilities that are impossible without agent identity. If an agent behaves unexpectedly, you need to intervene on that specific agent without affecting others.
| Control | What It Does | Why It Requires Identity |
|---|---|---|
| Per-Agent Kill Switch | Instantly disable a specific agent without affecting other agents in the system | Without unique agent_id, you can't target one agent — must disable the entire tool or system |
| Quarantine Mode | Switch an agent to observe-only — it can reason but cannot commit actions through the Tool Broker | Quarantine requires identity-scoped execution control at the commit-time gate |
| Canary Rollout | Deploy a new agent version to a subset of traffic while the previous version handles the rest | Version-aware routing requires distinct identities for each agent version |
| Per-Agent Performance Tracking | Measure cost, latency, error rate, and compliance rate per individual agent | Performance metrics require attribution — the feedback loop primitive tracks outcomes per agent_id |
These controls are the operational safety layer that enterprises require before deploying agents at scale. They are the agent equivalent of the infrastructure lifecycle controls that Kubernetes provides for containers — and like container orchestration, they are impossible without identity as the foundational primitive.
FAQ: Can I implement kill switches without an Agent Registry?
You can stop a process, but you can't selectively disable one agent while keeping others running on the same infrastructure. The Agent Registry enables surgical intervention — targeting a specific agent version, on a specific tenant, handling a specific task type.
Every human in your enterprise has an identity. Every agent should too.
Agent identity is not a feature to add after deployment. It is the foundational layer that makes every other governance control architecturally possible. Policy enforcement requires an entity to evaluate permissions against. Decision traces require an entity to attribute actions to. Tool execution control requires an entity to scope access for. Feedback loops require an entity to measure performance of. Dual-gate enforcement requires an entity whose authority can be verified at both decision-time and commit-time.
Without agent identity, you have agents that are invisible to your IAM system, unaccountable in your audit trail, over-permissioned by default, and indistinguishable from each other when something goes wrong.
With machine-grade identity — registered in the Agent Registry, governed by hybrid ABAC/ReBAC, tracked through delegation chains, and protected by operational safety controls — agents become governed actors within your enterprise's institutional framework. This is the identity primitive that Context OS provides as the foundation of the Governed Agent Runtime.