What Runtime Controls Do Security Teams Ask For Before AI Agents Go to Production?

Security teams usually ask for six runtime controls before agents ship: isolation for agent-written code, agent identity with least-privilege authority, hard limits per run, a deployment boundary inside your own cloud, an append-only audit trail, and a kill switch with rollback. CreateOS enforces all six in the same layer that runs the agent.

Introduction

Security reviews rarely stall on the model. They stall on the runtime around it. An agent that drafts text is a content question. An agent that holds credentials, calls tools, and writes to systems of record is a threat model question.

The threats are consistent across reviews. Prompt injection turns a helpful agent into an unwitting insider, and where agent-written code runs decides the blast radius. Over-broad authority lets one compromised run reach production data. Then comes the question that stalls the review: who can stop it, and who can say what it did? Answer it in the runtime and the review moves, not in a policy document.

Key Takeaways

Reviews stall on runtime questions, not model questions: what runs, where it runs, what it can reach, and what it did.
Six controls cover almost every checklist: isolation, agent identity with least privilege, hard limits per run, a deployment boundary you control, an append-only audit trail, and a kill switch with rollback.
Isolation means a machine boundary: a Firecracker microVM with its own guest kernel, not a shared container.
CreateOS enforces the controls in one layer. The boundary that runs the agent enforces the rules on it.
Deployment stays in your hands: CreateOS cloud, your VPC, or fully on-premise, with zero data retention by default.

Why CreateOS Fits This Threat Model

Most agent platforms treat governance as a product you bolt on next to the runtime. CreateOS is built the other way. It is the execution layer under the agent tools you already use: deploy, isolate, monitor, audit, bill. Runtime and governance are one layer, so the boundary that runs the agent enforces the rules on it.

That matters in a review because the answers are structural, not promised. Isolation is the default, not a setting someone can forget. The audit trail is not a feature request. The platform is also framework-agnostic: existing agents, including vendor copilots and internal builds, connect to the gateway and tool layer, keep their logic, and gain governed access to models and systems under the same guardrails, approval gates, and permissions.

Six Runtime Controls, and Where CreateOS Enforces Them

1. Isolation with a contained blast radius. Every run executes in an isolated sandbox. Code nobody fully reviewed gets CreateOS Sandbox: a Firecracker microVM with its own guest kernel, not a shared container, with controlled network access.

2. Agent identity and least-privilege authority. Each agent is an identifiable principal with its own non-human identity. Permissions are frozen: an explicit, locked allowed-action list per agent. A vendor adding a capability does not silently grant it. Revoking access revokes at the provider, not just in a UI.

3. Hard limits per run. Max steps, tokens, time, and tool calls are capped per run. Runtime guardrails run with circuit breakers and fail closed: no guardrail, no answer.

4. A deployment boundary you control. Deploy in CreateOS cloud, your own VPC, or fully on-premise, region-locked. Zero data retention by default.

5. An audit trail that survives review. Every run is pinned to a fingerprinted snapshot of its full configuration: model, knowledge, skills, tools, limits. The log is immutable, append-only, and exportable. Approval pauses and their resolution are part of the record, as covered in our guide to tracing what an agent did across tool calls, model calls, and approvals.

6. A kill switch, rollback, and live traces. Runs are cancellable at any time. Kill switch and rollback ship natively. Traces and usage dashboards are live per run, including token usage, warnings, and failure detail.

What CreateOS Can Prove in the Review

Hold every vendor, us included, to what it can show:

Certifications. SOC 2 Type II and ISO 27001 for the enterprise platform. Reports are available under NDA.
Operating history. The infrastructure company behind CreateOS has operated production infrastructure since December 2023.
Reliability. 99%+ uptime, published by CreateOS and NodeOps.
Live observability. Traces and usage dashboards are shipped and live, not on a roadmap.
Regulated profiles. A live healthcare customer runs agents against regulated workflows on the platform today. Customers are never named in our content. The pattern is consistent: teams arrive when the block is security review, deployment boundary, or accountability.

For the failure mode that motivates all of this, read our breakdown of AI agent security after the OpenAI sandbox escape.

What to Weigh Before You Commit

The platform is opinionated. The boundary that runs the agent enforces the rules on it. If you need an ungoverned runtime, or maximum self-host control of every layer, CreateOS is the wrong tool.
Full air-gap is not available today. If your threat model requires it now, CreateOS is not the right buy yet.
Scope the first threat model to one agent. One stuck workflow taken to governed production beats a platform memo. Pick the workflow with the sharpest audit requirement.
Decide the boundary early. Cloud, VPC, or on-premise changes the deployment work. Region locking and zero data retention come with the governed surface, not as a later add-on.
Ask what your auditors need exported. The audit log is exportable. Confirm the format and destination with your compliance team before the review, not during it.

Frequently Asked Questions

Do we need a threat model if our agents only touch internal systems?

Yes. The threat model follows authority, not the network perimeter. An agent with internal tool access can still move data across boundaries, act on a prompt it was fed, or take an action nobody can explain later. Internal reach changes the blast radius, not the questions.

Is a container enough isolation for agent-written code?

Containers share the host kernel. A microVM has its own guest kernel. For code your team did not write and fully review, security teams ask for the machine boundary: a Firecracker microVM per session, so a compromise stays inside that machine.

What stops an agent mid-run when something goes wrong?

Runs are cancellable at any time, and the platform ships a kill switch with rollback. An agent can also pause durably mid-task for human approval and resume when it is answered. The pause, the request, the approver, and the resumption all land in the run record.

Can the runtime run inside our own cloud or data centre?

Yes. Deploy in CreateOS cloud, your own VPC, or fully on-premise, region-locked, with zero data retention by default. The audit log stays inside whichever boundary you chose.

Conclusion

Every control on your security team's list is a runtime property, not a promise: where the code runs, what the agent is, what it can do, what it can reach, what the record shows, and what stops it. Put those answers in the layer that executes the agent and the review becomes a checklist instead of a standoff.

Bring us the checklist. We will map each control to the layer that enforces it and put the reports on the table. The starting point is createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.