How AI Agents Authenticate Today (Spoiler: Badly)

The Dirty Secret of Agent Authentication

Ask a team deploying AI agents how their agents authenticate to backend systems. You'll usually get one of three answers:

1. "We use the developer's personal access token."
2. "We created a service account with admin permissions."
3. A long, uncomfortable silence.

None of these are real answers. They're admissions that agent authentication is being papered over with shortcuts that would make any security auditor cringe. And these shortcuts are running in production at companies you trust with your data.

In my view, agent authentication today is roughly where web application authentication was in the mid-2000s. Secrets sit in plaintext, sessions never expire, and the attitude is "we'll fix it when it becomes a problem." It's already a problem.

How Agents Actually Authenticate Right Now

Let's map the real-world patterns. Not what vendors say in their marketing, but what actually runs in production.

Pattern 1: Inherited Human Credentials

The most common pattern. A developer configures an AI agent with their own credentials: a GitHub personal access token, an AWS access key, a database password. The agent uses them to access systems as if it were the developer.

Developer's Credentials
        |
        v
+------------------+
|   AI Agent       |
|   (acts as the   |
|    developer)    |
+------------------+
        |
        v
+------------------+     +------------------+
| GitHub (write)   |     | AWS (admin)      |
+------------------+     +------------------+
        |
        v
+------------------+     +------------------+
| Database (full)  |     | Slack (post)     |
+------------------+     +------------------+

Why it's terrible:

• The agent has all the developer's permissions, not just what the task needs
• Audit logs show the developer did it, with no way to tell human from agent activity
• If the agent is compromised, the developer's entire access footprint is exposed
• Several agents may share the same credential, making attribution impossible
• Rotating the credential means updating every agent that uses it

Pattern 2: Shared Service Accounts

Teams create a shared service account ("ai-assistant@company.com" or similar) and hand it to their AI agents. It typically gets broad permissions because "we're not sure what the agent will need."

Why it's terrible:

• One credential shared across many agents means compromising one compromises all
• "Broad permissions because we're not sure" is the definition of over-provisioning
• No way to attribute actions to specific agents or tasks
• The account accumulates permissions over time as new use cases emerge
• Nobody owns it, so nobody reviews or rotates it

Pattern 3: API Keys with No Expiration

Agents get API keys generated months or years ago. The keys sit in configuration files, get shared in chat messages, or are committed to code repositories.

The numbers are large and growing. GitGuardian counted 23.8 million new secrets leaked in public GitHub commits in 2024. Its 2026 report counted 28.65 million in 2025, up 34%, including about 1.28 million secrets for AI services. Private code is not safer: the 2026 report found internal repositories roughly six times more likely than public ones to contain hardcoded secrets.

Why it's terrible:

• Static keys are the most easily compromised credential type
• No expiration means no forcing function for rotation
• Keys scattered across config files, environment variables, and chat histories create an unmanageable attack surface
• Nothing connects the key to the agent's current task or required permissions

Pattern 4: OAuth Tokens (Getting Warmer, But Still Wrong)

More sophisticated deployments use OAuth 2.0 tokens for agents. This is directionally correct but usually implemented poorly. Common mistakes include:

• Requesting overly broad scopes ("give me all the scopes, the agent might need them")
• Using long-lived refresh tokens that effectively create permanent access
• Not rotating refresh tokens
• Storing tokens insecurely in the agent's runtime environment

Agent Auth Failures: One Public Case and Three Composites

The Assistant That Could Read Private Channels

In August 2024, researchers at PromptArmor showed data exfiltration from Slack AI via indirect prompt injection. Slack AI answered a user's questions by searching both public and private channels that user could access. An attacker posted crafted instructions in a public channel. When the victim later queried Slack AI, it could be steered into leaking an API key the victim had stored in a private channel. The Register reported that Salesforce deployed a patch.

The lesson for agent authentication: the assistant ran with the full reach of the person asking. Anything that person could read, injected instructions could reach too.

The next three cases are illustrative composites built from common patterns, not reports of specific incidents.

The CI/CD Agent with Production Access

An engineering team lets an AI coding assistant open pull requests with bug fixes. It needs repository access (reasonable) and CI/CD access to run tests (mostly reasonable).

But the pipeline's service account can also deploy to production. The assistant traces a test failure to a staging configuration issue and "helpfully" updates the staging config. The same access works for production. A mis-targeted environment variable change lands there and causes an outage.

The Customer Support Agent with PII Access

A SaaS company gives an AI support agent access to its CRM. The CRM API has no field-level access controls: you either see a customer record or you don't. The agent only needs basic account information, such as subscription status and recent tickets.

It can also see payment details, government ID numbers stored for identity verification, home addresses, and internal sales notes. The agent never misuses that data. But every prompt and response flows through a third-party model provider, so PII leaves the company with every interaction. Before connecting an agent to customer data, check the provider's retention and training terms; the LLM data handling comparison is a starting point.

The Multi-Tool Agent Nobody Could Audit

A DevOps team connects an agent to 14 tools: GitHub, Jira, PagerDuty, Datadog, AWS, Terraform Cloud, Slack, and seven internal services. Each integration authenticates differently. Some use API keys, some OAuth, and two use username and password basic auth.

Security asks, "What can this agent access?" Mapping it takes three engineers two days. Then security asks, "What has it actually accessed in the last 30 days?" The answer is that nobody can correlate actions across the 14 systems.

The Attribution Problem

Even when agents authenticate properly, a deeper problem remains: attribution. Traditional security relies on knowing who did what. With agents, the chain of responsibility gets murky.

Action in audit log: "Service account 'ai-ops' deleted
                      47 CloudWatch log groups"

Questions you can't answer:
  * Which agent instance performed this action?
  * What human authorized or triggered this action?
  * What was the agent's reasoning for this decision?
  * Was this part of a larger task, and what was that task?
  * Did the agent consider alternatives first?
  * Is this within the agent's expected scope?

Traditional audit logs record the "what" (action taken) and the "who" (credential used). For agent activity, you also need the "why" (task context), the "on behalf of" (human principal), and the "within bounds of" (authorized scope). Few logging pipelines capture all of that today without custom instrumentation.

What "Good" Agent Authentication Looks Like

Let's define the target state. Good agent authentication has seven properties.

1. Unique Identity Per Agent Instance

Every agent instance should have its own identity. Not a shared service account, not a human's credential, not a reused token. This identity should be:

• Automatically provisioned when the agent starts
• Tied to a specific human principal (the person who authorized the agent)
• Scoped to a specific task or session
• Automatically revoked when the agent's task completes

2. Minimal Scoped Permissions

Agent permissions should be the minimum the current task requires, decided at runtime, not at deployment time.

Bad:  Agent gets "admin" role at startup, uses it for everything
Good: Agent requests specific permissions per action

Example: agent deploying a service
  Step 1: Request "repo:read" for 15 minutes      --> Pull code
  Step 2: Request "build:execute" for 30 minutes  --> Run build
  Step 3: Request "registry:push" for 10 minutes  --> Push image
  Step 4: Request "k8s:deploy" for 15 minutes     --> Deploy
  Each permission expires after its time window

3. Short-Lived Credentials

Agent credentials should live for minutes to hours, not days or months. When a credential expires, the agent must re-authenticate and re-authorize. That gives the system a chance to re-evaluate whether the agent should still have access.

4. Delegation Chains

When a human authorizes an agent, and that agent invokes another agent, the chain of delegation should be cryptographically verifiable. Anyone inspecting the action should be able to trace it back through every agent to the original human.

5. Rich Audit Context

Every agent action should be logged with:

• The agent's unique identity
• The human principal who authorized the agent
• The task or goal the agent is pursuing
• The specific permissions used
• The agent's reasoning (where available)
• A correlation ID linking related actions across systems

6. Continuous Authorization

Rather than one authentication event at startup, agents should be authorized continuously. Re-evaluate their permissions based on:

• What they've done so far (have they stayed within expected bounds?)
• What they're asking to do next (is it consistent with their task?)
• Environmental context (has anything changed since they started?)
• Risk signals (are there anomalies in their behavior?)

7. Revocability

You must be able to revoke an agent's access instantly, across all systems, with a single action. That requires centralized credential management and real-time revocation propagation, which most current architectures lack.

The Technology Gap Is Closing

When the first edition of this book went out, the honest answer to "why isn't anyone doing this?" was that the technology wasn't ready. By late 2026, most of the building blocks exist. What's missing is deployment.

What Exists Today

• OAuth 2.0 and OpenID Connect: The base for delegated authorization. Good between apps, but not designed for agents that decide for themselves what to access.
• OAuth 2.0 Token Exchange (RFC 8693): Lets an agent trade a user's token for a narrower one. Its act claim records both the user and the actor, so downstream calls carry the delegation.
• MCP authorization: The Model Context Protocol authorization spec (version 2025-11-25) makes protected MCP servers OAuth 2.1 resource servers. Chapter 4 covers it.
• Agent identity in the directory: Microsoft Entra Agent ID is generally available and registers agents with sponsors, lifecycle governance, and Conditional Access. Okta and others have agent identity products as well.
• Cross App Access (ID-JAG): An identity-provider-brokered pattern, promoted by Okta, that lets admins approve app-to-app agent connections centrally instead of users clicking consent screens.
• Asynchronous human approval (OpenID CIBA): The agent pauses and asks a person to approve a sensitive action on a separate device.
• SPIFFE/SPIRE: Strong workload identity for the process running the agent, at the infrastructure level.
• Cloud IAM roles: Temporary credentials and role assumption, without agent-specific context.
• Secrets managers (Vault, AWS Secrets Manager): Store credentials securely, but don't decide which credentials an agent should use.

The AI Agent Security Map's identity primitives page tracks which vendors publicly claim each of these building blocks.

What's Still Missing

• Dynamic permission negotiation in practice: The standards allow narrow, per-action tokens. Few agent frameworks request them by default.
• Cross-domain delegation: Expressing "this human authorized this agent for these actions across five systems run by three companies" is still hard.
• Agent-aware audit logs: There is no widely adopted standard for capturing the context needed to understand agent actions.
• Adoption: Most agents in production still run on the four patterns above.

Practical Steps for Today

While adoption catches up, here's what you can do right now.

Stop sharing human credentials with agents. Create dedicated identities for each agent deployment. Yes, this is more work. It's also the bare minimum for attribution and access control.

Implement credential rotation. If an agent must use an API key, rotate it automatically every 24 hours. Most secrets management tools support this.

Use OAuth where possible, but scope it tightly. Request only the scopes the agent needs. Use short token lifetimes. Implement refresh token rotation. Prefer token exchange over passing the user's own token through.

Log everything with context. Add custom fields to your logs that identify agent actions: the agent's ID, the triggering user, the task ID. This won't happen automatically; you'll need to instrument your agent deployments.

Set up alerts for anomalous agent behavior. Define normal for each agent (which systems it accesses, how often, which actions it takes) and alert when behavior deviates.

Run regular agent access reviews. Monthly, compare every agent's actual access with its required access. Remove permissions that aren't used. Decommission agents that are no longer needed.

The Organizational Challenge

Technology alone won't solve agent authentication. Organizations also face structural challenges.

Who Owns Agent Identity?

In most organizations, IT owns human identity (provisioning and deprovisioning) and security governs it (access reviews and policy). For agents, ownership is unclear. The team that deploys the agent thinks infrastructure owns the credentials. Infrastructure thinks the team owns them. Security doesn't know the agent exists.

Until someone owns agent identity, including provisioning, credential management, access review and decommissioning, the technical solutions won't matter. Someone needs to be responsible for every agent credential, just as someone is responsible for every employee's access.

The Cultural Shift

Developers are used to creating service accounts, API keys, and integration tokens as part of normal work. A governance process for agent credentials feels like bureaucracy. The shift required is real: every credential an agent uses is a security decision, and security decisions should be deliberate, not accidental.

That doesn't mean weeks of process. It means a streamlined, low-friction way to provision agent credentials with the right scope, lifetime and monitoring. It has to be easier than grabbing a personal access token and hoping for the best.

The Uncomfortable Truth

We're deploying autonomous systems into production with authentication practices we'd never accept for human users. No security team would let an employee use shared passwords, skip MFA, keep a session forever, or work with no audit trail. Yet we accept all of these for AI agents.

The gap exists because agent authentication is hard, deployment is immature, and the pressure to ship agents is intense. But "it's hard" has never been an acceptable reason to skip security, and the stakes rise every day.

The organizations that get agent authentication right first will have a genuine advantage. Not just in security, but in their ability to deploy agents at scale without unacceptable risk. The rest will learn the lesson the hard way.