TL;DR: A sidecar observes an agent from beside it rather than inside it, which is what makes its evidence independent of the agent's own account. That is the whole value, and it comes with a hard limit: a sidecar sees exactly what passes through the boundary it intercepts. Anything reaching the outside world by another path is not observed and not blocked. Knowing where that line falls is the only technical question about a sidecar that matters.
The sidecar pattern arrived in agent security by way of service meshes, where it earned its reputation: a companion process handling cross-cutting concerns so the primary workload does not have to. Applied to AI coding agents it is a genuinely good fit for one specific reason, and it is oversold for several others.
This page is about which is which. It assesses the pattern rather than any particular implementation, and it is deliberately specific about where the approach stops.
Table of Contents
- What Is a Security Sidecar?
- Why "Beside" Matters More Than "Around"
- The Four Interception Points
- What a Sidecar Cannot Observe
- Sidecar Versus In-Process Versus Kernel
- Deployment Trade-offs
- How This Relates to Operation-Scoped Control
- Evaluating a Sidecar Implementation
- Frequently Asked Questions
What Is a Security Sidecar?
A security sidecar is a process that runs alongside a workload, mediating some class of its interactions with the outside world, without requiring changes to the workload itself. In the agent context, the workload is a coding agent such as Claude Code, Cursor or Codex, and the mediated interactions are its effects: processes started, files touched, network connections made.
Three properties define the pattern:
- Out of process. It does not run inside the agent, is not a plugin, and does not depend on the agent's cooperation to function.
- In the path. It sits on at least one channel the agent uses, which is what distinguishes it from a monitor that merely reads logs.
- Agent-agnostic. It works against a boundary rather than against a specific product's internals, which is why one deployment can cover a fleet running several different agents.
That last property is why the pattern suits this problem at all. Agent-native controls are excellent and they are per-product: Claude Code's six permission modes, Cursor's three Run Modes, Codex's sandbox-mode-by-approval-policy matrix. A fleet running all three has three policy languages, three failure behaviors and three sets of defaults. A boundary-level control has one.
Why "Beside" Matters More Than "Around"
The strongest argument for the sidecar in agent security is evidentiary, not architectural, and it is worth stating precisely because it is the part usually left implicit.
A record produced by the agent describes the agent's view of itself. If the agent is confused, manipulated, or simply wrong about what a command did, the record inherits the error. This is not a hypothetical concern about malicious agents; it is the ordinary case where a tool call's summary and its actual effect differ.
A record produced beside the agent does not inherit that error. Gensee's trace analysis of eight autonomous agent runs puts a name to the property: independent evidence, which alongside service semantics and persistence is what exposed two boundary crossings that activity volume alone could not explain. That is the sidecar's real product. Not enforcement, not coverage, but a record whose truth does not depend on the observed process.
Every agent vendor's native telemetry is, structurally, the other category. Claude Code's OpenTelemetry export, Codex's opt-in OTel, Cursor's compliance logging: all useful, all describing the agent's own account. When an auditor asks "how do you know," the distinction becomes the answer.
The Four Interception Points
A sidecar mediates specific channels, and which ones it covers determines what it can see. In practice there are four, with meaningfully different characteristics.
Process and syscall boundary. The richest signal and the highest volume. Observing process creation, file operations and network syscalls gives the parentage that makes every other observation attributable. Its cost is volume, and its requirement is a privileged position on the host.
Network boundary. Naturally suited to a sidecar, and the point where the pattern is most proven. A proxy sees destinations, volumes and timing. The limitation is well documented in the agent products themselves: Claude Code's built-in sandbox proxy "enforces the allowlist based on the requested hostname and, by default, does not terminate or inspect TLS traffic." A network sidecar without TLS termination knows where data went and not what it was.
Tool and MCP boundary. Mediating calls between the agent and its tools. Attractive because it is semantically rich, and limited because it only sees tools that route through it; a local subprocess bypasses it entirely.
Effect and promotion boundary. The point where a change becomes durable, whether that is a commit, a merge, a publish or a deploy. The lowest volume and the highest signal, and the one most directly aligned with what an auditor asks about.
Most real implementations combine two or more, and the combination is what determines coverage. A sidecar on the network boundary alone is a good egress control and a poor agent observer.
What a Sidecar Cannot Observe
Four limits are inherent to the pattern rather than to any implementation. A vendor that cannot state its own version of this list has not thought about it.
1. Anything that does not cross an intercepted boundary. This is the defining limit. An effect produced through a channel the sidecar does not mediate is not observed and not blocked, and it is absent from the record rather than marked as unknown. In-memory reasoning, a syscall path outside the intercepted set, a side effect through a co-resident process: all invisible.
2. Payload content where transport is opaque. Where TLS is not terminated, the sidecar has metadata. It should represent this as an unknown in the record, not as an implied benign, and most do not.
3. Intent. It observes that a credential file was read and that a connection followed. Whether that was a developer debugging or something worse is a question the record informs and does not answer.
4. A compromised host. A sidecar is a process on a machine. If the machine is owned, so is the sidecar. It raises the cost of an attack and does not survive one at the host level.
There is also a fifth limit that is specific rather than inherent, and worth flagging because it is the most common gap in practice: a sidecar that restarts loses in-flight state unless it persists it, and the persistence store is itself part of the attack surface it exists to observe.
Sidecar Versus In-Process Versus Kernel
The pattern sits between two alternatives, and the trade-offs are clean enough to state as a table.
| In-process (hook/plugin) | Sidecar | Kernel (sandbox/LSM) | |
|---|---|---|---|
| Evidence independence | None; runs inside the observed process | High | Highest |
| Semantic richness | Highest; sees the agent's own concepts | Medium; sees effects, infers intent | Lowest; sees syscalls |
| Agent-agnostic | No, per product | Yes | Yes |
| Survives agent compromise | No | Partly | Yes |
| Deployment cost | Low | Medium | High; platform-specific |
| Coverage | What the agent exposes | What crosses the boundary | Everything at that layer |
In-process hooks are what Claude Code's PreToolUse and ConfigChange hooks provide, and they are genuinely useful for policy enforcement at points the agent defines. They are not independent evidence, because they run inside the thing being observed.
Kernel-level enforcement is what the agent sandboxes already do: Seatbelt on macOS, bubblewrap or Landlock and seccomp on Linux. Nothing above the kernel replaces this, and a sidecar that positions itself as an alternative to a sandbox is making a claim it cannot support.
The honest positioning of the sidecar is between the two: independent enough to be evidence, semantic enough to be actionable, portable enough to cover a mixed fleet, and positioned to carry the cross-session lineage that Gensee's multi-session agent safety research shows native controls do not span. It complements both neighbours rather than displacing either.
Deployment Trade-offs
Three practical decisions shape whether a sidecar deployment succeeds.
Where it runs. On the developer machine it sees local effects, which is where coding agents do most of their work, and it inherits the machine's trust problems. In a container or hosted environment it is cleaner to operate and misses everything local. Codex's cloud model is the useful reference point for how much the environment itself can do: sessions run in isolated containers on a two-phase runtime where the agent phase is offline by default and secrets are removed before it begins. A sidecar in that setting has less to defend.
What it does on failure. The same question every enforcement layer faces, and the agent vendors have answered it differently: Claude Code's sandbox fails open unless sandbox.failIfUnavailable is set, while Cursor's Linux sandbox falls back to requiring approval when the kernel lacks Landlock v3. A sidecar's failure behavior should be an explicit, dated decision rather than a default, and it should differ by phase: fail open while observing, fail closed once blocking.
How policy reaches it. A sidecar with locally editable policy is a suggestion. The property to look for is the one Cursor documents for its own sandbox rules, where team-admin policies and hardcoded rules layer on top so local files cannot weaken them.
How This Relates to Operation-Scoped Control
The sidecar is a deployment shape, not a security model, and this distinction is where most of the confusion in the category lives. It answers "where does the control run." It does not answer "what is the unit of authority."
That second question is the one Gensee's architecture work addresses. Gensee's operation security layer organizes the problem into five planes: admission and policy, execution and isolation, authority and effects, observation and evidence, persistence and recovery. A sidecar is an implementation choice within the middle planes; it is not the model.
The model itself is the move from ambient privilege to operation-scoped authority, set out in Gensee Crate Enterprise, where a single request resolves to one of five execution paths: run in the existing environment, use a trusted mediator that performs the effect without transferring the secret, spin up a fresh capability cell that makes risky work disposable, take a live TClone fork that preserves state without laundering authority, or deny and require approval. The promotion boundary then governs what crosses back out.
Read that way, the sidecar's role is narrower and clearer than the marketing usually suggests: it is one way to observe and mediate at the authority-and-effects plane. The decisions about what authority an operation gets, and what is allowed to cross back, are made elsewhere.
Evaluating a Sidecar Implementation
Seven questions, ordered by how much they reveal:
- Which boundaries do you intercept, and what does each miss? Expect four possible answers and an honest gap list.
- Is TLS terminated? If not, you have metadata. Ask how the record represents that.
- Is an unobserved effect recorded as unknown or simply absent? Absence that looks like safety is the dangerous failure.
- What happens on sidecar failure, per phase?
- Can a developer weaken the policy locally?
- What is the overhead, by what methodology? Refuse a figure without a method.
- What is the relationship to the sandbox already in place? Complement is the right answer; replacement is not.
Frequently Asked Questions
What is a security sidecar for AI agents?
A process that runs alongside a coding agent, mediating some class of its interactions with the outside world without modifying the agent. Its defining property is that it produces evidence independent of the agent's own account of what it did.
Does a sidecar replace the agent's sandbox?
No. Agent sandboxes enforce at the kernel level using Seatbelt, bubblewrap or Landlock and seccomp, and nothing above the kernel replaces that boundary. A sidecar adds independent evidence and cross-session correlation, which the sandbox does not provide.
What can a sidecar not see?
Anything not crossing a boundary it intercepts, payload content where TLS is not terminated, the agent's intent, and anything on a host that has itself been compromised. The first is the important one, because unobserved effects are usually absent from the record rather than flagged as unknown.
Why not just use the agent's own hooks?
Hooks such as Claude Code's PreToolUse and ConfigChange are useful policy enforcement points, but they run inside the observed process, so they are not independent evidence. They are also per-product, which does not scale across a fleet running several different agents.
Is a sidecar the same as operation-scoped authority?
No. A sidecar is a deployment shape answering where the control runs. Operation-scoped authority is a security model answering what authority a given operation receives and what is allowed to cross the promotion boundary afterward. A sidecar can be one way to implement part of the latter.
Conclusion
The sidecar earns its place in agent security for one reason that holds up: a record produced beside the agent survives the agent being wrong. Everything else claimed for the pattern is contingent on which boundaries a given implementation intercepts, and that question deserves a direct answer before anything else.
Treat it as a deployment shape within a larger model rather than as the model itself. Gensee's operation security layer and operation-scoped authority work set out that larger model in detail. To discuss how it applies to your deployment, book a demo, or read the architecture posts on the Gensee blog.