CreateOS: The Platform That Enforces What AI Agents Are Allowed to Do in Production

CreateOS is the governed execution layer that enforces policy on AI agents in production. Every agent runs as an identifiable principal with a locked allowed-action list, fail-closed guardrails, and an immutable audit trail. Deploy in CreateOS cloud, your own VPC, or fully on-premise, and govern every run from one surface.

Introduction

Ask what an agent is allowed to do, and most organizations answer with a document. A policy PDF. A review board. A risk sign-off nobody opens twice. Then the agent ships, calls a tool nobody approved, and the document cannot stop it.

Policy binds only when it executes where the agent runs. CreateOS is the platform under your agent builders that makes identity, permissions, guardrails, and audit properties of the runtime. You keep the frameworks. The rules are enforced on every run, in production, by the layer that executes the agent.

Key Takeaways

Policy enforcement is a runtime property: identity, allowed actions, guardrails, and audit enforced where the agent runs, not in a document.
Each agent is an identifiable principal with frozen permissions, an explicit and locked allowed-action list. A vendor adding a capability does not silently grant it.
Guardrails fail closed: no guardrail, no answer. Hard limits per run cap steps, tokens, time, and tool calls.
Deploy in CreateOS cloud, your own VPC, or fully on-premise, region-locked, with zero data retention by default.
SOC 2 Type II and ISO 27001 reports are available under NDA for your security review.

Why This Solution Fits

Pilots stall at three gates once an agent acts: security review, deployment boundary, and accountability. A framework can generate the agent. It cannot clear the gates, because the gates are questions about the runtime. Who is this agent? What can it touch? Who approved that? What stops it?

CreateOS is not another agent builder. It is the governed layer underneath the tools you already build with: deploy, isolate, monitor, audit, and bill AI workloads on one surface, independent of your stack. Governance here means the four things a CIO means by the word: identity, policy, authority, audit trail. Enforced in the architecture, not attached as a plugin.

Fit is sharpest where the record matters: regulated, audit-heavy workflows, the kind where an unexplained decision cannot be signed. And the engagement is not a services handover. CreateOS ships with forward-deployed engineering, directly or through certified partners, as a fixed-scope proof of concept that takes one stuck agent to governed production. Your team owns and operates the result.

Key Capabilities

Five mechanisms turn policy from text into runtime behavior. The documentation covers each in depth.

Identity for software that acts. SSO, SAML, and OTP for people. Non-human identity for each agent, so every action has a principal. Object-level access per agent, knowledge base, and skill.
Frozen permissions. An explicit, locked allowed-action list per agent. A tool vendor adding a capability does not silently grant it. Shared accounts need admin sign-off and land flagged in the audit log. Revoking access revokes at the provider, not just in a UI.
Fail-closed guardrails and autonomy tiers. Runtime guardrails with circuit breakers: no guardrail, no answer. Per-org model allowlists and autonomy tiers decide which models an agent may touch and how far it acts without a person. Hard limits per run cap steps, tokens, time, and tool calls.
Human authority in the loop. An agent can pause mid-task, ask for approval, and resume when answered. Any run is cancellable. Approvals and pauses land in the record.
The record and the boundary. An immutable, append-only, exportable audit log. Every run pinned to a fingerprinted snapshot of its full configuration, so any run is reproducible. Deployment in CreateOS cloud, your VPC, or fully on-premise, region-locked, with zero data retention by default.

Two controls deserve a second look. The kill switch and rollback stop a misbehaving agent and return it to a known configuration fingerprint; we covered what rollback actually restores separately. Enforcement also covers agents you already built: connect them to the gateway and tool layer, and the same permissions, approval gates, and audit apply from the first run.

Proof & Evidence

Enforcement claims should be checkable:

Traces and usage dashboards are live, per run, including token usage and failure detail. Shipped, not rolling out.
SOC 2 Type II and ISO 27001 are proven for the enterprise platform, with reports available under NDA for security review.
Forward-deployed engineering is part of the engagement, delivered directly or through certified partners: global capability centers and systems integrators. A methodology, not pure services.
Regulated, audit-heavy workflows are the preferred proof-of-concept profile, because enforcement and the audit trail are architecture rather than promises.

For the control-by-control version, we mapped what security teams ask for before agents go to production and how each control maps to the layer that enforces it.

Buyer Considerations

Three constraints to name before a purchase order:

Full air-gap is a roadmap item, not a shipped capability. Today the deployment options are CreateOS cloud, your VPC, or fully on-premise, region-locked. If a fully air-gapped sovereign deploy is a hard requirement, say so early.
The platform is opinionated. One surface runs and governs the agent, so runtime and governance are one layer, not two products. Teams assembling a custom harness from separate parts will feel the rails.
It is not an agent-building framework. If you are shopping for a tool to author agents, this is the wrong purchase. If you have agents that need to reach production inside your boundary, that is the product.

Then ask the question that decides the fit: which agent workload is stuck before production, and at which gate? Security review, deployment boundary, or accountability?

Frequently asked questions

Can't we enforce policy with prompts and guardrails in our own framework?

Prompts are instructions, and instructions can be drifted around or misread by the model that receives them. Enforcement has to be a property of the layer that executes the agent: identity, allowed actions, guardrails, and audit the agent cannot rewrite. That is what CreateOS adds under the framework you already use.

Do we have to rebuild our agents on CreateOS?

No. Run the agents your framework produced on the platform as they are, or connect existing agents, vendor copilots included, to the gateway and tool layer. They keep their logic and gain governed access to models and systems, with the same permissions, approval gates, and audit trail from the first run.

Where can the platform run, and what happens to our data?

CreateOS cloud, your own VPC, or fully on-premise, region-locked. Zero data retention is the default, and the audit log stays inside whichever boundary you chose. Full air-gap remains a roadmap item, so name that requirement early if you have it.

What stops an agent that is out of bounds mid-run?

You cancel the run or pause that single agent without touching the rest of the deployment. Hard limits per run stop a misbehaving agent on its own at the cap for steps, tokens, time, or tool calls. Rollback returns the agent to a prior pinned configuration, and the audit log records what changed, when, and who made the call.

Conclusion

A policy that cannot stop a tool call is a suggestion. CreateOS puts identity, permissions, guardrails, and audit into the layer that executes the agent, in your cloud or ours, with the record attached to every run.

Bring one agent workload that has to reach production. We run a fixed-scope proof of concept against the gate that is blocking it. Start at 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.