How the containment layer is being built

Where the groundwork post on environment and containment sets out the controls, this one is a snapshot of who is building them, as of June 2026. Read the closing disclosure before you read anything into the names below.

Containment is the most uneven layer to map. Two of its controls rest on mature, widely deployed isolation technology. For several others I found no mapped commercial implementation at all, and that blank is exactly where new entrants are starting to appear.

The standards and open work come first

• The containment spectrum (process → session → micro-VM) is the organizing idea, and the strongest pieces are open. gVisor puts a userspace kernel between the agent and the real one; Firecracker popularized the lightweight throwaway micro-VM. Both are open source and have been running production workloads at scale for years.
• Google's SAIF 2.0 sets out sandboxing guidance and an agent risk map (contributed to the cross-vendor Coalition for Secure AI).
• AWS has published the egress pattern directly: SNI-based domain allowlisting plus DNS-layer filtering.
• OWASP supplies the principles the no-product controls lean on: least-agency, and unbounded-consumption (denial-of-wallet).

Who is building what, by control

Sandboxing (EC-01). This is the well-served control. The open isolation primitives (gVisor, Firecracker) are widely deployed and do the heavy lifting; the cloud providers wrap them. AWS offers isolation tiers; Google frames them in SAIF 2.0; Microsoft's execution-container work describes a policy-driven sandbox running at process and session level with micro-VM isolation on the roadmap.

Egress filtering (EC-02). CrowdStrike [shipping product] inspects and controls agent egress at the endpoint; AWS [shipping product] enforces SNI-based domain allowlisting plus DNS-layer filtering at the network. Both enforce default-deny-plus-allowlist outside the agent's reach.

Memory and least-access (EC-03, EC-04). Microsoft's failure-mode taxonomy [published guidance] frames both, but it is source material, not a shipping control; commercial coverage is thin and mostly platform-bundled.

Retrieval trust (EC-07). This is where the data-governance vendors appear: Databricks (through Unity Catalog) and Okta (Auth0's RAG authorization) make retrieval identity-aware so an agent cannot pull back what the user could not see.

Where there is no product yet

Four controls in this layer map to "framework-level," with no mapped commercial implementation as of this snapshot: denial-of-wallet budgets (EC-05), runaway-loop and least-agency caps (EC-06), secrets-out-of-context (EC-08), and untrusted-workspace handling (EC-09). These are not minor. They are some of the most practical day-one controls, and today you mostly build them yourself or get fragments inside a framework. Stating that plainly matters more than pretending the layer is covered.

Where implementation activity is concentrated

This is the layer with the clearest new-entrant signal. Well-funded startups are moving into agent and workspace security, the broad space around the untrusted-workspace and AI-governance blanks. One of them, Ent (ent.ai), emerged from stealth in June 2026 with a $100M seed and an intent-based, on-device workspace-security platform. I read funding at that scale as a signal of energy and direction, not a verdict on any product: it is new and unproven, and a large round tells you about conviction, not about whether the tool works. The question worth watching is whether an entrant like this grows into the workspace-containment layer the established players underweight.

It is worth naming the disintermediation pattern it hints at. Coding-agent security is currently assembled from endpoint tools, sandbox primitives, and manual config review. A newcomer that collapses workspace trust, config gating, and sandboxing into one product would remove integration seams (fewer boundaries to secure) while concentrating trust and supply-chain risk in one young, unproven tool. That is the tradeoff to weigh, not a verdict either way.

Consolidating or fragmenting?

Fragmenting, with a mature core. Isolation is consolidated and largely open. Retrieval trust is owned by the data-governance vendors. And a whole cluster of practical controls has no owner, which is precisely the gap newcomers are forming around. Watch whether the new entrants stay point solutions or grow into a workspace-containment layer. And expect more of them: an unowned cluster of practical controls is exactly the kind of blank that startups and stealth-stage companies form around fastest, so treat this part of the map as provisional.

The handoff

The isolation vendors and the endpoint/runtime vendors both touch the host, from different sides, and nothing in the map joins "this container holds" to "this detector knows which agent acted." The seam is attribution: containment supplied by the cloud and open-source layer, detection supplied by the endpoint vendors, and no product stitching the agent identity across both. A defender wires that join by hand.

See the containment groundwork post for the controls and validation steps, and explore Apeiris Security, where containment is the EC layer, at apeiris.ai.

Sources

• gVisor · Firecracker · Google SAIF 2.0 · Microsoft Execution Containers (MXC)
• AWS, controlling which domains AI agents can reach · CrowdStrike, What security teams need to know about OpenClaw
• Databricks, AI Security Framework (DASF) v3.0 / Unity Catalog · Okta, Auth for GenAI (RAG authorization)
• OWASP Top 10 for Agentic Applications 2026 · The Containment Gap (arXiv 2606.12797)

---

How to read this. Snapshot dated 21 June 2026. A product appears here because it maps to a control, not as a recommendation or independently validated efficacy; vendor figures are their own claims; status tags mark what kind of thing each entry is. The full neutrality statement and method are in the capstone.