I have found that most agent security discussions start too late. They inspect logs after the agent has already called a tool, touched a database, or opened a production shell. That is not enough once agents move from Slack demos into deployment workflows, incident response, data analysis, or infrastructure automation.

Teleport’s Agentic Identity Framework is interesting because it treats identity as the control plane for agents. The January 27, 2026 framework announcement was not just another “secure AI” positioning exercise. It made a concrete claim: autonomous and semi-autonomous agents need first-class cryptographic identities, ephemeral credentials, scoped delegation, runtime containment, and tamper-resistant audit. Teleport then made that more tangible with Beams on March 19, 2026, followed by Delegated Identity and LLM Proxy in the Beams public beta on June 16, 2026.

The practical takeaway is not “buy one product and stop thinking.” The useful part is the blueprint. Even if you use Microsoft Entra Agent ID for governance, Google Cloud IAM for cloud-native agents, Cloudflare for token hygiene, or SPIFFE/SPIRE in Kubernetes, the same production questions keep coming back: who is this agent, who delegated authority to it, what can it reach, what instructions did it receive, where did it run, and can we prove what happened?

Why does the old service-account pattern break for AI agents?

The old pattern is familiar: create a service account, put an API token in a secret manager, inject it into a job, and rely on logs if something breaks. That works tolerably for deterministic software with a narrow call graph. It breaks down for AI agents because the call graph is partly created at runtime.

When building internal automation around LLM tool calling, I ran into this exact problem. The agent did not just call get_ticket() and summarize_ticket(). It discovered tools, retried operations, chose between data sources, and sometimes asked for broader context than expected. The security question changed from “does this service need the token?” to “does this agent need this authority for this task, after this instruction, in this runtime, right now?”

Shared service accounts blur the evidence chain. If three agents and two cron jobs all use prod-automation@company, a later audit can tell you that the account changed something, but not which agent was acting under whose authority. Human tokens are worse. They make the agent look like the operator, which breaks least privilege and makes incident response awkward. Static secrets add another failure mode: once the token lands in a runtime, prompt logs, tool output, or a compromised dependency can leak it.

Cloudflare cited GitGuardian data that more than 28 million secrets were published to public GitHub repositories in 2025, with AI making leaks happen faster. That matches what I see in practice: LLM-assisted workflows increase the amount of generated glue code, config, and copied examples. If your agent security model depends on developers never pasting a token into the wrong place, the model is already fragile.

For related background on tool boundaries, see MCP security for production AI agents and LLM gateway patterns for platform teams. The identity layer sits underneath both.

What is Teleport’s core claim about agent identity?

Teleport’s core claim is that agent identity should be first-class, cryptographic, short-lived, and tied to infrastructure access. An agent should not impersonate a person. It should not borrow a general-purpose machine credential. It should have its own identity, and that identity should be constrained by delegated task authority.

That sounds obvious until you map it onto a real production workflow:

1. A human operator asks an agent to investigate a failed deployment.
2. The agent receives a delegated task with a narrow time window.
3. The agent runs inside an isolated Beam runtime.
4. The agent sends model traffic through Teleport LLM Proxy.
5. The agent calls approved MCP servers or infrastructure tools.
6. The agent accesses only registered resources allowed by policy.
7. The audit log records the delegation, prompts, model responses, tool calls, access decisions, and runtime termination.

The key difference is that identity is not just a record in an admin console. It becomes the enforcement point for model access, tool access, network access, and infrastructure access.

Teleport’s survey of more than 200 infrastructure leaders found that 69% believed widespread AI adoption would require significant identity management changes, while only 2% disagreed. I would not over-read a vendor survey, but the direction is consistent with what platform teams are already discovering. Agents are non-human identities with unusual behavior: they are dynamic like users, automated like workloads, and often privileged like operators.

What are the five layers of a production AI agent identity framework?

The framework I would use with a platform team has five layers: identity, delegated access, inference control, runtime isolation, and audit. Teleport’s blueprint maps cleanly onto those layers, but the model is useful even outside Teleport.

The important engineering choice is to enforce these layers inline. After-the-fact monitoring helps with detection, but it does not stop an agent from using an overpowered token at 2:00 a.m.

How should each agent get a first-class cryptographic identity?

Each production agent should have its own identity, not just a label in a YAML file. In practice, that means the runtime can prove who it is using short-lived credentials, preferably bound to workload attestation rather than copied into an environment variable.

For infrastructure teams, this often means X.509-style workload identity, SPIFFE IDs, or a vendor-managed equivalent. A useful identity shape looks like this:

spiffe://example.com/agents/deploy-auditor/prod

That identity can be mapped to policy:

agent:
  id: spiffe://example.com/agents/deploy-auditor/prod
  environment: production
  allowed_tools:
    - read_deployment_status
    - read_kubernetes_events
    - read_ci_logs
  denied_tools:
    - kubectl_exec
    - rotate_database_credentials

The exact syntax depends on your stack, but the principle matters more than the file format. The agent identity should be separate from the user identity, the cloud service account, and the model provider key. That separation lets you answer three different audit questions:

• Which human or system delegated the task?
• Which agent executed the task?
• Which infrastructure identity was used for each resource access?

Google Cloud’s Agent Identity guidance points in the same direction by recommending per-agent identities instead of shared service accounts. Red Hat’s emerging pattern uses SPIFFE for workload identity, RFC 8693 token exchange for delegation, and Kagenti for lifecycle and policy binding. Microsoft Entra Agent ID focuses more on enterprise identity governance, lifecycle, sponsorship, Conditional Access, and managed agent identity workflows.

Teleport’s differentiator is that the same identity story is connected to production infrastructure access. That matters when the agent needs to reach databases, Kubernetes clusters, SSH hosts, cloud APIs, and internal services across environments.

How does Delegated Identity change least privilege?

Delegated Identity is the most useful idea in Teleport’s framework because it matches how real agent work is assigned. A human or parent agent grants an agent authority for a specific task, not broad standing access.

In practice, I would model effective permission as an intersection:

effective_agent_access =
  human_delegate_scope
  ∩ agent_policy_scope
  ∩ task_scope
  ∩ environment_scope
  ∩ runtime_allow_list

If any one of those scopes does not allow the action, the action should fail. This is the difference between “the agent has a production token” and “the agent can read deployment state for service A for the next 30 minutes because Alice delegated incident triage.”

Here is a concrete example:

delegation:
  delegated_by: alice@example.com
  agent: deploy-auditor
  task: investigate-checkout-api-deploy
  expires_in: 30m
  allowed_resources:
    - k8s:prod:namespace/checkout
    - ci:github-actions:repo/checkout-api
    - logs:datadog:service/checkout-api
  allowed_actions:
    - read
    - summarize
  requires_approval:
    - rollback
    - exec
    - credential_rotation

This is also where MCP security becomes practical. An MCP server is not safe just because it exposes a nice tool schema. The policy needs to decide which agent can call which tool, under whose delegation, with which arguments, against which environment. A read-only incident assistant and a deployment remediation agent should not share the same MCP permissions.

Cloudflare’s Principal, Credential, and Policy framing is useful here. Their scannable token formats, OAuth visibility, resource-scoped RBAC, and automatic revocation help with token lifecycle and non-human identity hygiene. Teleport goes further on the infrastructure side by making delegated authority part of the agent runtime and access path.

Why is LLM Proxy different from a generic LLM gateway?

Generic LLM gateways usually start with routing, cost control, provider abstraction, rate limits, and prompt logging. Those are useful. They are not the same as identity-aware enforcement.

Teleport’s LLM Proxy sits between an agent and its inference endpoint, inspects every request and response, applies per-Beam allow lists, and writes activity into Teleport’s audit log. The important part is the linkage: model traffic is connected to agent identity, task delegation, runtime, and downstream infrastructure access.

That linkage changes the control surface. For example, a gateway can say:

model request from beam-123 used gpt-4.1-mini and cost $0.02

An identity-aware proxy should help answer:

deploy-auditor received this prompt during task T,
under delegation D,
got this model response,
then requested tool X,
then accessed resource Y,
and policy allowed or denied it for reason Z.

That is the evidence chain security teams need during incident response. If a prompt injection tells the agent to ignore previous instructions and dump environment variables, the proxy is one place to detect and block dangerous instruction patterns before tool execution. It should not be the only control, because prompt screening is imperfect, but it is valuable when combined with tool policy and runtime isolation.

I would still keep standard gateway controls: model allow lists, token budgets, provider failover rules, rate limits, data loss prevention checks, and redaction. The trade-off is latency and operational complexity. Every inline control adds another component that can fail or slow down the agent. For production infrastructure agents, I usually accept that cost for high-risk workflows and keep lighter controls for low-risk summarization or documentation tasks.

What role do Beams and Firecracker VMs play?

Teleport Beams turn agent execution into a controlled runtime problem. Each Beam runs in an isolated Firecracker VM with filesystem and network isolation, built-in identity, infrastructure connectivity without secrets, and audit from start to termination.

That is a stronger boundary than running a privileged agent in a long-lived container with broad network access. Containers are still useful, but they are not a complete security model by themselves. A high-risk agent should not be able to scan internal networks, read unrelated mounted secrets, or persist state after the task ends.

The runtime controls I would expect for production agents are:

• Ephemeral runtime per task or session.
• No long-lived secrets injected into the filesystem.
• Outbound network allow lists.
• Separate identities per agent and environment.
• Resource access through registered services, not raw network reachability.
• Automatic cleanup when the task ends.
• Full lifecycle logging.

The trade-off is operational friction. Firecracker isolation is heavier than a local process. It may complicate debugging, dependency packaging, and cold starts. For agents that only summarize public documents, that overhead may be excessive. For agents that can inspect production databases, trigger deployments, or touch cloud APIs, the isolation is exactly where I would spend complexity.

What should an audit trail prove?

An agent audit trail should prove more than “a request happened.” It should reconstruct the chain from delegation to action.

For every meaningful action, I want to answer:

• Who or what created the task?
• Which human, workflow, or parent agent delegated authority?
• Which agent identity executed the task?
• Which runtime hosted the agent?
• Which prompt and model response preceded the tool call?
• Which MCP tool, API, shell command, or database operation was requested?
• Which policy allowed or denied the action?
• Which resource changed?
• When did the runtime terminate?

This is where Teleport’s infrastructure background matters. Audit logs are already central to SSH, Kubernetes, database, and cloud access. Extending that pattern to agents is more convincing than treating agent telemetry as a separate observability stream that security teams have to stitch together later.

For more on the workload identity side of this problem, see SPIFFE and workload identity for platform engineers.

How does Teleport compare with Cloudflare, Microsoft, Google, and Red Hat?

No single vendor owns the whole agent identity problem. The better question is where each approach is strongest.

In practice, many large teams will combine these. For example, Entra may remain the enterprise governance layer, Teleport may control infrastructure access, Cloudflare may handle token scanning and edge policy, and SPIFFE may identify Kubernetes workloads. The risk is duplicate policy with inconsistent answers. The design goal should be one clear decision path for each action, not five dashboards that all know part of the story.

What reference architecture should platform teams start with?

A practical starting architecture looks like this:

Human operator
  -> delegates task with scope and expiry
  -> agent starts in isolated Beam runtime
  -> runtime receives short-lived agent identity
  -> model traffic passes through LLM Proxy
  -> MCP/tool calls are checked against task policy
  -> infrastructure access goes through zero trust controls
  -> audit log links delegation, prompt, tool call, resource action
  -> runtime terminates and credentials expire

The first implementation does not need every possible control. I would start with one high-risk workflow, such as production incident investigation. Make the agent read-only. Give it access to logs, deployment metadata, Kubernetes events, and CI output. Deny shell execution, rollback, credential rotation, and cross-environment data movement unless a human approves the step.

Then test the uncomfortable cases:

• Can the agent access a namespace outside the delegated task?
• Can prompt injection convince it to call a denied tool?
• Can it reach an unapproved model endpoint?
• Can it exfiltrate secrets through model output?
• Can it keep working after the delegation expires?
• Can an auditor reconstruct the whole session without asking the developer who built it?

If the answer to any of those is unclear, the architecture is not production-ready yet.

What implementation checklist should teams use?

Start with inventory. List agents, owners, model endpoints, MCP servers, tools, cloud APIs, databases, queues, CI systems, and internal services. Most teams underestimate how many unofficial agents already exist in scripts, notebooks, IDE extensions, and support workflows.

Then move through the controls in order:

1. Replace shared accounts and embedded API keys with per-agent identity.
2. Use short-lived credentials with no standing privilege.
3. Define who can delegate authority, for what task, for how long.
4. Enforce least privilege at tool, MCP, network, database, cloud API, and model endpoint boundaries.
5. Put an identity-aware proxy or gateway in front of model traffic.
6. Run high-risk agents in isolated, ephemeral runtimes.
7. Add human approval for destructive actions, privilege escalation, production changes, and cross-environment data movement.
8. Log delegation, prompts, responses, tool calls, policy decisions, resource access, and runtime lifecycle events.
9. Review stale identities, shadow MCP servers, leaked credentials, and anomalous behavior.

The sequencing matters. If you start with a beautiful audit dashboard while agents still use broad static tokens, you have observability but not control. If you start with isolated runtimes but no delegated authorization, you have containment but not least privilege.

What failure modes should be designed out early?

Prompt injection is the obvious one, but it is not the only one. An attacker does not need to “jailbreak” a model if the agent already has a powerful token and a permissive tool surface.

The failure modes I would prioritize are:

I’ve found that the best design reviews ask boring questions repeatedly: where is the credential, who can grant access, what denies the action, and where is the audit record? If the team cannot answer those questions with specific configs, the agent is still a prototype.

When is Teleport’s blueprint the right fit?

Teleport’s blueprint is strongest when agents need production infrastructure access: SSH, Kubernetes, databases, internal services, CI/CD, cloud APIs, or multi-environment operational workflows. It is also a good fit when security teams already care about zero trust access, short-lived credentials, session audit, and privileged access management.

It may be more than you need for low-risk content generation, offline analysis, or agents that only operate on synthetic data. In those cases, a lighter model gateway plus scoped application credentials may be enough. The trade-off is future migration. Agents tend to grow from “summarize this” to “take action on this” faster than governance processes expect.

My default recommendation is simple: if an agent can change production state, read sensitive data, execute tools, or influence another system that can do those things, give it a real identity and a bounded runtime. Teleport’s Agentic Identity Framework gives a concrete version of that model: first-class identity, delegated authority, LLM Proxy enforcement, Firecracker-backed isolation through Beams, and audit that follows the agent from prompt to action.

FAQ

What is an AI agent identity framework?

An AI agent identity framework is a security model that gives each agent its own identity, scoped authority, runtime boundary, model access controls, and audit trail. The goal is to stop treating agents like scripts with API keys and start treating them like managed non-human identities.

How is Teleport’s Agentic Identity Framework different from normal IAM?

Normal IAM usually governs users, service accounts, and workloads. Teleport’s framework focuses on agents that receive dynamic instructions, delegate work, call tools, and access production infrastructure. It connects identity to task delegation, LLM traffic, runtime isolation, and infrastructure audit.

Is LLM Proxy the same as an LLM gateway?

Not exactly. A generic LLM gateway often handles routing, spend, provider abstraction, and prompt logging. Teleport’s LLM Proxy is positioned as identity-aware enforcement tied to Beams, delegated authority, inference endpoints, and Teleport’s audit log.

Do AI agents need isolated runtimes?

High-risk agents do. If an agent can reach production systems, sensitive data, or privileged tools, runtime isolation limits filesystem access, network reachability, credential exposure, and persistence after the task ends. For low-risk agents, the overhead may not be justified.

Should every agent have its own identity?

Yes for production use. Shared accounts make attribution weak and least privilege difficult. Per-agent identity lets teams apply scoped policy, short-lived credentials, delegated authority, and audit records that show exactly which agent acted under which task.