igor omilaev IsYT5rUuVcs unsplash 2

AI Infrastructure Identity: Why Non-Deterministic Agents Need a New Security Model

For decades, infrastructure security has rested on a simple assumption: the entity requesting access is either a human with a login or a machine running a predictable script. Identity and access management systems were built around that assumption. A person authenticates, a policy checks their role, and a session is granted with a defined scope. A service account does the same thing on a fixed schedule, executing the same calls in the same order every time.

AI agents break that assumption. A large language model calling into a codebase, a cloud environment, or a database doesn’t behave like a static service account. It reasons, branches, and sometimes takes actions no engineer explicitly scripted. This is what security researchers mean by “non-deterministic” behavior, the same prompt can lead to different sequences of actions depending on context, retrieved data, or even randomness in the model’s sampling process. That unpredictability is precisely what makes agents useful, and it’s also what makes them hard to secure with tools built for deterministic systems.

Why Traditional Access Models Fall Short

Most enterprise access control was designed around two assumptions: identity is tied to a person or a fixed machine, and behavior is predictable enough that a role-based policy can anticipate it. Neither holds cleanly for AI agents.

A 2024 survey by the Cloud Security Alliance found that a majority of security teams had already deployed some form of AI agent or copilot with access to internal systems, yet most lacked a formal policy for governing what those agents could do once authenticated. This gap matters because an agent with a valid credential and broad scope can, in principle, take actions a human operator never would, not out of malice, but because its reasoning path diverged from what was anticipated.

Traditional identity systems also struggle with a more basic problem: attribution. When an agent acts on behalf of a user, who is actually responsible for the action? If an agent chains together five tool calls to complete a task, standard audit logs often capture only the final API call, not the reasoning or intermediate steps that led there. That’s a serious gap for any organization that needs to reconstruct what happened after an incident.

What a Security Model for Agents Actually Needs

Security engineers working on this problem generally converge on a few core requirements. An effective model for agent identity needs to:

  • Treat every agent as a distinct, auditable identity rather than folding it into a shared service account or a human’s credentials.
  • Issue short-lived, scoped credentials instead of long-lived API keys, so a compromised or misbehaving agent has a narrow and time-limited blast radius.
  • Log the full decision chain, not just the final action, so reviewers can see why an agent did something, not only what it did.
  • Apply just-in-time authorization for sensitive actions, requiring a policy check or human approval at the moment of execution rather than relying solely on upfront role assignment.
  • Continuously reassess trust, since an agent’s behavior pattern can drift over time as models are updated or fine-tuned.

This is a meaningfully different posture from conventional IAM. It borrows ideas from zero-trust architecture, including never trusting by default and verifying continuously, but applies them to an entity that can generate novel action sequences on its own. Infrastructure identity platforms such as Teleport extend identity and access controls to AI agents, reflecting the need for ephemeral, identity-bound access rather than static credentials designed for processes that follow fixed scripts. 

The Middle Ground: Identity-Aware Proxies and Session Recording

One practical pattern that has emerged is routing agent access through an identity-aware proxy rather than handing agents direct network or database credentials. In this setup, the agent authenticates through a broker that issues a short-lived certificate or token scoped to a specific task, and every command the agent runs passes through a recorded, auditable channel. This is functionally similar to how privileged access management systems have long handled human administrators accessing sensitive servers, except the session is now generated by a model rather than typed by a person.

Teleport and comparable access platforms illustrate this shift well: instead of a static SSH key or a shared API token, access is brokered per-session, tied to a cryptographic identity, and expires automatically. Applied to an AI agent, this means that even if a model is manipulated through a prompt injection or produces an unexpected action, the resulting session is still bounded by the same policy engine that governs human access, and it leaves a full record for review.

This middle ground matters because it avoids two extremes. Giving agents unrestricted infrastructure access is clearly risky given documented cases of prompt injection leading to unintended data exposure. But locking agents out of infrastructure entirely defeats the purpose of deploying them. Session-based, identity-bound brokering is one of the few approaches that lets agents do real work while keeping a verifiable record of what “real work” actually included.

Measuring the Stakes

The scale of this shift is not theoretical. Gartner has projected that by 2028, a significant share of enterprise software will incorporate autonomous or semi-autonomous AI agents capable of taking action without step-by-step human instruction. As that adoption curve rises, the number of entities with standing or dynamic access to production systems will grow well beyond the number of human employees at most organizations.

That has direct implications for incident response. Security teams accustomed to investigating a breach by reviewing a handful of human user sessions will instead need to reconstruct chains of agent reasoning, tool calls, and delegated permissions — often across systems the agent touched only briefly. Without identity infrastructure purpose-built for this, that reconstruction becomes guesswork.

What We’ve Learned

Non-deterministic agents don’t fit cleanly into identity models built for humans or static services, and pretending otherwise creates blind spots that only surface after something goes wrong. The organizations managing this well are the ones treating agent identity as its own category — distinct credentials, short-lived scopes, full session recording, and continuous policy checks rather than one-time role assignment.

Platforms like Teleport point to where this is heading: access brokered per-session, bound to verifiable identity, and logged in enough detail to answer not just what an agent did, but why. As AI agents take on more operational responsibility, the organizations that treat identity as a first-class design problem — rather than an afterthought bolted onto existing IAM — will be the ones best positioned to catch problems before they become incidents.

About The Author