AI Agent Identity: Why Every AI Agent Needs Its Own Login (IBM watsonx Orchestrate)

Most companies rolling out AI agents have not decided who an agent is when it logs in to a system. IBM’s latest watsonx Orchestrate update puts that question in front of every team doing an AI digital transformation.

On October 2, IBM published its September release notes for watsonx Orchestrate. Two items matter beyond IBM customers: Agent Identity, now in preview, and an AI Gateway that can find agents built on other clouds. This post explains what AI agent identity is, what IBM says it does, and what you can do about it today, whichever platform you use.

What Is AI Agent Identity?

IBM defines an agent identity as a unique, verifiable enterprise identity assigned to an AI agent, separate from the identity of its creator, owner or end user.

The problem it addresses is common. IBM notes that many agents today sign in with shared service accounts, static API keys or a user’s own credentials. That makes it hard to tell what a person did from what an agent did for them. The agent can also inherit more access than the task needs.

IBM lists three risks that follow:

• Limited traceability: security teams cannot reliably tell an agent’s actions from a user’s.
• Overprivileged access: an agent may hold broad, standing permissions.
• Limited authorization control: it is hard to say which agents may act for which users, and for which sensitive operations.

What Did IBM Announce?

Here is what IBM’s own announcement says. These are vendor claims about vendor features, not independent test results.

• A separate identity per agent. Each agent can be registered with the identity provider you already use. IBM says the private preview supports IBM Verify and Microsoft Entra. If an agent’s identity is disabled there, the agent can be stopped from running.
• Access scoped to the task. Instead of inheriting all of a user’s permissions, an agent can get a short-lived token limited to the task. IBM’s example: a user may have admin access to an HR system, but an agent that lists open positions only needs read access.
• A clearer audit trail. The record can show that a specific agent accessed Workday on a user’s behalf, not just that the user accessed Workday.

Two other items in the same release are worth knowing about. The watsonx Orchestrate AI Gateway can now discover and import agents built on Microsoft Foundry and Google Gemini Enterprise Agent Platform, in addition to Amazon Bedrock (preview, released September 15). And six built-in LLM-as-a-Judge evaluators now run against live agent traffic (generally available September 30). IBM says the default sampling rate is 3% and admins can raise it to 20% per evaluator, which makes sampling a cost control.

Agent Identity is a preview, so treat it as a direction rather than something every company can switch on today. IBM’s September 21 post calls it a private preview, and its October 2 post says “now in preview”.

Why Does This Matter for an AI Digital Transformation?

Early AI projects are often one agent, one team, one set of credentials. That works for a pilot. It breaks when you have agents in finance, HR and support, built by different teams on different clouds, each holding keys nobody tracks. IBM’s own framing is that most large enterprises build agents on more than one cloud.

Our view, not IBM’s: this is the point where a pilot turns into an operating model. A business can only trust agents with real work if it can answer four questions, which IBM also frames for security teams:

1. Who is the agent?
2. What is it allowed to do, and under whose authority?
3. What access did it actually get at runtime?
4. What did it do, and for whom?

You do not need watsonx Orchestrate to ask them. IBM is one of several vendors working on agent governance. The same week, Oracle announced Fusion Claw, a governed execution runtime for its Fusion Agentic Applications, which Oracle says supports 25 new agentic applications.

What Should You Do Before Agents Touch Your Systems?

A practical checklist, based on our own project experience rather than any vendor’s roadmap:

• Make an inventory. List every agent, who owns it and which systems it can reach.
• Stop using personal credentials. An agent should not run on an employee’s login or a shared API key.
• Scope access to the task. Start read-only and add permissions only when a workflow needs them.
• Log the agent and the person. Every action should record both who asked and what acted.
• Keep a kill switch. You should be able to disable one agent without touching the rest.
• Sample and review runs. Decide which quality and safety checks run on live traffic, and how often.

How Incresco Helps

Incresco does AI digital transformation. Our AI transformation work covers the pieces described above:

• AI strategy and consulting: roadmaps, readiness assessments and the business case, so you pick the right process first.
• Custom AI development: AI agents, copilots and intelligent automation built around your workflows.
• AI integration: connecting AI to your existing systems through workflow automation, API integration and legacy system modernisation.

If you want to plan where agents fit in your operations, and how they should sign in and be monitored, talk to our team.