An AI agent that can query a customer record, draft a quote, change inventory, release a purchase order, or send a message is no longer just a software feature. It is an actor inside the business.

That actor needs a distinct identity. Otherwise, the audit trail may show only a shared service account or an employee credential—even when several agents, workflows, and users contributed to the action.

The practical goal is not identity technology for its own sake. It is the ability to answer four operating questions: Which agent acted? Who authorized it? What exactly was it allowed to do? How quickly can that authority be revoked without stopping the business?

What changed

On October 20, 2026, AWS published a reference architecture for securing AI-agent identity with X.509 public-key infrastructure. The architecture, developed with Keyfactor, uses separate agent credentials, signed request envelopes, user-signed delegation assertions, audience-scoped tokens, and real-time certificate-status checks.

Documented facts: AWS’s authors state that sharing API keys between components or passing the same OAuth token through an agent chain does not provide the identity separation expected in a zero-trust deployment. They also note that Model Context Protocol is transport-agnostic and does not itself supply a built-in authentication standard.

Vendor architecture, not a universal standard: The AWS post demonstrates one implementation using Amazon services and Keyfactor EJBCA. It does not establish that every business needs to deploy its own certificate authority, that X.509 is the only acceptable approach, or that the reference code has been independently validated for every production use.

Authoritative context: The NIST National Cybersecurity Center of Excellence is separately developing practical work around software- and AI-agent identity and authorization. NIST’s project materials focus on identification, authentication, authorization, auditability, non-repudiation, and limits on delegated authority. That work is still developing; it should not be described as a completed agent-identity standard.

Why a shared account is an operating problem

A shared credential collapses several different facts into one login. The business may be able to see that an ERP integration account changed a record, but not whether the action came from the quote agent, the purchasing agent, a background retry, a compromised component, or a person testing the workflow.

That ambiguity slows incident response and weakens approvals. It also makes least privilege difficult: every workflow using the shared account inherits the same access, even if one needs only product availability while another can create transactions.

Identity does not make an agent correct. It makes authority attributable, constrainable, monitorable, and revocable. Deterministic validation, human approval, and outcome reconciliation still decide whether an action should proceed.

The minimum agent-identity record

For each production agent or automated workflow, record:

• Unique identity: one identity per agent and environment, not one generic “AI” account.
• Business owner: the person accountable for the workflow, permissions, exceptions, and renewal.
• Human delegation: which user, role, or approved process authorized the agent to act.
• Permitted audience: the specific ERP, CRM, commerce, database, tool server, or API that may accept the credential.
• Allowed actions: read, draft, recommend, approve, create, update, release, refund, or delete—kept separate.
• Data scope: the customers, locations, business units, record types, and fields the agent may access.
• Credential lifecycle: how credentials are issued, stored, rotated, expired, and revoked.
• Evidence chain: user, agent, tool, input, validation result, approval, final write, and outcome.
• Emergency owner: who can disable the identity and who decides when it may return.
• Fallback: how the underlying work continues manually or through a deterministic process.

This belongs in the systems and workflow inventory, connected to the actual service account, application role, credential store, and incident procedure.

Turn identity into practical controls

1. Separate people, agents, and tools

Keep the employee’s login out of the agent runtime. Give each production agent its own non-human identity, then record the human or approved process that delegated the task. A downstream system should be able to distinguish the initiator, the agent, and the tool that performed the write.

2. Use short-lived, audience-scoped authority

A credential intended for the quoting API should not also work against email, file storage, or the general ERP interface. Prefer expiring credentials and narrow audiences over static secrets that remain valid until somebody remembers to rotate them.

3. Bind access to the business action

“Can access the ERP” is too broad. Define whether the agent can read price and availability, prepare a draft quote, create a sales order, release a purchase order, or post a refund. Use the smallest permission set that supports the approved workflow.

4. Validate the transaction, not just the login

A valid identity can still propose a bad action. Apply deterministic checks for customer, SKU, approved price source, margin, available inventory, duplicate risk, quantity limits, required fields, and policy constraints before a write is accepted.

5. Keep people at consequential gates

Require human approval for commitments, unusual substitutions, sensitive-data access, pricing overrides, purchases, refunds, destructive writes, and other actions with material financial or customer impact. The approval record should bind the person, agent, proposed action, and final transaction.

Design revocation before production

Revocation is the operational payoff of separate identity. If one agent behaves incorrectly or a credential is exposed, the business should be able to disable that identity without shutting down every integration that shares the platform.

Monitor authentication failures, unusual destinations, access outside normal hours, unexpected tool calls, privilege changes, repeated retries, and transactions outside the workflow’s normal volume or value. Alerts need a named owner and a decision path: investigate, restrict, revoke, contain, restore, or move to manual processing.

Test the sequence before launch:

1. Revoke or disable the agent credential.
2. Confirm new calls are rejected.
3. Preserve the delegation and transaction evidence.
4. Stop queued or retrying work without creating duplicates.
5. Move open exceptions to a named person.
6. Continue the business process through the documented fallback.
7. Issue new authority only after root cause and configuration review.

For an industrial automation workflow, that may mean continuing quote preparation or order entry manually while the agent identity is disabled. For commerce, it may mean leaving catalog and order systems available while pausing only the agent’s ability to change prices, refunds, or fulfillment records.

What remains unresolved

Agent identity is still an active standards and implementation area. Organizations should not assume that every vendor preserves a complete delegation chain, supports independent identities for multiple agents, exposes fast revocation, or logs the difference between a model decision and a tool execution.

Ask vendors direct questions: Can each agent receive its own identity? Are credentials short-lived? Can they be restricted to a tool and action? Does the audit log preserve the initiating human and the executing agent? How fast does revocation propagate? What happens to queued work? Can one agent be disabled without breaking the rest of the system?

Those answers belong in vendor and model-risk review before production access is approved.

The practical takeaway

Distinct agent identity is not a reason to slow adoption. It is what lets a business expand automation without losing accountability. Give every acting agent a unique identity, narrowly delegated authority, deterministic transaction checks, human gates where consequence warrants them, an evidence trail, monitoring, and a revocation path that preserves operations.

Bridge Road’s AI governance framework connects identity, permissions, approvals, validation, exception ownership, auditability, rollback, and manual fallback to the workflow itself—where the controls can actually be used.

Sources: AWS, “Securing AI agent identity with X.509 PKI on AWS,” October 20, 2026; NIST NCCoE, Software and AI Agent Identity and Authorization; NIST NCCoE, Summary of Comments on the Concept Paper.