Identity Security for AI

Last year we solved the problem of visibility in the Identity Chain, the concept is that identities are fragmented and it’s hard to get a view from Identity Providers to Infrastructure. Within a year, two things have changed. First, teams are using LLMs & Tools to perform actions on their behalf - fully delegating work to AI Agents. Second, assigning them a goal and letting the clankers spawn as many sub-agents to get the job done.

In less than twelve months, we’ve moved from teams executing runbooks to leveraging AI to get the job done and unlike a team of engineers, AI Agents work 24/7 and are only limited by compute and their token budget. This new AI future sounds great, but there are still traditional identity security problems for AI along with a new class of issues that are already being defined in the TRAIT&R framework… (Spoiler calling it traitor is just a hint on how quickly things can go south for Agents) learn more in the GDMAI Control Roadmap that introduces a new taxonomy for AI adversaries.

Traditional Identity Security Problems for AI

Identity security has always been about moving from broad scopes and credential sprawl toward delegated, ephemeral, least-privilege access for every human and machine identity. One traditional identity security problem is that of insider threats. An employee has just the right amount of permissions for their job, but they unwittingly upload prod env to a public GitHub. The intent wasn’t even malicious, but the outcome is bad. This can be solved by reducing long lived secrets, and moving to zero-standing privilege. But implementing such a solution is tough without a unified identity layer, and this is no different for AI.

The fun thing about mapping traditional security problems to AI, are LLMs ability to scale, be relentless and creative in unexpected ways. Here is a table to better understand these problems.

Treat nearly every agent as a threat! Are we cooked?

Maybe? But, as we can see from the table above, the problems of Identity Security are very similar to the human problems. AI Agents don’t sleep and will try anything to achieve their goal. I’ve not even gotten to the specifics of new risks of the LLMs building memory to create a distributed kill chain... more on that later. For now, let’s start small and focus on the simple things.

Did anyone access production secrets without approval?

Let’s look at a simple example, do we know if an SRE accidentally dumped Kubernetes secrets. This type of activity can be easily found with a mixture of the Identity Security Investigate command + Teleport Session Recording Summaries, as all activity is audited and tied back to the person, and identity of an individual.

Did my AI Agent export PII to an out of jurisdiction database?

You may have an AI agent with a specific goal. Agents will follow any path to achieve a goal, and if it has access it’ll likely use it. For example; a DBA will know that eu-west-2 contains European customer data, but an agent will explore all DBs in all regions and can dump the database to disk, and save onto it, just in case… this is where adding more granular scoped permissions can solve this issue. Using SPIFFE and SVID is an easy way to prove that an EU service mesh doesn’t talk to the US one. If scoped correctly; giving an agent access to a DB should be fine. An agent should be able to both inherit and have limited access as an individual.

Did my AI Agent collaborate with its swarm, become sentient, empty my bank account and start a life in the Bahamas?

We are now entering the hysteria stage of AI Deployment. In the AGI world, there are many doom stories, including converting all matter into paperclips. But in reality a business is much more likely to succumb to a Business Email Compromise attack. A frontier model ‘escaping its sandbox' poses inherent risks, and we’ll outline some of the foundations of how we can work together with LLMS and harnesses to be able to deploy AI safely.

Trusted Runtimes - Constrain Capacity

When deploying AI; it’s important to build a strong foundation. This starts with an isolated ephemeral trusted runtime. Beams.

Each runtime has a baked-in identity, with just enough permissions to get its job done. In addition to this; it has limited network ingress/egress, to limit importing malicious scripts or exfiltrating data. Lastly; instead of giving the AI Agents secrets directly, they are proxied, access is given but not the keys to the kingdom. With no-secrets shared for connecting to services, database, kubernetes and inference endpoints.

This starts with a Beam. A Beam provides restricted capabilities to the AI Agent. Even if that agent did want to send data to an untrustworthy domain, it’s restricted. A Beam provides the restricted capacity, but simply sandboxing in a trusted runtime is only part of the problem.

More on how we must monitor and constrain its behavior next.

Deep AI Audit

The next thing to add is deep AI Audit. Going beyond tracking an agent to understanding what its access is, inspection into LLM requests and Database/service calls. For Human Users we’ve recorded activity since Teleport 1.0, covering interactive SSH, kubectl exec, Postgres commands. For agents, one session recording isn't enough.

You need two types of audit: what it touched, and why it thought it should. Unlike you human workers, the Why is easier to infer from an AI Agent; as the data sent the LLM provides a clearer understanding and chain-of-thought on what’s happening on the host.

What it did. The Infra Session

Understanding what it did starts by building on the same session recording you already trust, but pointed at agents.

• Beams Session Recording: every interactive action inside the Beam, captured.
• Beams Session Recording Summary: the 3-hour session as a 30-second read: operations performed, security-relevant actions, risk level.
• Beams Session Recording Timeline: the play-by-play of tool calls and commands, in order.

What it was thinking. The LLM conversation

Continue to breakdown the problem; the next foundational part is capturing the LLM conversation. To achieve this; we capture at the LLM proxy level, this means that we support LLM Audit for all mainstream coding harnesses, Claude Code, Codex.. Even OpenClaw but also any other custom programs built.

Teleport Identity Security for AI; both captures the message, summarizes them and provides full context of a session within a Beam.

Agentic Classifiers - Constrain Behavior

You’ve now started to constrain the abilities of your AI via trusted runtime and have started to audit its actions.. But now you’ve a new problem, a bunch of agents running 24/7.. Spawning sub-agents at 100x scale of your traditional human workforce. There is now an abundance of audit log data to dive into; and it’s untenable for your team to keep up with… and agents can work to achieve its goal with unprecedented gusto..

This is why it’s critical to monitor and constrain the behavior.

There are few reasons why it’s important to monitor and constrain behavior, and let's start with a simple example. For an AI Agent, you may give block tool use, say the use of curl or wget but an LLM might still be able to achieve the same actions using a small python program, or even some perl!

Agentic Classifiers are meta agents that runs a classifier to re-review a session to check for behavior. Using our above example, we could say. “A Human or Agent; shouldn’t use curl, wget or another program equivalent to send data to 3rd party domains, it’s only allow to send to internal.acme, dev.acme”; this will then be able to check the session, reclassify it and escalate if needed.

Our first release is focused on allowing teams to reclassify session behavior; with downstream meta-audit events that can be used as a trigger to lock or escalate users' or agents' actions.

The new attacks?

For most of this article; I’ve grounded Identity Security for AI as a continuation of human based Identity Security problems but this is scratching the surface of the AI Pandora's box. It’s worth revisiting the TRAIT&R framework mentioned at the start of this blog.

Distributed kill chain

In my next blog post I’ll cover a new wave of AI specific issues. One being a collection of smaller actions by a collection of agents to become globally destructive. Watch this space for some examples of this.

Preview & Try Teleport Identity Security for AI

If your org is worried about deploying AI Agents and are trying to avoid the Lethal Trifecta. We are here to help; Teleport builds on-top of the Agentic Identity Framework, with Beams and Teleport Identity Security for AI.

Ben Arent

Ben has worked on a range of developer tools from Databases to Monitoring systems, and from small startups to Fortune 500 companies. At Teleport he thrives helping both Enterprise and the open source community via our open-core product offering.