Why agents needed their own identity layer
Most enterprise agent deployments today borrow identity from somewhere else: a service account, an API key scoped far too broadly, or a human user's own credentials passed down through a chain of tool calls. That works fine until something goes wrong, at which point nobody can say with precision which agent did what, under whose authority, or why it had access to the system it touched in the first place.
Agent Identity is IBM's attempt to close that gap directly. Every agent gets its own credential, short-lived and scoped to a specific owner and permission set, rather than inheriting broad access from a shared account. When an agent tries to step outside that scope, the system denies the request and terminates the session automatically, which turns a governance policy that used to live in a document into something enforced at the infrastructure layer.
Built on Vault, not bolted onto it
The choice to build this on HashiCorp Vault 2.2, rather than as a standalone IBM product, matters for adoption. Vault is already the secrets-management layer inside a large share of enterprise infrastructure, which means Agent Identity extends a system security teams already trust rather than asking them to onboard a new vendor relationship purely for agent governance.
That lineage also explains the timing. IBM closed its acquisition of HashiCorp in 2025, and this release is the first major agent-specific capability to come out of that combination at scale. We expect IBM to keep building agent governance features directly into the Vault product line rather than as a separate watsonx add-on, because the credential and secrets layer is the more natural home for identity enforcement than an application layer sitting above it, and because every existing Vault customer is a built-in distribution channel IBM does not have to win over from scratch. That matters more than it sounds, since the hardest part of selling a new governance product into a large enterprise is usually not the feature set, it is the procurement cycle and the security review a brand-new vendor relationship has to clear.
Secure Hub and the hardware angle
Secure Hub, shipping in public preview, centralizes Vault environments across an organization's infrastructure and integrates with Nvidia OpenShell, which pushes identity and access controls down into GPU and accelerator infrastructure rather than stopping at the application or API layer. That is a meaningful extension, because a lot of agent governance conversations today focus entirely on API-level permissions and ignore the compute layer the agent's model actually runs on, leaving a blind spot at exactly the layer where a compromised credential could do the most expensive damage, since GPU time itself is one of the largest line items in any serious AI infrastructure budget.
Extending identity controls to the hardware layer closes a gap that becomes more relevant as enterprises run more inference on dedicated or co-located accelerator capacity rather than purely through API calls to a hosted model. We think this is the part of the release that will matter most to organizations running large internal AI infrastructure footprints rather than those purely consuming hosted model APIs, and it is also the part least likely to get matched quickly by a pure-software competitor that does not already have a hardware partnership in place.
Discover, Contain, and Evaluate inside watsonx Orchestrate
The three new watsonx Orchestrate tools target different parts of the same problem. Discover, in tech preview, finds agents, models, and MCP servers already running across an organization's infrastructure, spanning Bedrock, Microsoft Foundry, and Google Gemini, which is a direct acknowledgment that most large enterprises already have agent sprawl across multiple vendors whether central IT approved it or not.
Contain, also in tech preview, sandboxes agents with an explicit kill switch, giving operations teams a way to isolate a misbehaving agent without taking down the systems around it. Evaluate, which is generally available rather than preview, handles agent quality and compliance testing on an ongoing basis. Shipping Evaluate as GA while Discover and Contain stay in preview tells us IBM considers ongoing compliance testing the more mature, demand-ready capability of the three, likely because compliance testing maps onto audit requirements enterprises already have to satisfy today, while discovery and containment are newer problems that most organizations have not yet standardized a process around.
What this signals about the agent governance market
Several vendors have talked about agent identity and governance this year. What sets this release apart is its breadth: identity, hardware-layer controls, multi-cloud discovery, sandboxing, and compliance testing all shipped in a single announcement rather than trickled out over several quarters. That breadth suggests IBM believes the market has moved past point solutions and into something enterprises want delivered as a coherent platform, bundled and supported together rather than assembled from several vendors' overlapping roadmaps.
We would treat this release as a signal to revisit any agent governance plan that still treats identity, discovery, and compliance as three separate future projects on three separate timelines. The vendors converging fastest on packaging all three together are the ones setting the baseline that procurement teams will start asking everyone else to match, and IBM has just set a fairly high one for the rest of the market to clear.
