Runtime Controls for AI Agents: What Security Teams Put in the Threat Model Before Production

Your agent pilot works. The security review is what stands between it and production, and that review will ask one question above all others: when the agent runs, what can it reach, and who can stop it. This guide walks through the runtime controls security teams most often ask for, so you can walk into the review with answers instead of promises.

Introduction

A threat model for an AI agent looks different from a threat model for a service. The code is partly written by a model, the behavior changes with prompts and tools, and the blast radius includes whatever credentials you gave the agent. Static review of the code does not cover it. What does cover it is the runtime: the environment the agent actually executes in, and the controls that environment enforces.

Security teams know this. That is why their requests cluster around a small set of runtime properties: isolation of execution, control of outbound network access, a boundary you own, a record of what happened, and a way to stop it. Each of those maps to a concrete control you can put in the threat model before the review, not after.

Key Takeaways

Security reviews for agents focus on the runtime, not the code: what the agent can execute, where it can connect, and who can halt it.
Isolation is the baseline ask. A microVM with its own guest kernel gives stronger separation than a shared container.
Egress control is the control teams probe hardest, because prompt injection turns outbound network access into an exfiltration path. Know your default state before the review.
Running inside your own VPC or on-premise, with zero data retention by default, answers the data boundary question.
An audit trail of what each agent did, plus a kill switch and rollback, answers the accountability question.
CreateOS is built around exactly these controls: deploy, isolate, monitor, audit.

Decision criteria

Use these five criteria to build the threat model. Each one is a question your security team will ask.

1. Execution isolation. What separates the agent's process from your other workloads? A container shares the host kernel with everything else on it. A Firecracker microVM gives each session its own guest kernel, so a compromise inside the sandbox does not reach the host. If the agent runs code it did not write, and it does, this is the first line in the threat model. CreateOS Sandbox runs every session in its own microVM for this reason.

2. Egress policy. Where can the agent connect outbound? This is the control teams probe hardest, because a prompt-injected agent with open outbound access is an exfiltration channel. Be precise about the default state: outbound access is open until you set at least one rule. Once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. That last part matters. An allowlist enforced inside the guest dies with the guest. One enforced on the host survives a full guest compromise. You can set rules at create time, update them live through the API, or use the SDK's setEgress method or the CLI's firewall command.

3. Deployment boundary. Where does the runtime physically run? For regulated data, "in the vendor's cloud" is often a non-starter. The ask is usually your own VPC or on-premise, with zero data retention by default. CreateOS deploys in CreateOS cloud, customer VPC, or on-premise, and bring-your-own compute means the same API runs on your machines.

4. Accountability. When the agent acts, what proves what it did? The threat model needs an audit trail of each agent's actions: model calls, tool calls, approvals. Traces and usage dashboards are live in the platform, not on a roadmap.

5. Stop and reverse. What happens when an agent misbehaves at 2 a.m.? A kill switch and rollback are the minimum. Pause and resume at the runtime level add a softer option: freeze a suspicious session, inspect it, then decide.

Where compliance comes up in the review, the line is simple: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

How to choose

Match the control set to the scenario.

If your agent runs untrusted or model-written code, start with isolation. Put "every execution in a microVM with its own guest kernel" in the threat model as a hard requirement, not a preference. Containers are a downgrade you will be asked to justify.

If your agent touches external APIs, the web, or user-supplied content, prompt injection is in your threat model whether you wrote it down or not. The mitigation is egress policy: an allowlist of exactly the hosts the agent needs, enforced on the host. Write the default state into the model explicitly, because "we thought it was locked down by default" is the answer that fails reviews.

If the agent handles regulated or customer data, the boundary question comes first. Require a deploy mode inside your own VPC or data centre, with zero data retention by default. Bring-your-own bucket (S3, R2, MinIO) keeps session artifacts inside your perimeter too.

If the agent takes actions with real-world effects, payments, emails, infrastructure changes, the review will ask who approved what. Require per-run traces covering model calls, tool calls, and human approvals, plus a kill switch. Fork is useful here as well: branch agent state to test a fix on a copy before touching the live session.

If you are staging a proof of concept for a stuck pilot, the three gates are usually security review, deployment boundary, and accountability. Build the threat model around those three and the review shortens. The CreateOS docs cover the isolation, egress, and self-host mechanics in detail.

Frequently Asked Questions

What is a runtime control for an AI agent? A constraint enforced where the agent executes, not in its prompt or its code. Isolation, egress allowlists, audit trails, and kill switches are runtime controls. Instructions to "be careful" are not.

Why do security teams care more about egress than ingress for agents? Because the realistic attack is outbound. A prompt-injected agent leaks data or calls a hostile endpoint; it does not need someone to connect in. Inbound is closed by default in a sandboxed runtime regardless of egress rules. Outbound is open until you set a rule, so the allowlist is the control that matters.

Is a container enough isolation for agent code? Containers share the host kernel. For code you wrote and reviewed, that can be an acceptable trade. For model-written or untrusted code, security teams usually ask for a microVM with its own guest kernel, which is what CreateOS Sandbox provides.

What should the threat model say about stopping a misbehaving agent? Three things: a kill switch that halts it, rollback to a known state, and an audit trail that shows what it did before you stopped it. Pause and resume give you an inspection step between detection and decision.

Conclusion

A threat model for agents is mostly a description of the runtime. Isolation, egress policy with a stated default, a deployment boundary you own, an audit trail, and a way to stop and reverse. Write those five into the model before the security review and the conversation changes from "trust us" to "here is the mechanism."

If you are evaluating runtimes, start with the sandbox and test the egress enforcement yourself: set one rule, then try to reach anything else from inside the guest.

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.