Skip to main content
All right — we’ve already covered prompt injection and the risks created by overprivileged agents. This article completes that foundation by explaining the three primary controls that together secure agentic workloads: identity, runtime security (containment), and observability.
  • Identity answers who (or what) is acting.
  • Runtime security limits what the agent can reach while it runs.
  • Observability provides the evidence needed to understand what actually happened.
You can remember these as identity, containment, and evidence. A helpful way to connect them is to follow an agent through its lifecycle: the controls you apply before it runs, while it runs, and after the run.
  • Before execution: identity answers who is making the request — both the agent’s workload identity and any user or service it acts for.
  • During execution: runtime security enforces boundaries (isolation, network restrictions, tool policies, and human approvals).
  • After (and throughout): observability records what happened so you can audit, investigate, and meet compliance requirements.
Identity establishes who. Authorization defines what the agent can do. Runtime controls enforce boundaries. Observability records the evidence.
A dark-themed slide titled "One Agent - Three Security Layers" that outlines three columns: Identity, Runtime Security, and Observability. Each column poses a guiding question—Who is making this request? What can it do right now? What actually happened?

​
At-a-glance: the three layers

Think about these controls in lifecycle terms: identity before a run, containment during a run, and evidence both during and after the run. Use all three together — none is sufficient on its own.

​
Identity

A risky and common pattern is to assign many agents a shared service account with broad administrative permissions and long-lived credentials. That pattern creates two hazards:
  • Excessive privileges (violates least privilege).
  • Logs that cannot distinguish one agent from another — or an agent from a human.
Safer alternative:
  • Give each agent a distinct workload identity.
  • Scope its permissions narrowly (least privilege).
  • Use short-lived credentials that are issued on demand and expire quickly.
  • When an agent acts on behalf of a user, use delegated access (for example, an on-behalf-of token exchange) so logs preserve both identities: which agent performed the action and on whose behalf.
Example (illustrative):
Design principles:
  • Give agents distinct workload identities.
  • Use short-lived credentials.
  • Grant the least privilege necessary.

​
Runtime security (containment)

Identity tells us who the agent is; runtime security controls the environment where the agent executes. The central idea is a sandbox: an isolated filesystem, CPU/memory limits, time limits per run, and caps on token usage or spend. By default, block high-risk resources (open internet access, production databases, raw shell access). Allow approved capabilities through explicit guardrails: API/tool allowlists, required human approvals for high-impact actions, and policy checks (for example using Open Policy Agent) on privileged operations. These runtime controls are designed with the assumption that prompt-level defenses can fail — prompt injection can still happen. A properly configured sandbox and runtime guardrails can turn a compromised instruction into a failed attempt rather than a production incident. Important: sandboxing does not replace authorization — use both together.
A dark-themed infographic titled "Contain the Agent at Runtime" showing a sandboxed agent in the center with "blocked by default" items on the left (open internet, production database, raw shell access) and guardrails on the right (allowlist of APIs/tools, human approval, logging). The sandbox details limits like its own filesystem, CPU/memory/token/spend caps, time limits per run, and policy checks on privileged actions.
Runtime controls checklist (examples):
  • Sandbox: isolated FS, ephemeral containers, no host mounts.
  • Resource caps: CPU, memory, execution time, token limits, spend limits.
  • Network boundaries: deny-by-default egress; allow explicit endpoints.
  • Tool/API allowlists: only approved integrations.
  • Human-in-the-loop: approvals for high-impact actions.
  • Policy enforcement: automatic checks using a policy engine such as OPA.

​
Observability (evidence)

Observability gives you an auditable trace of what happened during a run. A robust trace should include:
  • Agent identity and any delegated user identity.
  • Model calls and token usage.
  • Tool calls and their responses.
  • Policy decisions and human approvals.
  • Timing, costs, and other run metadata.
Traces enable:
  • Real-time detection (e.g., flagging a draft that contains an external address).
  • Post-run reconstruction and investigation.
  • Compliance and audit evidence when you cannot exactly replay a model output.
Example trace (illustrative):
A trigger like “external address in draft” can cause the system to hold the action for review, giving investigators time to respond while the run is still in progress. Because model outputs and external systems can vary, an exact replay may be impossible — but a trace preserves trustworthy evidence for reconstruction, auditing, and incident response.
Traces may contain sensitive data (prompts, tool requests, PII). Protect traces with redaction, encryption, strict access controls, and curated retention policies.

​
Quick assessment checklist for any agent

If you can’t answer these, mark them as remediation priorities.

​
Summary

Identity, containment, and evidence form a practical, layered foundation for securing agents:
  • Give each agent a distinct identity with short-lived, least-privilege credentials.
  • Limit what the agent can reach at runtime with sandboxing, allowlists, policy checks, and human approvals.
  • Preserve reliable observability so you can detect, investigate, and audit what the agent did.
This article covers the foundational controls. Each area has additional design patterns and operational details to explore (for example, identity delegation flows, sandbox orchestration, and structured trace schemas). Use the checklist above to evaluate your current agent architecture and prioritize improvements. In the final section, we’ll bring these concepts together into a single, complete picture.

Watch Video