> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # IBM Gives AI Agents Verifiable Identities and a Kill Switch - URL: https://debugly.dev/ibm-ai-agent-control-verifiable-identities-vault/ - Published: 2026-10-28T19:00:00.000Z - Updated: 2026-10-28T19:00:00.000Z - Description: IBM launched verifiable identities for AI agents, with access limits and instant revocation. HashiCorp Vault now controls agent access too. - Author: Rohit Bhadani - Tags: AI, DevOps IBM announced new capabilities for managing AI agents inside organizations, and the timing matters. Agents can now consult databases, use applications and initiate workflows on behalf of a user. If an agent is given more permissions than it needs, an error or an unauthorized action can have significant consequences. IBM's answer is to give each agent a verifiable identity, limit what it can touch, and make it possible to revoke that access quickly, including through HashiCorp Vault. The details here come from the IBM announcement reported 28 October 2026 via Aidapted and The Digital Pulse, plus Bank of America guidance on credential sharing with AI agents also reported 28 October. ## What did IBM actually ship? | Property | Detail | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Announcement | IBM AI agent control capabilities, reported 28 October 2026 | | Core capability | Verifiable identities for agents, not just users | | Access control | Limits on access to data and applications per agent | | Revocation | Ability to quickly revoke permissions per agent | | Discovery | Features for discovering and assessing agents used across different platforms | | Vault integration | HashiCorp Vault extended to control AI agents' access to credentials and digital secrets | | Why now | Agents can go beyond generating text and carry out concrete actions such as database lookups, app calls and workflow initiation | According to Aidapted, the tools include verifiable identities for agents, limits on access to data and applications, the ability to quickly revoke permissions, and features for discovering and assessing agents used across different platforms. IBM is also extending the capabilities of HashiCorp Vault, a system for securely managing credentials and digital secrets, so that it can be used to control AI agents' access. That last line is the signal for teams that already use Vault for human service accounts. The same issuance and revocation flow can now be applied to agents. ## Why does an agent need an identity at all? A service account has an identity. An AI agent that acts as a user often does not. It inherits the user's token, which makes audit logs ambiguous. A verifiable identity fixes that. The agent authenticates as itself with its own credential that can be issued, scoped, and revoked independently. I run Claude Code agents in disposable microVMs at [Krova Cloud](https://krova.cloud/?ref=debugly.dev) where each agent gets its own Vault token with a short time to live. Revoking one agent without revoking the user is the kill switch. ## How does HashiCorp Vault help with agent access? Vault already issues short lived credentials for human and machine workloads. Extending it to agents means the agent holds a scoped Vault token that can be revoked centrally, not a long lived key in its prompt. The pattern is least privilege plus short time to live. According to IBM, Vault will control agent access to credentials in the same way it does for existing workloads. The review I run is the same one from [agent credentials with least privilege](https://debugly.dev/agent-credentials-least-privilege/) and [agent sandbox checklist](https://debugly.dev/agent-sandbox-checklist/): what identity does the agent present and how quickly can I revoke it. ## What did Bank of America tell customers the same day? On 28 October Bank of America emailed customers not to share login credentials with AI tools that offer to act for them. If you share, you are responsible, an agent might act unexpectedly, and the bank may mistake agent activity for account takeover. That warning and IBM's announcement are two sides of the same week. ## What should teams implement this week? The checklist is short. First, inventory agents and the credentials they hold. Second, give each agent its own Vault token with a policy that lists exactly what it needs. Third, set short time to live and test revocation. Fourth, restrict the agent's ability to carry secrets in its context, as described in [debugging an agent that wont reproduce](https://debugly.dev/debugging-an-agent-that-wont-reproduce/). According to IBM, these capabilities are for identifying and controlling AI agents in companies. The same announcement notes that agents can initiate workflows, which is the capability that makes the control urgent. ## What is the verdict and what remains uncertain? According to IBM via Aidapted, verifiable identities plus Vault integration give enterprises a way to issue, scope, and revoke agent access in the same way they do for existing workloads. According to Bank of America, sharing user credentials with agents remains risky until those identities are in place. The verdict is that the week of 28 October marks the point where agent identity stops being a future concern and becomes a current control. The tools exist, the bank warnings are public, and the attack surface from ARTEX style autonomy makes shared credentials untenable. The limitations are threefold. First, IBM's announcement is a product announcement, not a deployment audit, and cannot be treated as a deployment. However, the capabilities must still be configured per platform. Second, discovery across platforms will be incomplete until every platform where agents run is inventoried, but early adopters can still scope the agents they know. Third, Vault integration helps only if the agent actually uses Vault for every secret. An agent that still carries a long lived key in its prompt bypasses the control and cannot be considered secured. ### FAQ **Do we need Vault to use verifiable identities?** No, but Vault makes the lifecycle practical. An identity without short time to live and revocation is just a label. Vault provides the issuance and revocation that make the identity enforceable. **Does this replace the need to patch PHP2Shell and Brotli?** No. Agent identity controls the agent. Patching controls the interpreter and the decoder. You need both. The same week that produced IBM's announcement also saw CISA add Brotli and Adobe flaws to its Known Exploited Vulnerabilities catalog. **What is the first step if we already run agents?** Inventory them. According to IBM, discovery across platforms is part of the launch. Start there, then issue one scoped Vault identity per agent and test revocation before you expand scope. --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev) --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev)