The Limits of Single-Layer Security
Every few months, the industry converges on a new silver bullet for AI agent security. First it was static analysis. Then Docker sandboxes. Then AI-powered firewalls. Each approach solves a real problem. None of them solves the whole problem.
Understanding why requires examining what each layer catches and, more importantly, what it misses.
Static analysis alone
Catches what is in the files: prompt injection patterns, credential exposure, supply chain risks. But a clean skill can still be exploited via indirect prompt injection at runtime. Static analysis sees the code; it does not see the conversation.
Runtime isolation alone
Docker sandboxes constrain the blast radius, but they do not inspect the payload. A sandboxed agent running a malicious skill is still compromised within its boundary. The container limits what the attacker can reach, not whether the attacker gets in.
AI firewalls alone
LLM-based detection from products like Lakera and Cisco AI Defense is non-deterministic by design. The same input can produce different classification results on consecutive runs. This makes it unsuitable as a sole control for environments that require audit-grade consistency and regulatory compliance.
The pattern is familiar. It is the same lesson the industry learned with network security, endpoint security, and application security: no single control is sufficient. Each control addresses a specific attack surface. Defense in depth means layering controls so that the failure of one does not mean the failure of all.
The Three-Layer Framework
A defensible architecture for AI agents requires three distinct layers, each operating at a different phase of the agent lifecycle. Together, they form a security envelope that covers the full attack surface: from skill deployment, through resource access, to inter-agent communication.
Pre-Runtime: Static Analysis
Scans skills, configurations, and tool definitions before deployment. Deterministic rules produce the same output for the same input, every time. Catches prompt injection, credential exposure, configuration risks, and MCP tool poisoning. Runs in CI/CD as a deployment gate.
Runtime: Isolation
Micro VM and container isolation with network proxy. Credentials are injected at the proxy level so the agent never sees raw API keys. Filesystem scoping restricts each agent to its own workspace. Network access is deny-by-default with explicit allowlists for approved endpoints.
Runtime: Enforcement
Inter-agent message inspection with content scanning on every message. Cryptographic identity via Ed25519 signed messages. A policy engine using YAML rules to define allowed communication patterns. Immutable audit trail for compliance. Anomaly detection with automatic agent suspension.
How the Layers Interact
These layers are not redundant. They are complementary. Each one operates on a different dimension of the problem, and each one catches threats that the others structurally cannot.
Static analysis blocks malicious skills before they enter the runtime
A skill containing a prompt injection pattern, an embedded credential, or a suspicious npx -y invocation is flagged and blocked before it can be deployed. The runtime never sees it.
Runtime isolation constrains access to system resources
If a threat evades static analysis, maybe via a clean skill that gets exploited through indirect prompt injection at runtime, the sandbox limits what the compromised agent can access. No filesystem access outside its workspace. No network calls outside its allowlist. No raw credentials.
Runtime enforcement monitors and controls agent behavior
Even within the sandbox boundary, the enforcement layer inspects every inter-agent message, verifies cryptographic identity, evaluates policy rules, and logs every decision. If an agent starts exhibiting anomalous communication patterns, it gets suspended automatically.
The security property of this architecture is not that any single layer is impenetrable. It is that an attacker must defeat all three layers simultaneously to achieve full compromise, and that each layer produces forensic evidence that makes the attack detectable.
Enterprise Requirements Mapped to Layers
For security leaders evaluating AI agent deployments, the framework maps directly to the compliance and governance requirements that procurement teams ask about.
| Requirement | Control | Layer |
|---|---|---|
| SOC 2 audit trail | Immutable logs with content hashes, sender identity, and policy decisions | Layer 3 |
| Supply chain risk | Static scanning of third-party skills and MCP tool definitions before deployment | Layer 1 |
| Zero-trust architecture | Cryptographic identity (Ed25519), policy-based communication enforcement | Layer 3 |
| Data loss prevention | Scan for exfiltration patterns + network isolation + message inspection | Layers 1 + 2 + 3 |
| Incident response | Forensic logs with sender identity, content hashes, and policy decision rationale | Layer 3 |
| Least privilege | Filesystem scoping, network deny-by-default, credential proxy injection | Layer 2 |
| Vendor risk management | Continuous monitoring of public skill registries for emerging threats | Layer 1 |
The Oktsec + Aguara + Docker Stack
This framework is not theoretical. It is implemented across three open-source products that compose into a complete defense-in-depth stack for AI agent deployments.
Static analysis engine for MCP servers, AI agent skills, and configuration files. Deterministic rule-based scanning before deployment.
Micro VM isolation with network proxy for credential protection, filesystem scoping, and deny-by-default network access.
Runtime enforcement for agent-to-agent communication. Message inspection, cryptographic identity, policy engine, and audit trail.
Continuous monitoring of public skill registries, scanning for emerging threats across the ecosystem in real time.
Each component is independently useful. A team deploying only static analysis gets value from Aguara alone. A team already using Docker sandboxes can add Oktsec for runtime enforcement without changing their isolation strategy. The stack composes because each layer addresses a distinct phase of the agent lifecycle.
Open Source and Operational Today
This framework is not a roadmap. Every component described in this article is open source, self-hosted, and running in production. No LLM dependency, no cloud requirement, no vendor lock-in.
AI agents are being deployed at enterprise scale. The organizations that adopt defense-in-depth architectures now will be the ones that can move fast without creating unmanageable risk. The ones that rely on a single layer will learn the same lesson every other security domain has already taught.
Start building your defense-in-depth stack
Every component is open source. Deploy incrementally, starting with the layer that maps to your most urgent requirement.