Enterprise AI just crossed a threshold. Phase one was chatbots: they answered questions, generated text, and at worst, hallucinated. The risk surface was narrow — a bad answer, a confused user, a corrected response. Phase two is different in kind, not just in degree. The agents that enterprises are deploying now don't answer — they act. They write to databases. They call external APIs. They send emails, browse the web, and execute multi-step workflows. When something goes wrong, the consequences aren't a bad answer. They're a bad action that has already propagated through your systems.
That shift demands a different response. Not a better chatbot policy. A fundamentally different containment architecture.
That architecture is the Kosmoy Action Capsule.
What Is a Kosmoy Action Capsule?
A Kosmoy Action Capsule is a Kubernetes-native sandbox that gives each autonomous AI agent its own isolated runtime environment, enforced at the Linux kernel level and at network egress. Every outbound call from an agent inside an Action Capsule passes through the Kosmoy AI Gateway — the only authorized exit point. The agent cannot reach systems, APIs, or data outside its defined permissions, regardless of what instructions it receives.
Unlike application-level guardrails, which rely on the agent cooperating with its own constraints, an Action Capsule creates a runtime perimeter the agent cannot exit — even if it tries.
Action Capsules are part of the Kosmoy platform, alongside the Kosmoy AI Gateway (centralized LLM traffic control), Kosmoy Studio (governed AI assistant deployment), and Mission Control (fleet supervision and audit).
Why AI Agents Create a New Enterprise Risk Category
The Phase Shift: From Chatbots to Agents
Chatbots were bounded tools. They processed text and returned text. Even in the worst case — a confident hallucination delivered to a user — the blast radius was limited to whoever read the output. No system was modified. No API was called. No data moved.
Autonomous AI agents operate with no such boundary. A modern computer-use agent can:
- Write and modify files on connected systems
- Send emails and schedule meetings on behalf of users
- Query and update databases and systems of record
- Browse the web and interact with external services
- Execute multi-step workflows without human confirmation at each step
The risk surface isn't a bad answer anymore. It's an unauthorized action that has already happened — and may already have cascaded across connected systems before anyone notices.
The OpenClaw Problem: A Concrete Example
OpenClaw is an open-source autonomous agent that illustrates this concretely. It ships with full system access, browser automation, email read/write capability, and file system control. Its attack surface is fully documented and well-understood. A single prompt injection — a malicious instruction embedded in a document the agent processes, a webpage it visits, or an email it reads — can redirect OpenClaw's full capability toward unintended or hostile actions.
This is not a theoretical vulnerability. It is a documented, exploitable characteristic of any agent that combines broad capability with unrestricted system access. OpenClaw is not an outlier: it represents the capability profile of agents that enterprise teams are building and deploying today, often without centralized IT visibility.
Why the Two Standard Responses Both Fail
Enterprise security teams typically respond to high-risk agents in one of two ways. Both are inadequate.
Option 1: Ban it. The productivity gain disappears. In practice, the agent gets deployed anyway — through personal devices, shadow IT channels, or departmental workarounds — now entirely outside any oversight. Banning is a losing strategy when AI productivity is a competitive advantage and the tools are freely available.
Option 2: Approve it with a policy. A policy document defines what the agent is permitted to do. But a policy is a request, not a wall. Nothing at the infrastructure level prevents the agent from reaching whatever it wants. Compliance depends entirely on the agent cooperating with its own constraints — and on that cooperation persisting through every prompt it receives, including adversarial ones.
Neither option addresses the actual problem: the absence of a technical mechanism that prevents the agent from taking actions outside its intended scope.
How Kosmoy Action Capsules Work
Action Capsules address AI agent risk at the infrastructure level — not at the application layer, and not through documentation.
Kubernetes-Native Sandboxing
Each agent runs inside its own isolated Kubernetes pod with resource constraints enforced by the Linux kernel. The agent cannot escape its container, cannot access host system resources, and cannot communicate with other containers or internal networks outside its explicitly defined permissions. Isolation is not a software setting the agent could theoretically disable — it is enforced by the operating environment itself, below the application layer.
The Kosmoy AI Gateway: The Only Door In or Out
Every outbound call the agent makes — every API request, every LLM interaction, every external connection — is routed through the Kosmoy AI Gateway. The Gateway is the only authorized egress point from the Capsule. Attempts to make connections outside this path are blocked at the network level before they execute. The Gateway simultaneously enforces routing and access policies, screens for PII leakage, checks EU AI Act compliance rules, and logs every interaction for audit — in real time, for every call.
Live Kill Switch
Mission Control provides operators with a live kill switch that can halt any agent mid-action. If anomalous behavior is detected — unexpected API calls, attempts to reach unauthorized systems, outputs that trigger policy violations — the agent can be stopped immediately, without waiting for a workflow to complete. No manual process. No coordination overhead.
Mission Control: Fleet Supervision and Complete Audit Trail
Every action taken by every agent inside an Action Capsule is logged, auditable, and visible in Kosmoy Mission Control. Organizations have a complete record of what each agent did, when, and what it reached — the operational data required for compliance reporting, incident response, and ongoing governance.
Action Capsule vs. Traditional AI Guardrails
The distinction between an Action Capsule and a guardrail is not a matter of degree — it's a matter of where enforcement happens.
| Traditional AI Guardrails | Kosmoy Action Capsule | |
|---|---|---|
| Enforcement layer | Application level | Linux kernel + network egress |
| Agent cooperation required | Yes | No |
| Network isolation | None | Complete (gateway-only egress) |
| Prompt injection protection | Partial | Yes |
| Live kill switch | No | Yes |
| Full audit trail | Partial | Complete |
| Deployment scope | Per-application | Infrastructure-wide |
The practical implication: guardrails work when the agent is cooperative. An Action Capsule works regardless of whether the agent is cooperative, compromised, or actively attempting to escape its constraints.
The OpenClaw Stress Test
Kosmoy tested Action Capsules against OpenClaw specifically because it is the most demanding containment scenario available: maximum capability, maximum attack surface, and a fully documented exploit path that security researchers have confirmed is reliably exploitable.
Inside an Action Capsule, OpenClaw retains its full productivity capability. It can still perform the tasks it was deployed to perform. What it cannot do is act outside the Capsule: it cannot reach unauthorized systems, cannot exfiltrate data through unauthorized channels, and cannot be redirected by a prompt injection attack to access resources outside its defined permissions. The attack surface exists — but it terminates at the Capsule boundary.
If Action Capsules can contain OpenClaw, they can contain the agents your internal teams build, which are in most cases significantly more constrained to begin with. The same containment layer applies to any computer-use agent, any MCP server, and any autonomous workflow your organization deploys — today or next quarter.
What Action Capsules Enable for Enterprise AI Adoption
The conventional wisdom in enterprise AI security is a false binary: either you control AI by restricting capability (accept lower productivity) or you accept the risk that unrestricted capability carries. Action Capsules eliminate that trade-off.
The agent keeps its full capability. The blast radius is bounded by the Capsule. Productivity is preserved. Risk is contained at the infrastructure level.
This matters at scale. As enterprises move from deploying single AI assistants to running fleets of specialized agents — some built internally, some open-source, some from third-party vendors — the ability to contain each agent without individually auditing its codebase, its prompt engineering, or its third-party dependencies becomes a strategic necessity. Action Capsules make that operationally viable.
Chatbots needed governance. Agents need containment.
Frequently Asked Questions
What is a Kosmoy Action Capsule? A Kosmoy Action Capsule is a Kubernetes-native sandbox that isolates each autonomous AI agent in its own runtime environment, with containment enforced at the Linux kernel level and at network egress. Every outbound call from the agent routes through the Kosmoy AI Gateway — the only authorized exit point. The agent cannot reach systems, APIs, or data outside its defined permissions, regardless of what instructions it receives.
How is an Action Capsule different from an AI guardrail? AI guardrails are application-level controls that rely on the agent cooperating with its own constraints. An Action Capsule enforces containment at the infrastructure level — Linux kernel isolation and network-level egress control — independent of agent behavior. Guardrails work when the agent is cooperative and uncompromised. Action Capsules work regardless.
What is prompt injection, and how do Action Capsules protect against it? Prompt injection is an attack in which malicious instructions are embedded in content an agent processes — a document, a webpage, or an email — redirecting the agent toward unintended actions. Action Capsules protect against prompt injection by limiting what the agent can reach: even if an injected instruction directs the agent to exfiltrate data or access unauthorized systems, the network isolation blocks the action before it executes.
Does Action Capsule work with any AI agent or framework? Yes. Action Capsules are infrastructure-level containment and are not specific to any agent framework, model, or vendor. They work with any computer-use agent, any MCP server, and any autonomous workflow — including open-source agents like OpenClaw, internally built agents, and third-party AI tools your teams deploy.
What happens if an agent inside an Action Capsule behaves unexpectedly? Mission Control provides a live kill switch that can halt any agent mid-action the moment anomalous behavior is detected. Every action is fully logged. Operators can stop any agent immediately and review the complete audit trail of everything it did, every system it reached, and every call it made.
Can an agent inside an Action Capsule still access external APIs and services it needs? Yes — within its authorized scope. All outbound calls route through the Kosmoy AI Gateway, which enforces policy rules about which external services the agent is permitted to reach. Authorized calls proceed normally. Unauthorized calls are blocked and logged. The agent's productivity is preserved; its blast radius is bounded.
Does Action Capsule support EU AI Act compliance requirements? Yes. The Kosmoy AI Gateway — the mandatory egress layer for all Action Capsule traffic — simultaneously enforces EU AI Act compliance rules, screens for PII leakage, and maintains the complete, auditable interaction logs that regulators require. Containment and compliance enforcement happen in the same infrastructure layer.
The same agent. The same productivity. The blast radius is now the size of the Capsule.
Don't ban the wild ones. Capsule them.