AI Agent Identity and Governance: Who Can Authorise an Agent's Actions?

An AI agent can search a document repository, update a CRM record or call a financial application. Each action brings a question that the agent's instructions cannot answer on their own: whose authority is it using?

The answer determines which data it can reach, who approves a change and whether the organisation can identify the person and software involved afterward. IBM's Agent Identity releases in October and November 2026 have made this a current product decision. The underlying controls apply equally to agents built on other platforms.

What is an AI agent identity?

An agent identity is a way to identify a software agent independently of the person who uses it and the application credentials it holds. A useful implementation ties that identity to an owner, a workload or environment, and the permissions needed to perform its assigned work. The organisation must also be able to revoke those permissions when the agent is retired or compromised.

This distinction becomes important when several agents call the same business application. A shared service account may authenticate all their requests, but the application's audit log will often show the account rather than the individual agent. Additional logs might establish which agent initiated an operation, although that requires reliable correlation across systems.

NIST's 27 October 2026 design tenets propose distinct, verifiable agent identification and a traceable link to the person or organisation that initiated a task. These are proposed design tenets, not a new compliance certification or a claim that every platform already implements them.

Delegated access or application-only access?

The correct access pattern depends on who is authorising the work. With delegated access, a signed-in person asks the agent to act, and the downstream application should enforce that person's permissions. With application-only access, an unattended workload operates through its own assigned permissions, without a user signing in for each action.

Both patterns are legitimate. Neither gives the agent unrestricted authority. An agent that retrieves information for a user should respect the user's access to that information. An agent performing scheduled maintenance should have a narrowly scoped application identity and an accountable owner. Microsoft documents delegated access, application-only access, managed identities and service principals as distinct choices.

For each tool, record the permitted operation and resource scope. Reading an approved document library, editing specified CRM fields and administering user accounts are different privileges. An identity provider may issue the token, but the receiving service still has to check what that token is allowed to do.

Who authorises an AI agent to change business data?

The agent should request an action; an enforceable policy should decide whether the action is allowed. That decision belongs in the receiving application, an API gateway or another trusted control outside the language model. A prompt instructing the agent to seek approval cannot replace a server-side permission check.

A useful policy check considers the requesting user, agent identity, target tenant, resource, operation and granted scope. For a consequential change, it may also require a named approver. The approval should identify the particular operation and its affected records, rather than give the agent general permission to proceed.

Timing matters. If the record or proposed operation changes between approval and execution, the system should reject the stale approval or ask for a fresh one. The same enforcement must apply when the tool is invoked through an API, a scheduled workflow or another agent. Otherwise, a second execution route can bypass a control that appears to work in the chat interface.

NIST's proposed tenets explicitly call for deterministic access decisions and delegated permissions that narrow, rather than expand, when work passes to another agent or service. This gives teams a concrete acceptance test: a downstream tool should not gain authority its caller never had.

What IBM Agent Identity offers as of November 2026

IBM announced general availability of IBM Agent Identity on 26 October 2026. The product brings agent registration, ownership, delegation and governance into the IBM Verify identity portfolio. Its earlier preview announcement should no longer be used to describe the current status.

On 3 November, IBM also made Agent Identity generally available in watsonx Orchestrate. In the supported setup, agents can have their own identities registered through IBM Verify or Microsoft Entra. When an agent calls an enterprise tool for a user, OAuth token exchange can preserve both the agent and user context for the receiving service.

The 3 November release describes agent-specific access logs and a kill switch. An administrator can trace an agent's tool activity and undeploy it to end active sessions. That stops further activity in the Orchestrate environment; it does not automatically undo a record already changed in another application.

These are IBM product capabilities, not evidence that Phases has delivered an Agent Identity deployment. Buyers should verify the supported Orchestrate version, connected identity provider, imported-agent support, licensing and the permissions enforced by each downstream application. A broad product announcement is not a substitute for testing the specific workflow.

What must the audit trail show?

The record should make it possible to follow an action from request to result: the initiating user or workload, the agent, the policy decision, the tool and target resource, and the outcome reported by the receiving system. Recording that an agent asked to update a field is insufficient if the application never confirmed that the change was committed.

A useful test is to compare the agent's activity log with the receiving application's log for the same operation. Both should identify the event through a correlation identifier or another reliable linkage. The team should also check rejected requests, expired approvals, retries and partially completed operations.

Keep the evidence independent of the agent's editable conversation history. NIST recommends tamper-evident records, while Microsoft's guidance calls for tracing the user, agent, tool, policy decision and final outcome. Logs also need access controls and retention rules; tokens, secrets and unnecessary personal information should not be stored in traces.

Five acceptance checks before connecting an agent to production

Choose one proposed agent, one target application and one action it must perform. The review should produce answers to these questions, backed by configuration or test results.

1. Identity and owner

What identity will the target system recognise? Who owns the agent, approves access changes and can disable it? Record whether the agent uses a distinct identity, a managed workload identity or a shared credential.

2. Permission boundary

Which records, fields and operations can the tool access? Test a permitted action and an action outside the assigned scope. The second request should fail at the service or policy layer, irrespective of what the agent says.

3. Approval and delegation

Which actions need an authorised person? Check the same tool through every supported execution route, including scheduled or delegated calls. Denied, expired and altered approvals should not produce a write.

4. Audit and recovery

Can the operations team link the request, decision, tool call and committed result? Test what happens when the action is retried, only partly succeeds or the agent is disabled. Record which external changes need manual correction.

5. Operational responsibility

Who reviews access periodically, investigates unexpected activity and updates the controls when the API or identity provider changes? Assign these duties before deployment, with a documented handover.

What should an implementation estimate include?

The price of an agent platform does not account for the entire access-control workload. An estimate needs to cover identity-provider configuration, tool permissions, approval enforcement, integration changes, audit correlation, failure testing and operational support. Existing enterprise IAM and API-management capabilities may reduce the work, but their suitability has to be checked.

Ask the implementation team to separate built-in product functions from configuration and custom development. The acceptance checks above can then become a defined test scope. The useful budget measure is the cost of making a specified business action safe to operate and support, rather than the number of agents a licence permits.

Review an AI agent's access requirements with Phases

Phases develops and integrates enterprise applications, including AI-enabled workflows that use existing business systems. For this kind of project, a useful starting point is a review of the agent's target application, access model and proposed write action.

The review can establish what the existing platform already provides, where permission or approval enforcement needs development, and which tests should be included in delivery and handover. To make the discussion productive, bring the identity provider in use, the application's integration method and one operation you want the agent to perform.

Discuss an AI agent integration and access review with Phases.

AI Agent Identity and Governance: Who Can Authorise an Agent's Actions?