Skip to content
Gagan Bhatia

Agent identity: NIST's five failures and the AWS half you already have

· First published on LinkedIn

I read the NIST post on agent identity expecting to feel behind.

It was published on August 27. Turns out most agent deployments are repeating the IAM mistakes we spent twenty years fixing. Developers paste their own tokens into config files. Agents run under a human's account, so the log says a person did what a program did. Long-lived keys sit in env vars. A role is scoped for everything the agent might ever do. And humans click "allow" on autopilot, like MFA pushes nobody requested.

These are five distinct failures, and none of them are new. That's NIST's point.

Fortunately, the fixes aren't new either: an identity per agent, bound to the human it works for, short-lived credentials, access scoped to the task. The standards already exist: OAuth token exchange, SPIFFE, DPoP and RAR.

Then I looked at the AWS estates I work in. If you do infrastructure as code in AWS, you've already been doing half of this for years. You just never called it agent identity.

A Lambda execution role or an EC2 instance profile already is one. Nothing in the code holds a credential. AWS issues short-lived ones to that workload, rotates them, and logs every call in CloudTrail under the role. Three of NIST's five failures, handled before you write a single line of agent code.

The remaining gaps are specific and manageable:

  1. The authority gap. The role names the compute resource, not the person. CloudTrail proves the role acted, but never says on whose authority.

    The fix: Pass SourceIdentity when the agent assumes its task role, and require it in the trust policy.

  2. The scope gap. The role's policy is the union of every task the agent might ever do.

    The fix: Apply a session policy on that same call to shrink the invocation to the exact task at hand, and a permissions boundary to prevent a careless merge from widening it later.

  3. The boundary gap. IAM stops at the AWS perimeter. The moment an agent calls a SaaS API or an internal legacy system, the AWS role loses its meaning and you're back to managing keys in Secrets Manager.

    Nobody has ever solved that by writing more Terraform.

This is where the vendors are focusing.

Ping announced Enterprise Personal Agent Access on September 1: find the agents already running, know who's behind them, control what they touch. CrowdStrike announced an Agentic Identity Provider at Fal.Con the next day: a registry with a verifiable identity per agent, short-lived brokered access, every action tied to the human or workload behind it.

CrowdStrike's own post says those features are unreleased, so buy on what ships.

An agent carrying your credentials isn't an agent. It's you, at machine speed, with no audit trail.

NIST: nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation