On October 26, 2026, IBM made Agent Identity generally available, and the announcement deserves more than a shrug in a year crowded with agent security launches. The company's framing is blunt: AI agents have moved "from assistance to execution" — they retrieve data, invoke tools and APIs, coordinate workflows and act on behalf of people and organizations. Traditional identity models, built around people, applications and comparatively stable machine identities, were never designed for a workload that combines delegated user authority, contextual decision-making and privileged access all at once.
IBM's answer is to treat agents as first-class identities and to pull their entire lifecycle — registration, delegation, enforcement and governance — into one identity control plane. Here is what that actually means, how it differs from the agent identity moves we have tracked all year, and what a smaller team can borrow without buying the stack.
The problem IBM is naming
Most organizations running agents today cannot answer four basic questions, per IBM's announcement: Which agents are operating in the environment? Who owns them? What authority do they have? Which actions did they take, and under whose direction?
An agent is an odd identity. It acts with delegated user authority, but executes like a workload. It crosses systems, exchanges tokens, calls other agents and uses credentials to finish tasks. Its risk is dynamic: appropriate access at 9 a.m. can be excessive at 9:15 if context changes. Yet in most stacks, its credentials behave like a service account — standing, broad and invisible in the audit trail behind a human identity.
That gap is why the identity layer keeps surfacing as the control point for agent governance — ServiceNow's AI Passport attaches a signed credential to each agent, and 1Password built a trust layer for personal agents. IBM's version is the most complete enterprise attempt to consolidate all of it into one plane.
What is actually in it
IBM Agent Identity covers five lifecycle stages, and the details matter more than the labels:
- Discovery and registration. Agents get registered in a central inventory with ownership, metadata, risk classification, approved tool connections and lifecycle state. The point is a system of record for agents instead of fragments scattered across platforms and teams — a direct answer to the shadow-agent problem, which research this year put at severe levels: SailPoint found 79% of organizations have AI agents active, while only 2% secure them adequately.
- On-behalf-of delegation. The platform preserves the chain across identity providers and token exchanges, so an action can be traced to its originating person, approval state or upstream system. This kills the "the agent did it" excuse: every action lands attached to a human.
- Task-scoped credentials. OAuth-based, short-lived, task-scoped tokens narrow access at each step, and consent-aware authorization can add friction for sensitive actions. Rather than a standing service-account key, an agent gets exactly the access an approved task requires, for as long as the task requires.
- Runtime enforcement. Contextual authorization, policy evaluation and credential control stay active while the agent runs — not only when the session starts, which is the moment most current tooling stops checking.
- Accountability. Structured audit trails connect the human identity, the delegated agent identity, credential issuance, policy decisions and downstream actions, giving compliance and incident response an actual evidence chain.
The architecture: Verify, Vault and watsonx Orchestrate
The interesting engineering decision is that IBM did not build this as a single product bolt. Three pieces interlock:
- IBM Verify holds identity, authorization, governance, token exchange and audit — the "who is this agent and what may it do" brain.
- HashiCorp Vault brokers just-in-time, target-specific credentials for systems that cannot consume delegated tokens — the "hand the agent the exact key, briefly" mechanic, reducing dependence on persistent secrets.
- watsonx Orchestrate provides the onboarding path: agents created or managed there flow into centralized identity and governance controls in Verify.
IBM says the design coexists with existing identity providers rather than requiring replacement of workforce identity investments — a pragmatic note, since the realistic alternative to coexistence is nobody adopting it.
How it compares to the agent identity wave
| Offering (2026) | Core model | What it controls |
|---|---|---|
| ServiceNow AI Passport (June) | Signed credential per agent | Authorization via agentic OAuth, kill/dimmer switch per action |
| 1Password for Agents (Sept) | Scoped credentials for personal agents | Secret storage and hand-off for consumer-side agents |
| Straiker Agent Passport (Oct) | Third-party red-teaming before deployment | Verification independent of the vendor |
| IBM Agent Identity (GA Oct 26) | Full-lifecycle identity control plane | Registration, delegation, runtime enforcement, audit |
The distinction: passports and trust layers verify or scope individual agents; IBM is trying to own the lifecycle plane they all live in. Whether the plane wins depends less on IBM's engineering than on whether the market treats agent identity as an IAM problem (IBM's bet) or a security-tools problem (where credential-scoping vendors play).
The honest caveats
An IBM control plane does not solve agent governance by purchase order. Three limits deserve attention:
- Coverage follows inventory. Proper registration of an agent requires the agent to come through supported paths like watsonx Orchestrate; agents built on other frameworks depend on the coexistence story working in your specific stack. The shadow-agent numbers suggest the discovery problem is not solved by a registration form alone.
- Runtime enforcement needs real policy. The plane does the checking; your team still has to write what "appropriate" means per task and keep it current. Short-lived tokens reduce blast radius but concentrate effort on policy design — most teams underestimate this work.
- Accountability is only as strong as the delegation chain. "On-behalf-of" trails collapse if upstream systems strip or re-issue tokens before reaching Verify, which integration realities frequently do.
What to borrow if you are not an IBM shop
Small and mid-size teams adopting agents do not need the platform to adopt the pattern, and the pattern is the value:
- Build an agent register today. A spreadsheet beats nothing: name, owner, tools and APIs, authority level, review date. The 2%-versus-79% gap from SailPoint starts closing at the inventory step.
- Issue agents their own short-lived credentials, never a person's or a shared service account's, scoped to the task and expiring with it.
- Record the delegation chain. Log which human's intent triggered which agent's action, in a place your incident-response process actually looks.
- Review access at runtime events, not session starts — most agent abuse happens inside authorized sessions, a failure mode CERT-IN documented in unauthorized-access incidents this year.
This is the same architecture IBM productized, minus the invoices. And if your team is standing up its first working agents and wants the identity pattern designed properly from day one rather than retrofitted later, that is exactly the kind of build Vivid does. Contact us — an hour of architecture now saves months of cleanup.
