On October 27, 2026, IBM announced Agent Identity at TechXchange. Used with HashiCorp Vault, it keeps an authoritative record for each AI agent (who owns it, its lifecycle status, the authority it has been granted) and issues short-lived, least-privilege credentials that can be revoked in real time. IBM lists Agent Identity, Vault 2.2 and the evaluate features in watsonx Orchestrate as generally available. Cross-platform discovery and containment, meaning isolated sandboxes and a kill switch, are tech previews. The design is plausible on paper. Customer outcomes are not yet published.
Large enterprises are about to have many more non-human actors than they can name. Gartner, as cited in IBM's announcement, expects the average Fortune 500 enterprise to use over 150,000 AI agents by 2028, while only 13% of organizations believe they have the right agent governance in place.
IBM's answer, announced at TechXchange 2026 on October 27, is to treat each agent like an identity: someone owns it, it has a state, and it holds only the access it needs for as long as it needs it. The idea is not new for people and services. The new part is applying it to agents.
What did IBM announce?
The announcement is a bundle. This teardown covers the part that matters most for agents that touch real systems: Agent Identity and HashiCorp Vault for identity and credentials, plus the watsonx Orchestrate capabilities that rely on them. IBM's release also covers Terraform, Concert, an integration hub and IBM Z, which we leave aside.
How does the mechanism work?
- A record. Used with Vault, Agent Identity establishes the authoritative record for each agent: who owns it, its lifecycle status and the authority it has been granted.
- A credential. Vault issues secured, short-lived credentials limited to what the agent needs. It generates credentials dynamically and rotates supported ones. IBM says Vault 2.2 gives agents their own secured accounts and renews their credentials automatically.
- A check at the moment of use. If an agent tries to retrieve information or act outside its approved permissions, access can be denied and the session revoked in real time.
- Fleet controls. IBM says watsonx Orchestrate works across Amazon Bedrock, Microsoft Foundry and Google Gemini. In tech preview, it can discover agents built there, plus models and MCP servers, and run agents in isolated sandboxes with a kill switch. Its evaluate capabilities, which are generally available, can test agents, models and MCP servers before deployment, monitor them in production, and track each agent's model and token use.
IBM also says Agent Identity and Vault integrate with NVIDIA's OpenShell secure runtime, so a protected environment and a verified identity travel together.
What is shipping, and what is not?
IBM states availability explicitly, which is the most useful part of the release for a buyer.
| Capability | IBM's stated status | What it means for a buyer |
|---|---|---|
| Agent Identity | Generally available | Can be adopted now |
| HashiCorp Vault 2.2 (agent accounts, automatic credential renewal, post-quantum encryption) | Generally available | Can be adopted now |
| watsonx Orchestrate evaluate (pre-deployment testing, production monitoring, per-agent cost tracking) | Generally available | Can be adopted now |
| Secure Hub (visibility across Vault environments) | Public preview | Try it, do not depend on it |
| watsonx Orchestrate discover (find agents on other platforms, models, MCP servers) | Tech preview | Roadmap, not a control you can rely on |
| watsonx Orchestrate contain (isolated sandboxes and a kill switch) | Tech preview | Roadmap, not a control you can rely on |
| Integration with NVIDIA OpenShell | Announced integration | The release does not state availability |
The split matters. Discovery, which finds agents built on other platforms, and containment, which sandboxes them, are the ones still in preview.
Why is the credential the real boundary?
IBM's own framing is blunt: an agent with a long-lived, overprivileged credential can put systems and data at risk if it is compromised or acts outside its intended task. We agree, and the reasoning is simple. An identity record says who an agent is. The credential decides what damage a mistake or a theft can do, and for how long.
A recent example shows why lifetime matters. In our decode of the Cairn AI hacking campaign, NorForge ran a scanner over data from exposed control panels and found hundreds of secrets, 11% of which a scanner verified as valid. That is a different story from IBM's product, and nothing here claims IBM's controls would have changed it. It does show that a secret that expires quickly is worth less to anyone who steals it than one that never does.
What remains unproven?
- Outcomes. The release contains design intent and availability, not customer results or independent testing.
- Coverage. Controls only work for agents that actually get their credentials through the system. An agent holding a static key in a config file sits outside the model. That is our assessment, not an IBM claim.
- Unregistered agents. Discovery, the feature meant to find them, and containment are tech previews.
- Roadmap. IBM notes that statements about its future direction are subject to change.
How does this relate to the cloud platforms' own governance?
We compared how Microsoft, AWS and Google approach governance for enterprise agents in our teardown of Agent 365, Bedrock AgentCore and Gemini Enterprise, and we do not repeat that here. IBM's positioning is different: a layer that works across platforms rather than inside one. That claim is currently strongest for identity and credentials, which are generally available, and weakest for cross-platform discovery, which is not. The reasoning for why identity and least privilege matter at all is in our piece on banks blocking AI agents.
Who should evaluate it?
It is worth a serious look if you run many agents across teams or platforms, already use Vault or IBM's identity tooling, or work in a regulated environment where you must show who authorized what. The operations angle is easy to overlook: per-agent model and token cost tracking in Evaluate is a budgeting tool as much as a safety one.
It is probably more than you need for a single agent inside one platform whose native controls already cover owner, scope and revocation.
Before any agent touches an ERP, a maintenance system, or a scheduling or records system in healthcare, ask every vendor three questions:
- Is there a named owner for the agent?
- Are its credentials scoped, and do they expire?
- Is there a kill switch that works today, not in a preview?
The builder's verdict
This is a reasonable design: identity, short-lived credentials, a decision at the moment of use. It is also available now for the identity and credential pieces. What it cannot yet prove is that it works across the messy mix of platforms most companies actually run.
The evaluation we would run is narrow. Pick one agent that can change something in a real system, register it, give it a scoped credential, then try to make it act outside its permissions and confirm the access is denied and the session ends. If that works, expand. If you want a second opinion on where the owner, the credential and the kill switch should sit for your agents, show us the workflow.