IBM Just Gave Agents Their Own Identity — Stop Sharing Service Accounts With Software

IBM Just Gave Agents Their Own Identity — Stop Sharing Service Accounts With Software

2026-10-03

IBM just made a quiet but important move in watsonx Orchestrate: Agent Identity, now in preview, gives each agent a unique, verifiable identity managed through the identity provider your security team already runs — IBM Verify or Microsoft Entra in the private preview (IBM).

Same release also stretches the AI Gateway across Microsoft Foundry and Google Gemini Enterprise Agent Platform (on top of Amazon Bedrock), so multi-cloud agent sprawl can sit in one inventory with one policy set. The headline owners and operators should hear is not “IBM shipped another control plane.” It is: stop letting agents borrow human credentials and hope the audit log sorts it out later.

The operator takeaway

If an agent can act, it needs its own identity, least privilege, and a kill switch in the IdP — the same way you treat a privileged service, not a chat widget.

Most teams still authenticate agents with shared service accounts, static API keys, or the user’s own credentials. That makes it hard to tell what a person did from what software did on their behalf, and it usually over-grants access for the task at hand. IBM’s framing is blunt: a distinct agent identity, short-lived tokens scoped to the task, and an audit trail that keeps the link between the requesting user, the agent, and the tool it called (IBM).

Why this matters if you are not on watsonx

You do not need to buy IBM to absorb the lesson. Agent identity is becoming table stakes wherever agents touch Workday, Salesforce, email, or finance systems. If your current design is “the agent runs as Alice,” you have already decided that every agent failure is Alice’s blast radius.

The multi-cloud piece is the second half of the same story. Enterprises build agents on more than one platform. Platform-native tooling only governs what lives on that platform. A cross-cloud inventory plus shared policies is how you find duplicate agents, retire the ones nobody owns, and stop pretending each cloud’s console is a security program (IBM).

A practical agent-identity checklist

  1. Inventory agents like services. Name, owner, purpose, platforms, data classes touched, and last review date. If it is not on the list, it does not get production credentials.
  2. Ban shared “agent” service accounts for anything sensitive. One agent, one identity. If you disable that identity in the IdP, the agent stops. Shared keys are how “temporary automation” becomes permanent liability.
  3. Scope tokens to the task, not the user. Prefer short-lived, narrowly scoped credentials over inheriting Alice’s entire SaaS admin entitlements. Over-privilege is the default failure mode of agent demos.
  4. Keep a three-party audit trail. User who requested → agent that acted → tool that executed. “Alice accessed Workday” is not enough when Alice’s agent did it while Alice was in a meeting.
  5. Put evaluation cost where risk lives. IBM’s same drop also lets tenants tune LLM-as-a-Judge sampling (toxicity, hallucination, helpfulness, and friends) instead of evaluating everything at full rate. That is an ops budget lever, not a science project — spend evaluation where reputational or financial risk concentrates (IBM).
  6. Align CIO / CISO / CTO ownership early. Identity and access is usually CISO or CIO turf. Agent product design is CTO turf. If those seats do not share one policy, you get shadow agents with VIP keys. For how those roles split in smaller companies, see CIO vs CTO vs CISO.

Build vs buy without the theater

You do not need a full multi-cloud agent control plane tomorrow. You do need a stance:

  • Buy / adopt platform identity features when agents already write to production systems of record.
  • Build process first when you are still in human-watched pilots — but design the identity model before you widen blast radius.
  • Avoid “we’ll just use the founder’s API key” as a temporary plan. Temporary keys are how incident timelines start.

Soft next step

Yellow Coop helps owners and operators put fractional CTO / CISO judgment around AI agents: who owns them, what they can touch, and how you prove it after the fact. If agents are starting to look like coworkers with admin rights, we can help you give them identities before they inherit yours. Start at contact.

Internal links: Secure, What We Do, How We Engage, CIO vs CTO vs CISO, Insights.

Sources