Agent Identity and Least-Privilege Authorization: The Security Footgun Your AI Team Is Ignoring

Most AI agent architectures have a quiet security problem that nobody discovers until something goes wrong. You build the agent, wire it to your internal APIs using the app's existing service account credentials, ship it to production, and move on. The agent works. Users are happy. And somewhere in your audit log, a single service account identity is silently touching every customer record, every billing table, and every internal document that agent ever needs — with no trace of which user asked for what, or why.

This isn't a theoretical risk. When the breach happens, or when a regulator asks "who accessed this data on March 14th," the answer is the same every time: [email protected]. Every action, every request, every read and write — all collapsed into one identity. The audit trail is technically correct and forensically useless.

The Service Account Trap

Traditional service-to-service authentication assumes a static relationship: Service A always needs permission Y to do its job. The permissions are provisioned once, reviewed at setup, and rarely revisited. This model works when the service is deterministic — a billing service that reads invoices and writes payment records does a predictable, bounded set of things.

AI agents break this assumption in three ways.

First, agents have emergent access patterns. A customer support agent might need to read CRM data today, but next week a user asks it to pull a trend report and it starts querying the analytics warehouse. The set of data an agent might touch expands with every new capability you give it, and your initial permission grant becomes progressively outdated.

Second, agents operate on behalf of many users with different privilege levels. A marketing analyst and a C-suite executive might use the same agent, but they have very different data access rights in your system. When both route through a single service account, the agent's permissions are the union of every user's entitlements — or worse, they're completely decoupled from user permissions and reflect whatever the service account was provisioned with.

Third, agents are prompt-injectable. A malicious user, a poisoned document in the retrieval corpus, or a manipulated tool response can redirect an agent toward actions its original designer never intended. When the agent's credentials are broad, the blast radius of a successful prompt injection scales with permissions, not with intent.

The 2024 Palo Alto Networks "Double Agents" research exposed this concretely in GCP Vertex AI: agents that inherited overly broad service account permissions allowed researchers to pivot from restricted consumer projects into infrastructure-level resources, accessing source code and container images that had no legitimate connection to the agent's task. The weakness was architectural, not a model failure — the permissions outlasted any reasonable definition of what the agent needed.

What Production-Grade Agent Identity Looks Like

The right mental model isn't "give the agent an identity and constrain what it can do with it." It's "give the agent only the identity it needs for the specific task it's executing right now."

Per-task ephemeral credentials are the practical implementation of this. Instead of agents running on long-lived API keys, a vault system (AWS STS, GCP service account impersonation, HashiCorp Vault with short-TTL leases) issues a temporary credential scoped to exactly what this particular task requires, with a lifetime measured in minutes. When the task completes, the credential expires. There's no standing access to steal.

Okta's 2025 security benchmarks measured the impact: organizations using short-lived tokens (under 300 seconds) saw a 92% reduction in credential theft incidents compared to those using 24-hour sessions. The operational overhead of rotation disappears when credentials are issued dynamically and expire automatically.

SPIFFE-based workload identity takes this further. Each agent instance gets a cryptographically verifiable identity certificate with a short TTL, bound to the specific workload and task context. The certificate encodes not just "this is the AI agent service" but "this is agent instance X, executing task Y, on behalf of user Z." That identity propagates through every downstream API call, making audit logs actually meaningful.

The Dual-Identity Encoding Problem

When an agent acts on behalf of a user, downstream systems need to know two things: who authorized the action (the human user), and what system executed it (the agent). This is the principal hierarchy problem, and most implementations handle it badly.

The naive approach: the agent calls the API using its own service account, with the user identity recorded in an application-layer log somewhere. This breaks forensics — the API's native audit trail shows the agent, not the user, and reconstructing the full chain requires joining logs across systems.

The IETF has a draft specification (On-Behalf-Of User Authorization for AI Agents) that formalizes this. The pattern uses token exchange: the user's session token is traded for a new token that encodes both the user's identity and the agent's identity in the same credential. Downstream APIs see a token that says "this is user Alice, being represented by agent-v2, which has been granted these specific scopes." Revocation is clean — invalidating Alice's session also invalidates the agent's ability to act for her.

In practice, this maps to the On-Behalf-Of (OBO) flow in OAuth 2.0 implementations. The key requirement is that the agent's token must never have broader permissions than the user whose action it's fulfilling. If Alice can't read payroll data, the agent acting for Alice cannot read payroll data, regardless of what the agent's own service account can access. This "delegated not amplified" principle is what separates properly scoped agents from authorization bypass vectors.

Audit Trails That Actually Work

When every agent action carries proper dual-identity credentials, audit logs become useful. Instead of:

2026-03-14 14:32:01  [email protected]  READ  customers/record/9821
2026-03-14 14:32:02  [email protected]  READ  customers/record/9822

You get:

2026-03-14 14:32:01  user:[email protected] via agent:support-v2 task:ticket-12847  READ  customers/record/9821

The difference isn't cosmetic. When an auditor or incident responder asks "who accessed customer record 9821 on March 14th," the first log requires a separate investigation into what the support agent was doing at 14:32 and who triggered it. The second log answers the question directly.

This matters particularly under the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems effective August 2026. Building proper audit trails retroactively into a system that uses shared service accounts is painful — it requires instrumenting every layer of your stack. Building it correctly from the start requires only that you implement proper identity propagation in the credential layer.

Staged Authorization as a Safety Layer

Even with properly scoped credentials, agents benefit from a staged access model that matches permission level to task risk.

Stage 1: read-only observation. The agent can query any data it needs but cannot write, modify, or trigger actions. This is appropriate for research agents, report generation, and analysis tasks.

Stage 2: draft-only with human approval. The agent can propose actions — a draft email, a proposed calendar change, a query to execute — but those actions don't execute until a human confirms. Credentials at this stage include read access plus write access to a "draft" namespace, nothing in the live system.

Stage 3: supervised execution with scoped write access. The agent can take limited real-world actions (send a message, create a ticket) within a narrowly defined scope. Credentials are task-specific and expire immediately after the action.

The authorization escalation path should require explicit justification at each stage, and the system should default to the most restrictive stage that can still fulfill the user's stated intent. Most agent tasks don't need Stage 3. Most teams start there anyway because it's simpler to provision.

The Blast Radius Formula

A useful way to evaluate your current authorization setup: blast radius = access scope × operating velocity × detection window.

Access scope is how much of your system an agent's credentials can touch. Operating velocity is how many actions per minute the agent takes. Detection window is how long a compromise runs before it's noticed.

Broad service accounts maximize scope. Autonomous agents maximize velocity. Shared credentials and weak audit trails maximize detection window. The product of all three determines how bad the post-mortem conversation will be.

Ephemeral credentials reduce scope and compress the detection window simultaneously — a compromised credential expires before it can be systematically exploited, and the tight scope limits what an attacker can reach within that window. This isn't defense in depth in the academic sense; it's the single highest-ROI change you can make to the authorization architecture of any production AI system.

What to Do First

If you're inheriting an agent system that already uses shared service accounts, the migration path has a natural order:

1. Audit what the service account can actually reach. Most teams are surprised by the scope. Cloud provider IAM analyzers surface unused permissions automatically.

2. Add task-level identity context to your existing logs before changing credentials. Establish the audit trail now, so you can compare behavior before and after.

3. Move to short-lived tokens at the infrastructure layer. This doesn't require changing agent code — it's a credential provisioning change in how the agent runtime is deployed.

4. Implement user delegation if your agents act on behalf of specific users. This is the OBO pattern and requires token exchange at the authentication layer, but it's the only way to get meaningful audit trails for user-initiated agent actions.

5. Define staged authorization tiers that match your agents' actual task profiles. Push toward Stage 1 by default; require deliberate escalation to Stage 3.

The agents that cause the worst security incidents aren't the ones with clever prompt injections or sophisticated attacks. They're the ones that had unrestricted access, ran autonomously for months, and were discovered during a breach forensics exercise when the investigator asked "what else did this service account do" and the answer was "everything."

---

The identity model you choose for your agents is a product decision, not just a security one. It determines whether your audit logs are useful, whether your permission model degrades gracefully under attack, and whether a bad prompt or a malicious document can turn your agent into an insider threat with system-wide credentials. Most teams defer this decision until something breaks. The teams that get it right build proper scoping before they need it — because retrofitting authorization onto a running production system is an order of magnitude harder than designing it correctly from the start.