AI Agent Identity Security: Enterprise Access Controls

AI agent identity security starts with knowing which agent is acting and enforcing what it is allowed to do. Before giving it production access, you should be able to trace its authority and show that requests outside its permissions are refused.

A working demo doesn't settle that. Your agent may have completed the task because someone gave it a developer's credentials or a service account with far more access than it needed. What happens when it tries something outside the job?

Take an agent that reads support tickets and drafts replies. That job doesn't require issuing refunds, exporting customer data or changing account permissions. If its credential permits those actions anyway, you've given a reply-writing agent the power to do much more.

Choose how the agent gets its authority

Name the person or team responsible for the agent. Then decide how it gets permission for each workflow. The software doing the work and the person authorizing it should remain distinguishable.

An agent acting for a signed-in employee can use delegated access. The application receives a limited grant to act on that user's behalf. A background agent may instead use its own workload or agent identity with explicitly assigned application permissions. Microsoft's agent authorization guidance distinguishes delegated permissions from application permissions.

A delegated grant gives an agent a defined way to act for someone. Copying that person's session cookie into an unattended process can carry much broader access and obscure who acted. Preserve the user and agent identities in the authorization context wherever your platform supports it.

For the support agent, an employee-approved response and a scheduled overnight ticket-classification job may need different grants. Development convenience is a poor reason for either job to inherit an administrator's access.

Record those decisions in your internal inventory. The Agent Registry Checklist covers what to record.

Give each credential a limited job

Prefer short-lived credentials and workload federation where the environment supports them. Keep secrets in the application's credential-handling components, out of prompts, public manifests and tool output. Where API keys are necessary, restrict their use and establish rotation and revocation procedures.

Google Cloud's agent security guidance recommends a dedicated agent identity with only the permissions needed for its tasks. It also describes service accounts, workload identity federation and restrictions for API keys.

Be specific about what the credential can reach. Permission to read one customer's ticket should not open every customer's tickets. Check tenant, customer and environment boundaries at the service that holds the data.

For OAuth access tokens, validate the trusted issuer, intended audience, validity period and applicable permissions. Use the verification method appropriate to the token format. Where supported, sender-constrained tokens bind use to a particular client key, making a stolen token less useful on its own. The OAuth security best current practice explains audience restrictions and token protection.

Show the agent how to authenticate with auth.md

An agent should not have to guess how a service expects it to authenticate. An auth.md file can describe the supported methods, registration steps and credential-handling requirements, with links to the service's authoritative metadata and API contract.

You can see this in the Headless Domains auth.md. It documents agent provisioning, API-key authentication and a claim flow for attaching an agent to a human account. It also explains how to keep the agent's API key separate from an MPP payment receipt when both accompany a request. Delegated and verified identity assertions are explicitly marked as planned.

For the registration flow and identity model behind the file, read how Headless Domains uses auth.md for AI agent registration and identity.

Check the instructions against what the service actually does. Can the client obtain the intended credential and use it on the correct endpoint? Does a request fail when the credential lacks permission? auth.md explains the process; the service has to enforce it. Keep actual credentials and claim codes out of the public file. Its instructions must not override your own access policies.

Enforce permissions when the action happens

A prompt saying "never issue refunds" is an instruction to the agent. The refund service still needs an access rule that blocks unauthorized refunds.

Enforce policy outside the model, at the protected service or another enforcement point that the agent cannot bypass. Check the requested action and its arguments against the actual grant. An accepted credential is not blanket permission for whatever the agent asks next.

When a sensitive action requires human approval, bind that approval to the details that matter. For a refund, those include the customer, amount and transaction. If those details change, require a new decision rather than reusing a vague approval to "handle the ticket."

If the support agent hands work to another agent, check the receiving service's permissions too. A forwarded task description is no proof of delegated authority.

For remote HTTP-based MCP services, follow the applicable authorization flow and validate that tokens are intended for the receiving resource. The MCP authorization specification distinguishes HTTP authorization from local STDIO credential handling. Use the separate MCP Security Checklist when assessing a server before connecting it.

Test the requests your agent should not complete

Before release, test with synthetic data in a non-production environment. Start with a request that should succeed. A service that rejects everything may simply be broken. Then try the actions your agent has no business completing.

These cases give our support agent a starting point. Add tests for the resources and permissions in your own workflow.

If an injected instruction fails to trigger an export, you've shown that the tested access rule held. The model may still be vulnerable to other manipulation. Rerun the relevant tests when tools, permissions or enforcement behavior change.

Make the decision traceable

For each important action, retain the agent or workload identifier, delegating user where applicable, target resource, operation, policy decision, timestamp and outcome. Record the approval reference when one was required. A correlation identifier should let reviewers follow the request through downstream services.

Keep credentials and unnecessary customer content out of logs. Protect audit records from alteration and limit who can read them. Logging that an action was attempted is different from confirming that it completed, so record both the decision and the result.

Disable the agent's access and test what happens next. Don't assume every issued token stops working immediately. Existing tokens, sessions and cached decisions may remain usable until their expiry or the relevant revocation mechanism takes effect. Decide how quickly access needs to stop, then measure the actual delay. The AI Agent Offboarding guide covers retirement, while Agent Access Review handles recurring reassessment.

Give external users a public identity they can inspect

For an agent that customers or partners encounter outside your organization, a Headless Domains identity can provide a persistent public reference. Its records can point to the operator, official interfaces, verification information and current status.

Keep that public information consistent with the service you actually operate. A public declaration of permissions is not an access grant, and marking a profile inactive does not revoke a credential. Headless Domains' resolver contract explicitly separates identity and action discovery from authorization and execution.

Internal agents do not need a public domain to be secured. When public discovery is useful, publish information others need to inspect without exposing secrets, private endpoints or customer data. The broader Agent Identity Stack explains how that public reference relates to the rest of the system.

Before approving production access, ask for the test results. The support agent should be able to draft its reply, and the refund request should fail unless separately authorized. When customers or partners encounter that service, give them a maintained public identity they can inspect.

Set up a Headless Domains identity for your public-facing agent.