Identity in the Agentic Era, Episode 1
Medium | ~2,000 words | 8-minute read

I was reviewing an AI-powered internal tool a team had shipped to production. It summarized documents, answered questions about internal policy, and could update records in a few internal systems based on what it found.

When I asked what credentials it ran under, the engineer pulled up the service account configuration.

AdministratorAccess.

“It needed to read from S3, query DynamoDB, call a few internal APIs,” he said. “We weren’t sure exactly what it needed, so we gave it everything and planned to tighten it later.”

I had heard that sentence before. Almost word for word. In 2017, auditing an AWS account where six Lambda functions each carried three full-access managed policies because someone needed them to work quickly and planned to tighten them later. In 2019, reviewing a GCP project where a service account had roles/editor at the folder level for the same reason.

We are re-running the same IAM mistakes from the last decade, at speed, with a new class of actors that are harder to audit, harder to predict, and capable of taking autonomous action at a scale no human operator could match.

The non-human identity problem is back. And it brought reinforcements.

The Last Time We Had This Problem

In the early cloud era, the explosion of non-human identities was Lambda functions, EC2 instance profiles, container service accounts, CI/CD pipeline roles. Engineers needed these workloads to access cloud resources. The fastest path was broad permissions. And because nobody was accountable for “the Lambda’s IAM role” specifically, nobody came back to tighten it.

The IAM practices that emerged over the following years — least privilege policies, generated from actual usage rather than estimated requirements; workload identity federation instead of static credentials; OIDC short-lived tokens instead of long-lived access keys — were direct responses to the mess that accumulates when you grant first and audit never.

That took about a decade to normalize. Many environments still aren’t there.

Now we have AI agents. And we are starting the cycle again from scratch.

What Makes AI Agents Different as Identities

The workload identity problem from 2015 was hard because of scale — hundreds of Lambda functions, thousands of EC2 instances, each needing its own carefully scoped permissions.

AI agents introduce three properties that make the identity problem qualitatively harder.

Autonomy. A Lambda function does exactly what its code says. An AI agent decides what to do based on a prompt, context, and model behavior. The set of actions it might take is not fully enumerable at deployment time. This means you cannot reason about “what does this agent need access to” the same way you reason about a deterministic workload.

Manipulability. A Lambda function cannot be convinced to do something outside its code by a malicious user prompt. An AI agent can. If the agent has access to customer data and an attacker can inject a prompt that instructs it to exfiltrate that data, the agent’s valid credentials become the attack vector. This is prompt injection — and it turns IAM from a defense into a liability if permissions are too broad.

Opacity. When a Lambda function with s3:GetObject reads a file, you know exactly why: the code called that API. When an AI agent reads a file, the reason is a chain of model decisions that may not be logged, may not be auditable, and may not be consistent across runs. The audit trail that IAM depends on — who accessed what and why — becomes significantly harder to maintain.

The Same Mistakes, Same Causes

Walk through an AI agent deployment today and the anti-patterns are familiar:

Over-provisioned service accounts. The agent needs to read documents, call an API, maybe update a record. Rather than enumerate exactly which documents, which API endpoints, which records — all of which requires upfront work — the team grants broad access and ships. The access never gets tightened because the agent works and nobody is specifically accountable for its permissions.

Static long-lived credentials. The agent’s API keys are in environment variables. They were created six months ago. They’ve never been rotated. If the agent is compromised or its runtime environment is accessed, those credentials are available — and they’re broad.

No audit trail. The agent runs under a shared service account used by other services too. When CloudTrail shows an unexpected S3 read from that account, there is no way to know whether it came from the agent, the other service, or something else entirely.

“We’ll tighten it later.” The phrase that has followed every IAM explosion since 2012. Later rarely comes while the system is working.

These are not AI-specific failures. They are IAM failures that AI deployments are inheriting because the teams building agents are not always the same teams who spent the last decade cleaning up cloud IAM.

What Least Privilege Looks Like for an AI Agent

Applying least privilege to an AI agent requires working backwards from what the agent is actually allowed to do, not what it might conceivably need.

Enumerate the agent’s actions, not its access. A document summarization agent needs to read specific document stores, nothing else. An agent that updates records needs write access to specific tables with specific conditions — not the whole database. Define the scope from the action, not from the model’s capability.

Scope by data sensitivity. Not all data the agent could access is data the agent should access. An agent answering internal HR policy questions does not need read access to financial records. Separate the data stores. Separate the service accounts. The blast radius of a prompt injection attack is bounded by the permissions of the compromised service account.

Use short-lived credentials. If your AI agent runtime supports OIDC or workload identity federation — and most production platforms now do — use it. The agent gets a short-lived token scoped to its task. No long-lived key to rotate, no orphaned credential to discover later.

One service account per agent, per environment. Not a shared service account. Not the same account in staging and production. Each agent identity should be independently auditable, independently revocable.

# What you want to see in CloudTrail
eventSource: s3.amazonaws.com
eventName: GetObject
userIdentity:
  type: AssumedRole
  arn: arn:aws:sts::123456789:assumed-role/agent-doc-summarizer-prod/session

# What you don't want to see
userIdentity:
  arn: arn:aws:iam::123456789:user/ai-service-shared

The first entry tells you which agent, which role, which session. The second tells you nothing useful.

The Audit Gap

Here is the problem that doesn’t have a clean solution yet: even with a properly scoped service account, you know that the agent accessed a resource. You do not know why — what prompt triggered it, what reasoning led to it, what the agent was trying to accomplish.

This is the provenance gap in AI systems. Traditional IAM audit logs capture the action and the identity. For AI agents, you need a third dimension: the reasoning chain that produced the action.

Without that, your audit trail for compliance purposes is incomplete. You can prove that agent-doc-summarizer-prod read a file. You cannot prove whether it did so because a user asked a legitimate question or because an attacker injected a prompt that caused it to retrieve and expose that file.

Solving this requires logging not just the API call, but the context that produced it — the prompt, the model’s decision path, the tool call sequence. That logging infrastructure doesn’t exist out of the box in most AI frameworks today. Building it is one of the open problems in AI security, and it is an IAM problem at its core.

Framework Alignment

Key Takeaways

• AI agents are non-human identities. They inherit every IAM anti-pattern we spent a decade fixing for Lambda functions and EC2 instances — and introduce new ones unique to autonomous, manipulable systems
• Least privilege for AI agents works backwards from the agent’s defined actions, not from what it might conceivably need
• Prompt injection turns over-permissioned credentials into an attack vector — the agent’s valid access becomes the attacker’s access
• One service account per agent, per environment. Short-lived credentials where possible. No shared accounts that obscure audit trails
• The provenance gap — knowing why an AI agent took an action, not just that it did — is an open problem that traditional IAM logging doesn’t solve

What’s Next

In EP02, I’ll cover the specific IAM boundary that most AI pipelines are missing entirely: the data access layer for RAG systems. When your LLM retrieves context from a vector database, what controls what it can retrieve? The answer — for most teams right now — is nothing. And that’s a problem that has a concrete fix.

The post The Non-Human Identity Problem Is Back appeared first on Linuxcent.