An agent’s identity alone does not tell a security team what the agent can do. The authority to act must be traced through each system it touches.

The big change

  • What changed: IBM’s October 27 release lists Agent Identity, Vault 2.2 and watsonx Orchestrate Evaluate as generally available. Discover and Contain are tech previews; Secure Hub is a public preview.
  • Why it matters: Vault’s registry, delegated policy ceiling and session claims narrow access at different points.
  • What to watch: Cross-platform coverage and attack outcomes remain unverified.

Availability is not one status

The version number needs care. HashiCorp’s Vault release notes date 2.2.0 to October 15 and 2.1.0 to September 1. They say native agentic workflow support left beta and became generally available in Enterprise 2.1.0.

Orchestrate’s TechXchange article describes evaluation and trace inspection; preview discovery names Amazon Bedrock, Microsoft Foundry and Google Gemini.

Follow the authority through Vault

HashiCorp’s agentic IAM documentation identifies three different records. A Vault identity entity identifies the client; an agent registry record says whether that entity is an approved agent and carries governance constraints; an OAuth resource-server profile defines which external token issuers Vault trusts. Vault validates a presented OAuth JWT, resolves the entity, checks registration and evaluates policies on the request. It derives metadata from the JWT for each request rather than storing a lasting Vault token for that flow.

For an agent acting on behalf of a person, the delegation documentation describes an intersection: the person’s baseline Vault policies, the agent’s on-behalf-of ceiling and the session’s Rich Authorization Request constraints. The RAR reference says its vault:path_access details can narrow a Vault path, operation and allowed parameters; they cannot add a permission denied by the baseline policy. This is an authorization decision at Vault.

IBM describes Verify as the delegation layer and Vault as a credential broker for targets that cannot accept delegated tokens. An operator should inspect both Vault’s decision and the target system’s rights and logs before treating an audit trail as complete. This is an inference from the documented boundary, not an observed integration result.

There are practical conditions behind the architecture. HashiCorp says agentic IAM is available in Vault Enterprise 2.1.0 or later and requires an appropriate Enterprise license; its IAM overview also names HCP Vault Dedicated. The setup documentation calls for a deployed Vault environment, a supported identity or OAuth provider and Vault administration rights. Its RAR documentation says a missing authorization_details claim is rejected by default, although operators can make RAR optional, weakening that per-session constraint. The consulted sources give no combined price or full feature entitlement map.

What a team can assess now

For Vault, inspect the registered agent, delegated subject, baseline policies, ceiling and session constraint. Then examine the credential and target permissions. HashiCorp’s agent registry documentation is explicit that a ceiling restricts delegated access and cannot enlarge the person’s permissions. These checks describe the documented control surfaces, not a test that BIG CHANGE ran.