Machine Identity

Your AI agents have the keys to the kingdom

← All InsightsBy Dr. Derek A. Smith7 min read

Every AI agent you put into production is, in security terms, a new hire you never background-checked, handed a master key, and never assigned a manager. It works around the clock, at machine speed, with credentials you issued it — and in most organizations, no one can say how many there are or what they can reach.

An AI agent is not a chatbot answering questions. It is software that takes actions: it queries databases, calls APIs, writes to systems, triggers workflows, sometimes moves money. To do that it authenticates as a non-human identity — keys, tokens, and service credentials living inside your trust boundary. And here is the line I keep coming back to in The Defensible AI Program: nobody is the manager of an AI agent. The identity program you spent years building assumes there always is one.

The gap your IAM program didn’t plan for

Traditional identity management rests on five assumptions: every identity belongs to a person, access maps to a human job role, sessions start with a login and end with a logout, a manager reviews privilege periodically, and “normal” behavior is a human pattern. An autonomous agent violates all five — and each violation is a specific failure mode:

  • Privilege accumulation. Agents get broad access up front because no one knows exactly what they’ll need, and it never gets narrowed — the access review was built for humans with managers. Months later the agent can reach systems no one authorized.
  • Long-lived credentials. Agents don’t log out. They hold tokens valid for extended periods, so a stolen credential is persistent access with no authentication event for your SIEM to flag — and those secrets are rarely in the rotation program that covers people.
  • Invisible lateral movement. When an agent moves system to system on persistent credentials, it generates none of the authentication events your SOC watches for. An attacker who takes its credentials just instructs the agent to move, and it looks like normal agent behavior.
  • No behavioral baseline. Your UEBA tools know what normal looks like for a human. They have no baseline for a non-human actor, so an agent querying new systems at abnormal volume raises no alert — the deviation is invisible because the baseline was never built.
Machine identities now outnumber humans by more than 80 to 1 — and your IAM program was built to watch the other one.

That ratio comes from CyberArk’s 2025 research, and AI agents are accelerating it, because a single agent can spawn downstream identities to do its work.

Not every non-human identity is equal

Governance has to be proportionate, so the book sorts non-human identities into four classes. Class 1 is the static service account — lowest risk, where the gap is usually inventory rather than control. Class 2 is the automated pipeline identity. Class 3 is the AI model inference identity. Class 4 is the autonomous AI agent — the highest-risk class and the one your IAM program is least equipped for, because it takes actions, its access needs shift from one run to the next, and in multi-agent designs it can spawn sub-agents that are themselves identities needing credentials and oversight.

The control set for the agents that matter

The fix is to extend your identity program to non-human actors, not replace it. For Class 4 agents, that means four capabilities:

  • Inventory first. Discover every non-human identity from your IAM, PAM, API gateway, and cloud service-principal registries — then deprovision the orphans no one owns.
  • Scope-bounded least privilege with time-limited credentials — access granted for what the agent is doing now, not standing forever.
  • Behavioral monitoring with baselines built for non-human actors, plus human-in-the-loop escalation when an agent acts out of scope.
  • An audit trail detailed enough to reconstruct exactly what an agent did, including the ephemeral sub-agents that no longer exist.
Where to start this quarter
  • Run a non-human identity inventory across IAM, PAM, API gateways, and cloud — and deprovision every orphaned account.
  • Put your Class 4 agents on scope-bounded, time-limited credentials instead of standing access.
  • Stand up behavioral baselines and an audit trail for your highest-risk agents.

The goal is never to slow AI adoption. It is to make sure the identities your AI runs on are governed as carefully as the people you hire — starting with the uncomfortable step most programs skip: running the inventory, so the agents stop being keys to the kingdom you can’t see.

Dr. Derek A. Smith is founder of DAS Advisory Group and author of The Defensible AI Program. He advises federal agencies and enterprises on governing and securing AI.

Want this applied to your organization?

A 30-minute conversation on where you are and what governing your AI actually takes.

Book a Consultation

Get new briefs in your inbox

Practical AI governance and security notes, sent when there's something worth reading. No spam.