The question that stalls deployments. When an agent pilot goes to review, the hard question is rarely about the model. It is about credentials: whose permissions is this thing using? In most pilots we see, the honest answer is a shared service account, or a human's login borrowed "temporarily". That works in a demo. In front of a risk officer it collapses, because the organization cannot say who did what, on whose behalf, with what authority.
Why borrowed credentials fail audit. A shared account leaves a trail that says the account acted, not which agent, for which user, under which policy. It is over-provisioned by design, because it has to serve every case the agent might touch. And when something goes wrong, you cannot tell an agent error from a prompt injection from plain human misuse, since they all wear the same badge. A regulator asks two questions: what did the agent do, and what could it have done? With borrowed logins, neither has a clean answer.
What agent identity means concretely. Each agent gets its own verifiable identity in the same directory that manages your employees. Credentials are short-lived tokens scoped to the task at hand, not standing passwords; secrets come from a vault under least privilege. Every call is recorded as a triple: the user the agent acts for, the agent itself, and the tool it invoked. And the agent's entitlements are deliberately narrower than those of the human it assists, because software that never gets tired also never hesitates.
The platforms are catching up. This is no longer a custom build. In watsonx Orchestrate, Agent Identity has been in preview since September: identities issued through IBM Verify or Microsoft Entra, task-scoped tokens, and an audit trail linking user, agent and tool. At TechXchange, IBM added credential management with HashiCorp Vault and a governed catalog that evaluates MCP servers and agents before adoption, down to details like rejecting default credentials and validating tool schemas. Availability labels vary, so check status before you plan around a feature. The direction, though, is set: identity is becoming part of the platform, not an afterthought.
The rules we apply. Treat agents as employees in IAM terms. They join, they change roles, they leave, and each step has the same lifecycle discipline: entitlement reviews, deprovisioning, no orphaned accounts — at fleet scale, this is the difference between an inventory and an incident log. One identity per agent, not one per platform. And the entitlement conversation happens before the pilot, not after, because retrofitting identity into a running agent is the most expensive way to build it, and the fastest way to stall in review for months.
Closing. An agent with its own identity turns "trust me" into "check for yourself". That is the difference between a pilot that impresses and a deployment that passes review. We run identity and entitlement design as the first workshop of every agent engagement.