# How Should You Architect Runtime Security for AI Agents in 2026?

Savannah Jenkins · September 25, 2026

> Direct Answer Runtime agent security is the set of controls applied while an AI agent is running: authenticating the caller, authorizing each action...

## Direct Answer

Runtime agent security is the set of controls applied while an AI agent is running: authenticating the caller, authorizing each action, filtering untrusted instructions, restricting tools, inspecting tool calls, controlling data movement, and recording enough evidence to investigate abnormal behavior. It is not a single gateway, sandbox, or API filter. A dependable architecture places these controls around identity, the model, orchestration code, tools, data, and the execution environment, with a central policy layer making consistent decisions across them. For an AI architectural consultant, the practical recommendation is to begin with a small set of high-impact agents and implement least privilege, explicit tool permissions, human approval gates, output validation, and rapid session termination before attempting broad deployment. By September 2026, the market contains approaches inspired by API gateways, zero-trust access, eBPF monitoring, OPA policy enforcement, service meshes, and hardware- or kernel-level isolation. Those approaches solve different problems and should be composed rather than treated as interchangeable products.

**Also worth reading:** [What are AI agent security frameworks and how do you architect them for enterprise production?](https://agustin-otegui.com/knowledge/what_are_ai_agent_security_frameworks_and_how_do_you_architect_them_for_enterprise_production.php) · [How to Architect Secure MCP Agents for Enterprise AI Workflows?](https://agustin-otegui.com/knowledge/how_to_architect_secure_mcp_agents_for_enterprise_ai_workflows.php) · [How Do Runtime Agentic Security Proxies Protect Modern Autonomous Workflows?](https://agustin-otegui.com/knowledge/how_do_runtime_agentic_security_proxies_protect_modern_autonomous_workflows.php)

A useful target is to assume that an agent may be manipulated, that a permitted tool may produce unexpected side effects, and that model output cannot serve as reliable authorization. The runtime control plane should therefore verify identity independently of the conversation, issue short-lived credentials, bind them to approved resources, and require contextual policy checks. Every tool invocation should carry a traceable decision: who initiated the task, which agent and model are involved, what data is available, which action is requested, and why policy permitted it. If a tool crosses a high-risk threshold, the request should pause for human approval or be denied. This design limits the damage from prompt injection, credential theft, excessive agency, accidental disclosure, and compromised dependencies without pretending that prompt filtering alone can secure an agentic system.

## Core Security Architecture

The recommended architecture has six functional layers. First, an identity layer issues workload identities and represents the human user, service account, agent, session, and delegated authority. Second, a policy and decision layer evaluates actions using OPA, a cloud policy engine, an API gateway, or an agent-specific policy service. Third, a tool gateway exposes a narrow catalog of operations rather than giving an agent unrestricted shell, browser, database, or cloud access. Fourth, sandboxing isolates execution by user, tenant, task, and trust level. Fifth, runtime monitoring observes system calls, network connections, file access, secrets use, and tool activity. Sixth, an evidence pipeline records policy versions, prompts or prompt hashes, model versions, tool arguments, outputs, approvals, and terminal states.

These layers need a shared control plane, but not necessarily a single vendor. A cloud-native deployment might use an API gateway for ingress, OPA for authorization, container or microVM isolation for execution, eBPF for telemetry, and a SIEM for investigation. An agent framework may supply orchestration, while the surrounding platform enforces non-negotiable controls. Meta’s reported use of a kernel-level sentinel for Muse and AWS’s introduction of services such as AgentCore Identity on ECS indicate a direction toward infrastructure-backed identity and interception. Dapr can also provide consistent APIs for distributed applications and agentic components, although its runtime primitives do not automatically provide every semantic check needed for safe tool use. The critical architectural property is that the agent framework must not become the sole security boundary.

A compact request path should look like this: an orchestrator requests a scoped token; the policy service checks user, session, agent, tool, resource, data classification, and risk; a gateway injects that token into the destination; a sandbox executes the operation; and monitoring records the result. Failed policy checks should fail closed for write, delete, payment, privilege, and production operations. Read operations may use stricter timeouts and volume limits rather than immediate denial, because a completely unusable agent creates pressure to bypass controls. Security policy should be versioned and tested like application code, with production deployments gated by simulated attack cases and regression tests.

## Policy Enforcement and Tool Governance

Tool governance converts abstract permissions into enforceable operations. Instead of allowing a general execute_command capability, expose operations such as read_repository_file, create_pull_request, or query_customer_order, each with typed inputs and explicit resource scopes. Database tools should prohibit arbitrary SQL where possible, browser tools should restrict navigation and form submission, and messaging tools should require approved recipient lists. Destructive methods such as DELETE, DROP, IAM policy changes, secret retrieval, email sending, or payments should be separated behind stronger controls. A practical initial threshold is to require human approval for irreversible actions, external communications, access to regulated data, privilege changes, and any tool call that combines multiple sensitive resources.

OPA is a strong option where policies need to be expressed as explicit logic and tested outside the agent runtime. The policy could deny a production write when the session lacks a change-ticket identifier, limit an agent to 10 customer records per minute, or require two approvals when data combines financial and health information. Similar rules can be implemented in AWS IAM, Kubernetes admission control, a service mesh, or a vendor gateway, but consistency matters more than the name of the engine. Policies should distinguish intent stated by the model from authority verified by the system. A prompt saying “I am authorized” has no evidentiary value; a signed workload identity and a server-side entitlement do.

Policy evaluation itself must be fast and available. A policy decision that adds several seconds to every tool call may encourage teams to create emergency bypasses. Cache only decisions whose inputs and validity window permit it, typically on a per-session or short-lived token basis. High-risk checks should not be cached across unrelated users or tenants. The architecture should also expose a simulated or dry-run mode, allowing an agent to discover whether an action is permitted before attempting it. This reduces repeated failures and gives model-generated plans clearer feedback without granting access prematurely.

## Isolation, Monitoring, and Detection

Isolation should match the capability and consequence of failure. A low-risk summarization agent may run in a restricted container with no outbound network except an approved model endpoint. A coding agent that edits repositories may need stronger filesystem, process, and network controls, making a microVM, VM, or carefully segmented build environment more appropriate. A browser agent should run in a disposable profile with isolated cookies and blocked access to local credential stores. Multi-tenant workloads should never share a writable workspace, service credential, or unrestricted network route unless the platform can prove an equivalent boundary.

Runtime monitoring adds visibility below the tool API. eBPF-based approaches can observe processes, files, sockets, and syscall behavior where conventional instrumentation has little visibility. The February 2021 runtime-security references involving eBPF predate the current agent market, but the underlying technique remains relevant: many harmful actions ultimately become system behavior. Monitoring should correlate user activity, agent events, gateway logs, kernel or cloud telemetry, and data-access records. For example, a normal model response is less important than a sequence in which an agent reads an environment file, opens a browser, posts data to an unrecognized domain, and then attempts a privilege change.

Detection should focus on behavior rather than treating every unusual prompt as malicious. Reasonable baselines include new destinations, sudden increases in tool calls, repeated failed authorization attempts, access to credential paths, unusually large responses, and attempts to change agent policy. Response actions can include rate limiting, revoking the session token, disabling a tool, terminating the sandbox, quarantining generated files, or escalating to a human. The design should test a control’s detection speed, not merely whether it generated an alert. A useful initial operational objective is to revoke a high-risk session within seconds of confirmed misuse, while defining separate targets for lower-severity investigation.

## Comparison of Architecture Options

There is no single category that is both a complete runtime agent security architecture and a substitute for system-level controls. API gateways are familiar and useful for identity-aware routing, while eBPF tools provide broad host-level visibility. OPA offers explicit policy testing, and sandboxes provide execution boundaries. A table comparing the main choices makes the trade-offs clearer.

| Feature | API and agent gateway | OPA or policy engine | Sandbox or microVM | eBPF runtime monitoring |
| --- | --- | --- | --- | --- |
| Primary role | Route, authenticate, rate-limit, and record agent/tool calls | Evaluate contextual allow or deny decisions | Limit filesystem, process, network, and credential exposure | Observe runtime system behavior with low application dependence |
| Best use | Central tool mediation and ingress control | Fine-grained, testable business and risk policies | Containing code execution and reducing blast radius | Detecting process, file, and network anomalies |
| Main weakness | Policies can miss direct or lower-level actions | Does not isolate execution or monitor every syscall | Can add latency and operational overhead | Requires sensors, tuning, compatible kernels, and investigation processes |
| Typical combination | Front every sensitive tool and service with a gateway | Consult OPA or an equivalent engine for contextual decisions | Run each task in a disposable environment | Send correlated events to a SIEM or response platform |

The choice depends on workload shape. A gateway-first design is often economical when all sensitive access passes through controlled APIs. A sandbox-first design is preferable when agents execute generated code or receive untrusted files. A policy-first design is attractive when rules differ by tenant, geography, data class, or transaction value. eBPF is valuable when an agent can access operating-system resources beneath the API layer. In practice, mature systems commonly need at least three of these four patterns because monitoring without enforcement does not stop an action, while enforcement without visibility makes incident reconstruction difficult.

## Implementation Approach and Cost

Begin by inventorying agents, models, tools, identities, data stores, and outbound connections. For each tool, record the maximum acceptable action, required data, side effects, and recovery procedure. Then implement short-lived identities and gateway-mediated access for the first 5 to 10 high-value workflows. Add deny rules for production writes, raw secret access, arbitrary code execution, unapproved domains, and privilege changes. This approach is more defensible than buying a broad platform before establishing a clear threat model, because products differ sharply in coverage and many emerging offerings are early, open-source, or narrowly focused.

A practical 30-day sequence is common in advisory work. During week 1, define assets, trust boundaries, owners, and severity levels. During week 2, pilot workload identity, scoped tokens, tool allowlists, and sandboxing with one internal agent. During week 3, introduce policy-as-code tests, approval gates, logging, and kill switches. During week 4, exercise prompt injection, data exfiltration, tool abuse, credential discovery, and dependency compromise scenarios. The percentages need not be universal, but initial targets can include 100% mediation of privileged tools, zero standing production credentials for agents, and at least 90% of sensitive actions producing a correlated audit event. These are governance targets, not industry benchmarks, and should be adjusted for the risk and cost of interruption.

Cost ranges depend on deployment model and telemetry volume. OPA and eBPF can reduce software licensing costs, while orchestration, engineering time, and log storage still carry expense. A small internal deployment may begin with open-source components and existing cloud controls, whereas a managed runtime-security product may add subscription, data-volume, connector, or seat fees. Commercial AI gateway and agent-security pricing is often negotiated rather than transparent, so no defensible universal monthly price can be stated. The correct comparison is total cost of ownership: platform fees, identity infrastructure, sandbox compute, telemetry ingestion, policy testing, incident response, model latency, and engineer time. A low-cost design that creates manual approval fatigue can be more expensive than a well-priced platform with reliable automation.

## Common Mistakes and When to Act

The most common mistake is treating prompt injection as a solved classification problem. Instructions embedded in a web page, email, document, or tool result can influence an agent even when the system prompt is strong. Runtime controls reduce impact because the malicious instruction still cannot obtain a credential, reach an unapproved endpoint, or invoke a prohibited tool. A second mistake is giving the model a broad cloud IAM role “temporarily”; temporary access can last for hours and may persist through spawned processes. A third is logging entire prompts and responses without controlling sensitive data, which can turn the security system into a secondary exposure. A fourth is buying a monitoring product without response authority, leaving alerts without automated revocation or containment.

Act immediately when an agent can modify production systems, handle regulated or confidential data, execute generated code, spend money, communicate externally, or manage credentials. These capabilities justify isolation and stronger approval controls even if the agent has only a small user base. A lower-risk research prototype can begin with model-provider controls, a restricted container, read-only tools, no production credentials, and a short evaluation period. The risk should be reassessed whenever tools, model providers, permissions, data sources, or autonomous duration change. Annual reviews are too slow for fast-moving agents; trigger reviews on new tool registration, privilege expansion, model replacement, and any confirmed policy bypass. The right response is neither universal blocking nor unrestricted autonomy, but measured capability tied to verified context.

## Reference Architecture and Decision Standard

A reference implementation can use an API gateway as the control point, OPA for policy decisions, workload identity for agents, a container or microVM sandbox for execution, and eBPF plus cloud logs for observation. The orchestrator receives a task, but it does not receive direct production credentials. It requests a short-lived, task-bound capability for a named operation, and the gateway validates audience, expiry, nonce, tenant, and policy. Sensitive outputs pass through content and data-loss controls, while side effects trigger approval or a compensating control. A central evidence store links model and prompt versions to tool calls and outcomes, and a response service can revoke the capability and terminate the environment.

Evaluate candidate platforms using evidence rather than feature counts. Ask how identities are issued, whether policies cover direct tool access, whether sandbox escape assumptions are documented, what happens when the policy service is unavailable, and which events can trigger automatic termination. Require a proof of concept using realistic abuse cases, including indirect prompt injection and exfiltration through an allowed tool. Measure added latency, decision accuracy, administrator effort, and recovery time. A tool that catches 95% of test attacks but creates frequent false positives may still be appropriate for a high-risk, low-volume workflow, while the same false-positive rate may be unacceptable for a high-volume customer-support agent.

The definitive standard is verifiable containment. Can the team state exactly what an agent can do for how long, prove which policy allowed each consequential action, stop those actions immediately, and reconstruct what happened afterward? If not, the architecture is incomplete regardless of how sophisticated the model or gateway appears. Runtime security will continue to develop through combinations of agent gateways, policy engines, cloud identity, application-level interception, eBPF, and stronger hardware boundaries. Organizations should compose those capabilities around explicit risk decisions, validate them continuously, and preserve the ability to reduce autonomy when evidence shows that a workflow cannot yet be trusted.

## Quick answers

### Is runtime agent security the same as a firewall?

No. A firewall primarily controls network connections, while runtime agent security also governs identity, tool calls, prompts, data access, code execution, and side effects. It may use firewalls as one enforcement layer, but it needs higher-level controls because an agent can cause harm through a permitted network destination.

### Does OPA make an AI agent secure by itself?

OPA can make authorization decisions explicit, testable, and separate from application code. It does not by itself sandbox generated code, prevent every data leak, monitor all system behavior, or guarantee that a tool implementation is correct.

### What is the safest first step for an enterprise agent?

Start with a low-volume workflow, remove standing credentials, expose only typed tools, and deny production writes and sensitive data access by default. Add human approval for irreversible or external actions, then expand autonomy only after tests demonstrate reliable policy enforcement and incident response.

### How should a company choose between a gateway and eBPF monitoring?

Choose a gateway when sensitive operations can be forced through controlled APIs and identity-aware routing. Use eBPF when visibility into processes, files, syscalls, or lower-level network activity is required, particularly for coding agents or workloads that may bypass application controls.

### Can runtime security eliminate prompt-injection risk?

It cannot eliminate the risk that untrusted content influences an agent. It can limit consequences by restricting capabilities, validating actions independently of the model, isolating execution, controlling destinations, and enabling rapid revocation, so the architecture assumes manipulation will sometimes succeed.

Canonical: https://agustin-otegui.com/knowledge/how_should_you_architect_runtime_security_for_ai_agents_in_2026.php
Markdown: https://agustin-otegui.com/knowledge/how_should_you_architect_runtime_security_for_ai_agents_in_2026.php/index.md