How to Give AI Agents Identity Without Sharing Human Credentials

TL;DR

An AI agent should never authenticate to enterprise tools by borrowing a human password, copying a browser session, or carrying one broadly privileged user token through an entire workflow.

The stronger pattern combines a dedicated workload identity for the agent, explicit delegated authority when a user is involved, token exchange for each downstream resource, short-lived credentials, per-tool permissions, and audit records that preserve both the requesting subject and the acting agent.

The central design principle is simple:

The agent must have its own identity, even when it is acting with someone else’s authority.

Introduction

The moment an AI agent can call a tool, identity stops being a login problem and becomes an architecture problem.

A conventional application usually has a predictable security relationship. A user signs in, the application receives an authorization grant, and the application calls a known set of services. An agent can be far less predictable. It may interpret a request, retrieve data, choose between tools, hand work to another agent, retry failed operations, or initiate an action that was not explicitly named in the original prompt.

That flexibility is useful, but it creates a dangerous shortcut.

Teams often give the agent whatever credential already works. That might be a shared service account, a developer API key, a copied personal access token, a browser cookie, or a long-lived OAuth refresh token belonging to a human administrator.

The integration works, but the security model collapses.

The downstream system may no longer know whether an action came from the user, the agent, the agent developer, or an automation platform. Revoking one user may break every workflow. A compromised agent can inherit months or years of accumulated human permissions. Audit logs may record the wrong actor, and the credential may remain valid long after the agent run has ended.

Production agents need a different model. They need identities that are independently attestable, revocable, observable, and restricted to the tools and actions the agent is permitted to use.

Agent Identity Is a Chain, Not a Single Login

An agent transaction can involve several distinct security principals.

Identity element	What it represents	Example
Requesting subject	The human or system that initiated the task	An engineer requesting an incident summary
Agent identity	The software workload interpreting and executing the task	Production operations agent
Runtime identity	The deployed process, pod, VM, function, or agent service	Agent deployment in the production namespace
Tool identity	The client recognized by a downstream tool	Approved ITSM tool connector
Resource owner	The party whose data or authority is being accessed	The requesting engineer or business unit
Approver	The person or workflow authorizing a high-impact action	Change manager approving remediation

These identities may sometimes map to the same platform object, but they should not be conceptually collapsed.

Authentication answers what is making this request.

Authorization answers what that identity may do.

Delegation answers whose authority the actor is carrying.

Policy answers whether this specific action is allowed under current conditions.

A credential is only the cryptographic evidence used to prove part of that relationship. It is not the complete identity model.

The Reference Architecture

The recommended pattern separates the human identity, the agent identity, the policy decision, and the credential used at each tool.

The agent begins with a workload identity issued by the environment in which it runs. When a user is involved, the authorization layer also evaluates that user’s delegated authority. Before the agent calls a tool, an authorization broker creates or retrieves a credential that is limited to the intended resource and operation.

The important detail is that the agent does not receive one universal credential.

Each tool receives a credential intended for that tool, with only the permissions required for the current operation.

Separate the Agent’s Identity From Its Authority

An agent identity should describe the workload itself. Authority should describe what that workload may do in a particular context.

This separation supports three primary operating patterns.

Agent-Owned Authority

The agent acts as itself using permissions assigned directly to its workload identity.

This pattern is appropriate for tasks such as:

• Reading an approved knowledge repository
• Collecting platform inventory
• Querying non-user-specific metrics
• Processing a scheduled data pipeline
• Publishing an approved operational report
• Executing a tightly controlled background task

The downstream system should record the agent as the principal.

A human identity may have initiated the workflow, but the permission comes from the agent’s own role. The user should not be able to expand the agent’s authority merely because the user has broader permissions.

User-Delegated Authority

The agent acts on behalf of a user, but the agent remains visible as the actor.

This pattern is appropriate when the action depends on the user’s identity or data boundary:

• Reading the user’s calendar
• Accessing documents the user is permitted to view
• Creating a ticket for the requesting user
• Querying records within the user’s regional or departmental scope
• Preparing an action that requires the user’s consent

The downstream authorization decision should consider both identities:

• The user is the subject whose authority is being delegated.
• The agent is the actor using that delegated authority.

The resulting permission must not exceed the intersection of the user’s authority, the agent’s approved capabilities, and the policy attached to the target tool.

Effective permission =
    user permission
  AND agent permission
  AND tool policy
  AND current context

A highly privileged user should not automatically turn a moderately trusted agent into a highly privileged agent.

Workflow Authority

The agent does not receive direct permission to perform the final action. It can only submit a request to an approved workflow or automation service.

This is often the strongest pattern for production changes.

The agent might be allowed to:

• Create a change request
• Select an approved runbook
• Supply validated parameters
• Attach diagnostic evidence
• Request human approval
• Monitor the workflow outcome

The automation platform then uses its own controlled identity to perform the approved operation.

This design separates agent reasoning from production execution. It also lets the workflow platform enforce change windows, approvals, rollback requirements, and command allowlists.

Use Workload Identity as the Agent’s Base Identity

Every production agent should begin with a non-human workload identity.

The identity should be issued based on evidence about the deployed workload, not manually copied into a configuration file. Depending on the platform, that evidence might include:

• Kubernetes namespace and service account
• Pod, node, or cluster attestation
• Cloud workload identity
• VM or instance identity
• Serverless function identity
• Signed deployment metadata
• SPIFFE workload attestation
• An approved agent runtime registration

The identity should map to a unit that can be independently governed.

Creating one identity for every model invocation would usually be too granular. Sharing one identity across every enterprise agent would be far too broad. A practical identity boundary is normally the independently deployed and independently revocable agent service.

For example, a production incident-triage agent should not share an identity with:

• Its development environment
• A general employee chatbot
• A finance assistant
• A remediation agent
• A test harness
• A developer workstation

The agent identity should also carry or resolve to useful policy attributes:

Attribute	Why it matters
Agent identifier	Identifies the approved agent service
Environment	Separates development, test, and production
Owner	Establishes operational accountability
Deployment version	Correlates behavior with released code and instructions
Risk tier	Drives approval and monitoring requirements
Allowed tool classes	Prevents unapproved integrations
Data boundary	Restricts accessible information
Runtime location	Supports network and residency policy
Attestation state	Confirms the workload is running in an approved environment

The model name alone is not an identity. Neither is the prompt name, framework name, or API client label.

Identity belongs to the operating workload.

Exchange Tokens Instead of Forwarding Them

A common agent anti-pattern is direct token forwarding.

The application receives a user access token and passes that same token to the agent. The agent then sends it to one or more downstream tools.

This is risky for several reasons:

• The token may have been issued for a different audience.
• It may contain more scopes than the tool requires.
• Every downstream component gains access to the original credential.
• Token theft has a larger blast radius.
• The tool may see only the user and lose visibility of the agent.
• A compromised tool could replay the token elsewhere.
• Revocation and incident reconstruction become difficult.

OAuth token exchange provides a better conceptual pattern.

The authorization service receives evidence of the requesting subject and the acting workload. It evaluates the target resource and requested permissions, then issues a new token suitable for that specific downstream call.

A simplified request can be represented as follows:

token_exchange:
  subject_token: user-delegation-token
  actor_token: agent-workload-token

  requested_resource: itsm-production
  requested_scopes:
    - tickets.read
    - tickets.create

  context:
    agent_id: service-desk-agent
    environment: production
    run_id: run-84271
    purpose: user-requested-ticket

The authorization service should then apply policy such as:

Is the user permitted to create this ticket?
Is this agent approved to use the ITSM tool?
Is the token intended only for the ITSM service?
Are the requested scopes necessary?
Is the user currently active?
Is additional approval required?
Is the workload attestation valid?
Is the request occurring in an approved environment?

A successful response should contain a new, short-lived credential. It should not expose the original user credential to the downstream tool.

Token exchange is not automatically secure merely because an exchange endpoint exists. The authorization server must validate both identities, constrain the target resource, reduce permissions, and enforce the organization’s delegation policy.

Prefer Delegation Over Impersonation

Delegation and impersonation can look similar operationally, but they produce very different accountability.

With delegation, the agent retains its own identity while acting for another subject.

Subject: engineer-104
Actor: incident-agent-prod
Action: create incident ticket

With impersonation, the agent is treated as though it were the subject.

Subject: engineer-104
Actor: not visible to the tool
Action: create incident ticket

Impersonation creates several risks:

• The tool may attribute the action entirely to the human.
• The agent’s involvement may disappear from downstream audit records.
• The agent may inherit the user’s full authority instead of a limited subset.
• Incident responders may be unable to distinguish human actions from agent actions.
• A malicious or compromised agent may make activity look like legitimate user behavior.
• Approval systems may incorrectly assume the user directly performed the operation.
• Multi-agent handoffs can turn into untraceable authority chains.

Delegation should therefore be the enterprise default.

The issued credential or supporting audit context should preserve both the subject and the actor. If several agents participate, the system should preserve the relevant delegation chain without creating an unbounded identity history inside every token.

Some platforms use the word impersonation for mechanisms that still retain the original caller in central audit logs. Architects should evaluate the actual semantics instead of relying only on product terminology.

The key questions are:

• Does the target tool know that an agent acted?
• Can the original requesting subject be identified?
• Can the agent be revoked independently?
• Is the granted authority narrower than the subject’s full permission set?
• Can the authorization decision be reconstructed later?

An approved agent should not automatically receive access to every tool registered in its orchestration framework.

Tool availability and tool authorization are separate decisions.

The model may know that a tool exists without being permitted to invoke it. The agent runtime may be permitted to invoke a tool without being authorized for every operation exposed by that tool.

A useful policy evaluates multiple dimensions.

Policy dimension	Example
Agent	Only the production service-desk agent
User	Only active employees in supported departments
Tool	ITSM ticket connector
Action	Create ticket, not delete ticket
Resource	Production ITSM tenant
Object	Tickets associated with the requesting business unit
Data classification	Internal operational data only
Environment	Production agent runtime
Time	Within approved support hours
Transaction limit	No more than 20 creations per run
Approval	Required for emergency severity or privileged routing
Network path	Calls must traverse the approved tool gateway

Scopes are useful, but scopes alone are rarely sufficient.

A permission such as tickets.write may still be too broad. A more useful control distinguishes between:

• Creating a new ticket
• Editing a ticket the agent created
• Editing any ticket
• Assigning a ticket
• Changing severity
• Closing a ticket
• Deleting a ticket
• Accessing restricted attachments

Per-tool permissions should reflect business operations, not merely API endpoint structure.

Keep Credentials Short-Lived, Resource-Bound, and Non-Exportable

Long-lived credentials are especially dangerous inside agent systems because agents interact with prompts, tools, traces, logs, memory systems, and third-party libraries.

A production credential profile should include the following controls.

Short Lifetime

The credential should live only long enough to complete the intended operation or workflow stage.

Read-only queries might use a credential valid for several minutes. A high-impact action may use a single-use credential that expires almost immediately after approval.

Long-running workflows should obtain new credentials at controlled checkpoints rather than receiving one durable token at the beginning.

Resource or Audience Restriction

A token issued for the ticketing system should be rejected by the source-code platform, cloud API, database, and automation service.

Audience validation must occur at the receiving tool. Issuing an audience claim without validating it does not provide protection.

Reduced Scope

The credential should contain only the actions required for the current tool call.

Do not issue a token that combines knowledge retrieval, ticketing, cloud administration, and deployment permissions merely because the agent might need one of those capabilities later.

Sender Constraint

Where the platform supports it, bind the token to cryptographic material held by the approved workload. Mutual TLS or proof-of-possession mechanisms can make a stolen token harder to replay from another process.

Memory-Only Handling

The agent should not write credentials to:

• Prompt context
• Conversation history
• Model memory
• Tool parameters
• Trace attributes
• Error messages
• Local files
• Source repositories
• Debug output

The safest design keeps the credential inside a broker, gateway, or secure runtime component that performs the authenticated call without exposing the raw value to the model.

Restricted Refresh Behavior

Autonomous agents should not receive broadly scoped, durable refresh tokens by default.

When continued access is necessary, the broker should reassess the user, agent, resource, policy, and workflow state before issuing another access token.

A credential broker separates agent reasoning from credential handling.

The agent requests a business operation. The broker determines which identity and authorization model applies, obtains the necessary credential, calls the downstream tool, and returns a filtered result.

The broker should not be a simple secret proxy. It is an enforcement boundary.

A mature broker can provide:

• Credential acquisition and token exchange
• Tool allowlists
• Request validation
• Resource and audience mapping
• Rate and transaction limits
• Human approval integration
• Data-loss prevention checks
• Response filtering
• Audit correlation
• Credential revocation
• Policy versioning
• Emergency tool disablement

The agent should receive structured tool results, not raw authentication material.

This pattern also lets platform teams change identity providers, cloud roles, API authentication methods, or secret-management systems without teaching every agent how those systems work.

Prevent Authority Laundering During Agent Handoffs

Multi-agent systems add another identity risk.

Agent A may ask Agent B to perform part of a task. If Agent A simply forwards its token, Agent B can appear to be Agent A or inherit authority that was never approved for Agent B.

A secure handoff should be treated as a new authorization event.

The authorization service should evaluate:

• The original requesting subject
• The identity of Agent A
• The identity of Agent B
• The reason for the handoff
• The target tool
• The permissions required by Agent B
• The remaining workflow lifetime
• Whether the handoff is permitted by policy

Agent B should receive no more authority than it needs for its assigned subtask.

The system should also prevent recursive delegation from gradually increasing permission. Every handoff must preserve or reduce authority, never expand it without a new approval decision.

Define the Policy as a Reusable Contract

The following YAML is a vendor-neutral governance contract. It is not intended to be pasted directly into a specific identity platform.

It shows the information an enterprise policy engine, agent gateway, or tool broker should be able to enforce.

apiVersion: dtd.ai/v1alpha1
kind: AgentAuthorizationPolicy

metadata:
  name: service-desk-agent-production
  owner: enterprise-ai-platform
  riskTier: moderate

spec:
  agentIdentity:
    principal: agent/service-desk/production
    environment: production
    attestationIssuer: enterprise-workload-identity
    sharedIdentityAllowed: false

  authority:
    allowedModes:
      - agent-owned
      - user-delegated

    impersonation:
      default: deny

    delegation:
      requireSubjectIdentity: true
      requireActorIdentity: true
      preventAuthorityExpansion: true

  credentials:
    maximumLifetime: 10m
    refreshTokens: deny
    senderConstrained: true
    storage: memory-only
    logCredentialValues: false

  tools:
    - name: cmdb.search
      resource: cmdb-production
      actions:
        - assets.read
      authorityMode: agent-owned
      approval: none

    - name: itsm.ticket.create
      resource: itsm-production
      actions:
        - tickets.read
        - tickets.create
      authorityMode: user-delegated
      conditions:
        requesterMustMatchSubject: true
        departmentBoundaryRequired: true
      approval: none

    - name: automation.change.execute
      resource: automation-production
      actions:
        - approved-change.execute
      authorityMode: workflow
      conditions:
        approvedRunbookOnly: true
        singleUseCredential: true
        changeWindowRequired: true
      approval: human

  handoffs:
    credentialForwarding: deny
    requireNewAuthorizationDecision: true
    preserveOriginalSubject: true
    maximumDelegationDepth: 2

  telemetry:
    requiredFields:
      - subject_id
      - actor_id
      - agent_id
      - agent_version
      - run_id
      - tool_name
      - resource
      - requested_actions
      - granted_actions
      - policy_decision
      - approval_id
      - outcome

The reader should modify the principal names, resources, tool actions, credential lifetimes, approval rules, and telemetry fields to match the organization’s identity and policy systems.

Successful implementation means a reviewer can reconstruct every tool action without viewing the raw credential.

Common failures include:

• The broker accepts a token intended for another resource.
• Development and production agents share the same principal.
• The user is recorded, but the agent is not.
• The agent is recorded, but the initiating user is not.
• Tool permissions are broader than the tool schema suggests.
• The agent can bypass the broker and call the API directly.
• Refresh tokens outlive the approved workflow.
• Policy changes are not versioned or auditable.

Audit the Decision Chain, Not the Credential Value

Agent identity logging should answer more than who authenticated.

A useful audit event should capture:

Field	Purpose
Subject ID	Identifies the user or system whose authority was evaluated
Actor ID	Identifies the agent or workload that acted
Agent version	Connects behavior to released code, prompts, and tool definitions
Run ID	Groups all actions within the agent workflow
Tool and action	Shows what capability was requested
Target resource	Identifies the receiving service or tenant
Requested permissions	Records what the agent asked to do
Granted permissions	Records what policy actually allowed
Policy version	Shows which rules made the decision
Approval ID	Links privileged action to authorization evidence
Credential identifier hash	Supports correlation without logging the token
Result	Records success, denial, error, or partial completion
Downstream change ID	Connects the action to a ticket, deployment, or transaction

Never record complete access tokens, refresh tokens, API keys, or passwords in the audit event.

The audit trail should correlate identity events with:

• Agent traces
• Tool invocation records
• Authorization decisions
• Approval workflows
• Target-platform logs
• Change records
• Network telemetry
• Incident evidence

This creates a defensible chain from user intent to operational outcome.

Test Identity Controls Before Production

Identity architecture should be tested with negative scenarios, not only successful logins.

Test	Expected result
Reuse a ticketing token against a different tool	The second tool rejects the token
Replay a stolen token from another workload	Sender constraint or workload policy rejects it
Forward Agent A’s token to Agent B	Agent B cannot use it
Request a scope outside the agent policy	Authorization is denied
Use a production tool from a development agent	Environment policy denies access
Disable the requesting user during a long workflow	The next authorization checkpoint fails
Remove the agent’s workload identity	New credentials cannot be issued
Bypass the tool broker	Network or API policy blocks direct access
Attempt an action requiring approval without an approval ID	The action is denied
Reuse a single-use change credential	The second invocation fails
Submit a malicious tool parameter through the prompt	Schema and policy validation reject it
Inspect logs after the test	Both subject and actor remain visible

Write-capable tools should normally fail closed when the policy engine, approval service, or credential broker is unavailable.

Read-only tools may use a carefully defined degraded mode, but that decision should be explicit. An agent should not silently fall back to a shared credential because the preferred identity path failed.

Avoid the Common Identity Anti-Patterns

Shared Human Accounts

A shared human account removes individual accountability and usually accumulates excessive permissions.

An agent is not a team member and should not log in as one.

Developer Credentials in Production

The developer’s access token may work during prototyping, but it ties production availability and authority to one person’s employment, role, password, MFA state, and entitlements.

One Service Account for Every Agent

A single service account creates a large shared blast radius. It also prevents security teams from revoking or investigating one agent independently.

API Keys Embedded in Tool Definitions

Tool descriptions, environment files, prompt templates, and orchestration configuration are not credential vaults.

The model should know how to request a tool operation, not how to authenticate to the tool.

Broad Tokens Issued at Session Start

An agent may never use most of the tools available during a session. Issuing all possible permissions in advance creates unnecessary exposure.

Acquire authority only when the workflow reaches the required operation.

Treating Consent as Unlimited Delegation

A user approving one tool or action does not imply consent for every future action, every resource, or every agent version.

Consent should be specific enough that a reasonable user can understand what authority is being granted.

Logging Only the User

If the agent disappears from the audit record, the enterprise cannot distinguish user behavior from agent behavior.

Logging Only the Agent

If the requesting subject disappears, the enterprise cannot determine whose authority or data boundary justified the action.

A Practical Implementation Sequence

Inventory Existing Credentials

Identify every credential currently used by agents, copilots, bots, tool servers, connectors, and orchestration platforms.

Classify each credential by:

• Human or non-human owner
• Lifetime
• Storage location
• Resources accessible
• Permission scope
• Rotation method
• Revocation process
• Agents sharing it
• Audit visibility

Prioritize removal of shared human credentials and long-lived administrative keys.

Assign Workload Identities

Create separate identities for production agents based on independently deployed and independently revocable services.

Separate development, test, and production.

Classify Authority Modes

For every tool, decide whether the agent acts:

• On its own authority
• With delegated user authority
• Through an approved workflow
• Under an exceptional privileged process

Do not let the runtime choose the authority mode dynamically without policy.

Introduce the Broker Boundary

Move credential acquisition and sensitive tool calls behind an approved broker or gateway.

Block direct network access where practical.

Create Per-Tool Policies

Define resources, actions, data boundaries, approval rules, transaction limits, and required telemetry for every approved tool.

Replace Forwarded Tokens With Token Exchange

Create resource-specific credentials for downstream calls. Preserve both the subject and actor when user authority is involved.

Shorten and Bind Credentials

Reduce token lifetime, remove unnecessary refresh tokens, validate audience, and add sender constraints where supported.

Add Handoff Controls

Require every agent-to-agent handoff to create a new authorization decision and credential.

Exercise Revocation

Test user disablement, agent disablement, tool removal, policy rollback, emergency credential invalidation, and broker outage behavior.

An identity architecture that has never been revoked is not yet proven.

The Enterprise Decision Framework

Use the following decision model when choosing an identity pattern.

Scenario	Recommended authority	Credential pattern	Default control
Scheduled knowledge indexing	Agent-owned	Workload token	Read-only resource scope
User-specific document search	User-delegated	Exchanged downstream token	Subject and actor preserved
Ticket creation	User-delegated or workflow	Tool-specific token	Department and action limits
Inventory collection	Agent-owned	Short-lived workload token	Read-only and environment-bound
Deployment request	Workflow	Automation platform credential	Approval and policy validation
Production remediation	Workflow with human approval	Single-use execution credential	Approved runbook only
Cross-agent specialist handoff	Delegated chain	New token for receiving agent	No credential forwarding
Privileged identity administration	Human-controlled exceptional process	Just-in-time privileged credential	Deny autonomous execution by default

The right pattern is rarely “give the agent the user’s token.”

The better question is:

What minimum authority must this specific actor receive for this specific resource, operation, and period?

Conclusion

AI agents need identity because they are becoming active participants in enterprise workflows.

Giving an agent a human credential may make a prototype easy to demonstrate, but it creates the wrong production boundary. Human identity, agent identity, delegated authority, tool authorization, and credential issuance become indistinguishable.

A stronger architecture starts with a dedicated workload identity for every independently governed agent. It preserves the user as the subject when delegation is required, keeps the agent visible as the actor, exchanges credentials for each target resource, limits permissions to individual tool actions, and expires authority quickly.

Sensitive tools should sit behind brokers, gateways, approval workflows, and network controls. Multi-agent handoffs should create new authorization decisions rather than forwarding credentials. Audit trails should record the entire decision chain without recording the secrets themselves.

The objective is not merely to authenticate the agent.

The objective is to make every action attributable, constrained, revocable, and explainable.

External References