IBM gives each AI agent an owner record and credentials that expire. The revocable credential is the control

Picture the 2 a.m. version of an agent incident. A reconciliation agent starts writing to a table it should only read. The on-call engineer wants to stop that one agent without stopping the twenty others that share its service account, and wants to know who approved its access in the first place. In most companies today, neither is possible quickly: the credential is shared and long-lived, and the approval lives in a ticket.

IBM’s TechXchange announcements on October 27 are built around that scenario. IBM Agent Identity and HashiCorp Vault 2.2, both generally available, split the problem into a record and a credential.

The layers

From owner record to revocable access

IBM Agent Identity

• Owner of each agent
• Lifecycle status
• Authority it was granted

The record: who answers for the agent

HashiCorp Vault 2.2

• Agent's own secured account
• Short-lived, scoped credentials
• Session revocation in real time

The control: what the agent can reach right now

Secure runtime (NVIDIA OpenShell)

• Policy-governed execution
• Traceable actions

Databases, APIs, operational systems

• Accept only the credential Vault issued

Agent Identity keeps an authoritative entry for each agent: who owns it, whether it is in development, production or retired, and what authority it was granted. IBM shares that context with Vault. That record is the mandate half of what we described as the two permissions an agent acting for the company needs: someone accountable granted it, for a scope, until a date.

Vault 2.2 gives each agent its own secured account, issues credentials limited to what that agent needs, renews them automatically and adds post-quantum encryption. When an agent tries something it is not authorized to do, access can be denied and the session revoked in real time. Both also integrate with NVIDIA’s OpenShell secure runtime, so actions can be traced back to a verified identity.

Why the credential matters more than the policy

Most agent governance today is written as policy: what the agent should do, which tools it may call, which data it may see. Policy is necessary, and we argued that agent governance needs several independent authorities. But a policy only helps at 2 a.m. if something enforces it on the next request.

A short-lived credential is that something. If credentials expire in minutes and are scoped to one agent, three things become true. Stopping one agent does not stop the others. A leaked credential is worth little after its lifetime. And the owner record gives the incident team a name to call. Microsoft’s latest threat report made the case that agents make weak IAM fail faster; per-agent, expiring credentials are the direct answer.

Read the status line

IBM’s release is specific. Generally available: Vault 2.2, Agent Identity, watsonx Orchestrate evaluation capabilities, IBM Concert and Terraform policy. In public preview: Secure Hub, the Terraform Developer Portal and the Terraform remote MCP server, among others. In tech preview: Orchestrate’s capabilities to discover and contain agents across platforms. Vault already secures non-human identities for organizations such as ABN AMRO, Adobe, BlackRock and Target, but that is established Vault usage, not adoption of the new agent features.

A test for any agent identity setup

Whatever stack you use, these four questions tell you whether agent identity is real or decorative:

1. Can you revoke one agent’s access without touching any other agent or human account?
2. Does every agent have a named owner who is still employed and still responsible?
3. How long does an agent credential live, and where is that number set?
4. Does the target system see the agent’s own identity, or a shared integration account?

If the answer to the last one is “a shared account,” start there. Every other control depends on knowing which agent made the request.