Six identity rules for AI agents

Everyone is asking how to secure AI agents. Most of it is an identity problem, and IAM teams already own the playbook.

Delegation, not impersonation. An agent should never hold your credentials and be you. It should have its own identity and a short lived token that says "acting for Curt, limited to these actions." If your systems can't tell the agent from the human, you built impersonation.

Prompt injection is a confused deputy problem. An agent acting on untrusted input can be tricked into using its access for an attacker. Authorization won't stop the trick, but it decides how much damage it can do. That puts IAM at the center of AI risk.

Least privilege becomes least dynamic privilege. You can't predict what an agent will do, so scope access to the task and let it expire in minutes. No static API keys sitting in a config file.

Human in the loop is an authorization tier. Reading data: automatic. Low risk changes: automatic, with logging. Payments, data exports, access changes: a human approves.

Attribution has to survive. Your logs should show which agent, acting for which person, with what permission, did what. Most orgs log the service account and lose the human.

Agents need a lifecycle. Agents get created and forgotten, leaving orphaned identities with standing access. Same joiner, mover, leaver discipline: an inventory, a named owner, an expiry date, regular reviews.

None of this is new. It's IAM fundamentals applied to a new kind of identity.

How is your org handling agent identity today?

#IAM #IdentitySecurity #AgenticAI #NHI #Cybersecurity

Next
Next

Attribute Based Access Control (ABAC)