Introducing Teleport Beams: A Trusted Runtime for Securing Agents in Production Infrastructure

Many organizations want to run agentic AI in production, but stay stuck worried that an autonomous agent will go rogue and open up serious infrastructure risk. Teams split into three camps: keep agents away from production entirely, let them run wild and hope for the best, or approve every single action by hand. None of these scale.

Many of the same problems and legitimate fears keep coming up:

• Preventing deletion of production databases
• Guarding against prompt injection
• Preventing harm from agent misalignment
• Maintaining full audit trails of prompts and autonomous decisions
• Letting agents work alongside people without trading oversight for blind trust
• Removing barriers to agentic automation without removing the guardrails

Teams don't need fragile workarounds like ad-hoc policies and tooling shoehorned in to handle overprivileged agents running on broad human credentials as you. They need a system designed specifically for the job, with least privilege scoped access at its core.

We combined the Agent Trust principle ideas with what we heard from our customers and then created the solution, iterated on it by dogfooding it internally, and from that we created an entirely new product.

Today, we're excited to announce Teleport Beams.

Beams Runtime: Built Around Pillars of Agent Security

Running agents against production autonomously, connected to real resources, without causing problems takes more than a sandbox. That's the gap Beams closes.

Beams runs agentic workloads in cloud hardened, auto-expiring micro-vms, limiting possibility and blast radius of a potential breach. Every agent gets its own delegated identity instead of impersonating users or service accounts so by default there are no secrets to steal and nothing stale to clean up.

Let's learn a bit more about how this works:

BEAMS Runtime — the complete operational environment: compute, networking control, identity, bounded resource connections, observability, monitoring and lifecycle control. Updating production databases will rely on a runtime to execute an agent workflow with identity checks, audit logging, and resource limits.

• Agentic identity. Every agent gets its own X.509 identity without access to private key material. Agents can offer execution plans for human or agentic review. Guardrails are enforced statically inside an immutable environment, so they can't be changed mid-process without an agentic JIT request. Most teams run agents with a user's full access, Beams flips the script and scopes that down to a least-privilege identity tied to the task needs.

• Secure access control. Each agent uses passwordless authentication to infra (IAM, Kerberos, X.509), auto-discovery of cloud accounts/K8s/databases, bring-your-own-model routing (e.g. AWS Bedrock), and protocol-level inspection plus LLM tracing on every connection.

• Cloud isolated runtime environment. Each agent runs in a micro-VMs expiring in 12 hours with protocol traffic capture, and snapshot/fork/branch for agent state.

• Observability, Auditing, Control & Monitoring. You can't fully control what an agent decides to do, so you need visibility into what it's thinking and actions it's taking, not just a raw jsonl trace. Beams captures every message sent to an inference model, including LLM traces and protocol-level traffic, and scores each session against the MITRE ATT&CK framework. Classifiers flag behavior that departs from the agent's stated objective: goal hijacking, emergent multi-agent coordination, privilege escalation via out-of-band channels. It then will surface what happened versus what was intended and flag things for review.

Under the Hood: Key Features and Code Snippets

Phases — git for your container filesystem. Snapshot an agent's running state and filesystem at any point, fork it, and branch into multiple independent runs without losing your place. This allows you to keep a fresh container build with consistent state across agentic runs for state and memory management.

# Create a Beam with state
$ tsh phases add mygraph

# Snapshot the current state of a running Beam as a named phase
$ tsh phase snapshot

# Final snapshot and closing of the beam
$ tsh phase snapshot --final

# Fork a phase into a new, independent branch and resume from it
$ tsh phases add --fork mygraph

Delegated Identity — every agent has its own x.509 identity tied to delegated access. Instead of inheriting a user's or workload full role set, an agent gets a delegated identity: an X.509 cert with a scoped subset of roles, with a traceable link back to the human or workload that delegated it.

# Add a beams agent with a RBAC specific role
$ tsh beams add --role=<scoped-role>

Agentic JIT Requests — elevate access for an agentic process. An agent can request elevated, time-boxed access for a specific task. The request is reviewed by a human or another agent acting as reviewer, and expires automatically once the task completes. Teleport's existing JIT access-request flow, extended for agent-initiated requests.

# Create a JIT access request
$ tsh request create \
  --resource=<Var name="resource-id" description="Resource ID" /> \
  --reason="Read the application status to investigate the failed release"

Connect to MCP Securely - Tool-level RBAC for MCP servers through Teleport's identity flow, instead of a shared API key with access to everything. Developers sign in through your IdP in the browser and get short-lived certificates scoped to the tools they're allowed to use, and never handle the upstream server's credentials.

# Add MCP server access
$ tsh mcp login <mcp-server-name>

Beams is built on top of the Teleport Platform

Beams is an implementation of Agentic Identity Framework. It expands Teleport’s zero-trust architecture, leveraging our work in Zero Trust Access, Identity Governance, Machine and Workload Identity and Identity Security.

Try Beams today on https://www.beams.run and let us know what you think!