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 elementWhat it representsExampleRequesting subjectThe human or system that initiated the taskAn engineer requesting an incident summaryAgent identityThe software workload interpreting and executing the taskProduction operations agentRuntime identityThe deployed process, pod, VM, function, or agent serviceAgent deployment in the production namespaceTool identityThe client recognized by a downstream toolApproved ITSM tool connectorResource ownerThe party whose data or authority is being accessedThe requesting engineer or business unitApproverThe person or workflow authorizing a high-impact actionChange 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:
AttributeWhy it mattersAgent identifierIdentifies the approved agent serviceEnvironmentSeparates development, test, and productionOwnerEstablishes operational accountabilityDeployment versionCorrelates behavior with released code and instructionsRisk tierDrives approval and monitoring requirementsAllowed tool classesPrevents unapproved integrationsData boundaryRestricts accessible informationRuntime locationSupports network and residency policyAttestation stateConfirms 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?
Make Authorization Specific to Each Tool
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 dimensionExampleAgentOnly the production service-desk agentUserOnly active employees in supported departmentsToolITSM ticket connectorActionCreate ticket, not delete ticketResourceProduction ITSM tenantObjectTickets associated with the requesting business unitData classificationInternal operational data onlyEnvironmentProduction agent runtimeTimeWithin approved support hoursTransaction limitNo more than 20 creations per runApprovalRequired for emergency severity or privileged routingNetwork pathCalls 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.
Put a Credential Broker Between Agents and Sensitive Tools
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:
FieldPurposeSubject IDIdentifies the user or system whose authority was evaluatedActor IDIdentifies the agent or workload that actedAgent versionConnects behavior to released code, prompts, and tool definitionsRun IDGroups all actions within the agent workflowTool and actionShows what capability was requestedTarget resourceIdentifies the receiving service or tenantRequested permissionsRecords what the agent asked to doGranted permissionsRecords what policy actually allowedPolicy versionShows which rules made the decisionApproval IDLinks privileged action to authorization evidenceCredential identifier hashSupports correlation without logging the tokenResultRecords success, denial, error, or partial completionDownstream change IDConnects 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.
TestExpected resultReuse a ticketing token against a different toolThe second tool rejects the tokenReplay a stolen token from another workloadSender constraint or workload policy rejects itForward Agent A’s token to Agent BAgent B cannot use itRequest a scope outside the agent policyAuthorization is deniedUse a production tool from a development agentEnvironment policy denies accessDisable the requesting user during a long workflowThe next authorization checkpoint failsRemove the agent’s workload identityNew credentials cannot be issuedBypass the tool brokerNetwork or API policy blocks direct accessAttempt an action requiring approval without an approval IDThe action is deniedReuse a single-use change credentialThe second invocation failsSubmit a malicious tool parameter through the promptSchema and policy validation reject itInspect logs after the testBoth 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.
ScenarioRecommended authorityCredential patternDefault controlScheduled knowledge indexingAgent-ownedWorkload tokenRead-only resource scopeUser-specific document searchUser-delegatedExchanged downstream tokenSubject and actor preservedTicket creationUser-delegated or workflowTool-specific tokenDepartment and action limitsInventory collectionAgent-ownedShort-lived workload tokenRead-only and environment-boundDeployment requestWorkflowAutomation platform credentialApproval and policy validationProduction remediationWorkflow with human approvalSingle-use execution credentialApproved runbook onlyCross-agent specialist handoffDelegated chainNew token for receiving agentNo credential forwardingPrivileged identity administrationHuman-controlled exceptional processJust-in-time privileged credentialDeny 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
IETF: RFC 8693, OAuth 2.0 Token ExchangeCanonical URL: https://www.rfc-editor.org/info/rfc8693
IETF: RFC 9700, Best Current Practice for OAuth 2.0 SecurityCanonical URL: https://www.rfc-editor.org/info/rfc9700
IETF: RFC 8707, Resource Indicators for OAuth 2.0Canonical URL: https://www.rfc-editor.org/info/rfc8707
IETF: RFC 9396, OAuth 2.0 Rich Authorization RequestsCanonical URL: https://www.rfc-editor.org/info/rfc9396
IETF: RFC 9449, OAuth 2.0 Demonstrating Proof of PossessionCanonical URL: https://www.rfc-editor.org/info/rfc9449
NIST: SP 800-207, Zero Trust ArchitectureCanonical URL: https://csrc.nist.gov/pubs/sp/800/207/final
SPIFFE: SPIFFE ConceptsCanonical URL: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
Kubernetes: Service AccountsCanonical URL: https://kubernetes.io/docs/concepts/security/service-accounts/
Model Context Protocol: AuthorizationCanonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
Google Cloud: Workload Identity FederationCanonical URL: https://docs.cloud.google.com/iam/docs/workload-identity-federation
Google Cloud: Agent Identity OverviewCanonical URL: https://docs.cloud.google.com/iam/docs/agent-identity-overview
From Prompt Library to Policy Layer: Translating AI Prompt Intent Into Execution Rules
Prompt libraries are useful because they standardize intent. They give teams a repeatable way to ask for summaries, analysis, troubleshooting help, change…
The post How to Give AI Agents Identity Without Sharing Human Credentials appeared first on Digital Thought Disruption.