IBM gives AI agents their own identities—and separates permission from containment

An AI agent can produce the correct answer and still have too much power. Consider a purchasing assistant that only needs to check an invoice but has credentials allowing it to change a supplier’s bank details. Better reasoning would not remove that unnecessary permission. The system needs a separate way to decide who the agent represents, what it may do and when its authority ends. This is an illustrative deployment problem, not an incident reported by IBM.

IBM’s 26–27 October announcements address those layers separately. Agent Identity is now generally available; the company’s new discovery and containment capabilities have preview status. Treating the whole announcement as one finished security product would obscure what enterprises can actually deploy today.[1][2]

An identity is more than a service account

Agent Identity combines registration, delegated access and lifecycle governance. IBM describes an inventory with named owners and approved connections, a chain showing on whose behalf an agent acts, and short-lived tokens for particular tasks. Verify supplies identity policy; Vault can broker credentials where a destination cannot consume delegated tokens directly. The intended audit trail connects the person, agent, credential and action.[1]

The design distinction is important. Giving an agent a name makes its activity recognisable. Giving it only the authority needed for a particular transaction limits what that activity can become. Recording who delegated that authority addresses a third question: accountability. A system can satisfy one of these requirements while failing the others.

The TechXchange release also describes temporary credentials and rotation, plus containment using isolated execution environments. Its discovery programme extends to agents, models and Model Context Protocol servers across supported third-party platforms. These are IBM’s descriptions of product capabilities, not results from an independent security test.[2]

The useful test is a failed transaction

Orchestrate’s evaluation features include custom model-based judges, simulated interactions, deterministic checks of tool calls and parameters, and trace inspection. IBM also describes an AgentOps agent that helps investigate failures and generate tests before changes are promoted. Those facilities concern behaviour and observability, rather than replacing the identity layer.[3]

A meaningful acceptance exercise would therefore start with an agent that is deliberately asked to do something outside its remit. In the invoice example, can it read an approved document but not alter payment instructions? Does stopping it revoke the relevant credentials as well as terminate its current process? Can a reviewer reconstruct which user authorised the operation without searching several unrelated logs? These are proposed tests, not tests this publication has performed.

They also expose why a dashboard is not enough. Discovering an agent does not prove that every tool it can call is controlled. Ending one runtime does not, by itself, establish that a credential copied elsewhere has expired. A useful buying decision should distinguish visibility, authorisation, revocation and execution isolation instead of accepting a single broad claim that an agent is governed.

For enterprises evaluating the release, the strongest question is consequently narrow and operational: show one business action that is permitted, one that is denied, and the evidence connecting both decisions to an accountable owner. That demonstration would say more about usable control than the number of agents listed in a catalogue.

Report an error or suggest a correction