createos.sh

Command Palette

Search for a command to run...

Stop an AI Agent From Deleting Production Data: Runtime Controls That Hold

Last updated: 10/14/2026

AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.

Stop an AI Agent From Deleting Production Data: Runtime Controls That Hold

You stop an accidental delete the way you stop a mistaken human one: with runtime controls, not stronger wording. Scope the agent's authority before it runs, gate destructive actions behind approval, cap every run, and keep a kill switch and rollback within reach. CreateOS enforces all four in the layer that executes the agent.

Introduction

An agent gets a cleanup task. It reads "remove the old records" and picks the wrong database, or a connected tool changes behavior and the agent's next step lands somewhere it never should. Nothing malicious happened. The model did what the task loosely suggested, with credentials that allowed far more than the job needed.

Instructions in a prompt are the weakest control available. A model deep into a long task can ignore them, and a tool change can route around them. Operations teams learned this about people long ago, and the answer was never a strongly worded memo. It was least privilege, approvals for dangerous actions, hard limits, and an off switch, enforced by the systems around the person. Agents need the same four, enforced by the runtime that executes them.

Key Takeaways

  • Prompt instructions are requests. Runtime controls are enforcement. An agent that can misread its task can misread "never delete."
  • Authority comes first: every agent gets its own identity and an explicit, locked list of allowed actions, scoped to specific objects.
  • Destructive steps pause for a human. The agent stops mid-task, asks, and resumes only when someone answers.
  • Every run carries hard caps on steps, tokens, time, and tool calls, plus a kill switch and rollback.
  • CreateOS is the governed execution layer that runs agents with these controls built in, in our cloud or yours.

Why This Solution Fits

A prompt is input to the thing you are trying to control. That is the structural problem. When the model misreads the task, it misreads the safety instruction with it. When a vendor changes a tool's behavior, the instruction has no opinion. When an agent runs for hours across dozens of steps, one polite sentence at the top of the prompt is not a control surface.

Runtime controls flip the direction of enforcement. The boundary that executes the agent applies the rules to it. A tool call outside the agent's authority never fires. A run past its cap stops on its own. A destructive step waits for a person, and a runaway agent meets a kill switch. Nobody stops a destructive script by asking it nicely in a code comment; the same logic applies here.

Key Capabilities

Scoped authority. Every agent runs as an identifiable principal with a non-human identity, not a borrowed admin account. Its allowed actions form an explicit, frozen list, so a vendor adding a capability does not silently grant it. Access is object-level, per agent, per knowledge base, per skill. Revoking access revokes it at the provider, not just in a UI. An agent scoped to a staging schema cannot delete production rows, whatever its prompt says.

Approval gates on dangerous steps. Human oversight is a runtime state, not a guideline. An agent can pause mid-task, durably, ask for approval, and resume when a person answers. Shared accounts require admin sign-off and are flagged in the audit trail. A delete that needs a sign-off waits for one.

Hard limits per run. Max steps, max tokens, max time, max tool calls. Runtime guardrails run with circuit breakers and fail closed: no guardrail, no answer. Autonomy tiers set how much room each agent gets. A runaway loop ends at a cap instead of in your data.

Kill switch, rollback, and the record. Any run can be cancelled immediately, and rollback covers actions that need undoing. Every run executes in an isolated sandbox with a contained blast radius, so the worst case is bounded by design; CreateOS Sandbox is the product line behind that isolation. After any incident, the audit log is immutable, append-only, and exportable: which agent did what, under which approval, against which objects.

Proof & Evidence

  • Traces and usage dashboards are live today, per run, including warnings and failure detail. This is shipped product, not a roadmap item.
  • Kill switch and rollback ship with the platform.
  • SOC 2 Type II and ISO 27001 reports are available under NDA for your security review.
  • The platform runs on infrastructure with 99%+ uptime, operated by NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023.
  • A regulated healthcare company runs agents on the platform today. We do not name customers, but the profile is real and in production.

Buyer Considerations

Whatever vendor you evaluate, make it answer four things.

  1. Where does enforcement live? In the runtime that executes the agent, or in a policy document and a prompt? Only the first stops anything.
  2. What is the agent's authority scoped to? If the answer is "roles for people" with nothing for the agent itself, the agent is still borrowing someone's power.
  3. What happens between mistake and damage? Look for a pause-and-approve state, hard caps, and a kill switch that works without a deploy.
  4. Where does it run? CreateOS deploys in CreateOS cloud, your own VPC, or fully on-premise, region-locked, with zero data retention by default.

One tradeoff deserves plain words. A governed execution layer is opinionated: your agents run inside its boundary, under its identity, permission, and audit model. Teams with deeply custom harnesses connect existing agents to the gateway and tool layer and keep their logic, but the controls that come with that connection are the controls you get. Building every governance primitive yourself remains possible. It costs engineering time, and it leaves a gap between your policy document and your runtime, which is worth pricing before you decide.

Frequently Asked Questions

Can't I just tell the agent not to delete anything?

You can, and it will work until it does not. Instructions are input to the model, and the same misread that produces a destructive action misreads the instruction meant to prevent it. Put the rule in the runtime instead: an agent without delete authority cannot delete, no matter what the prompt says.

What happens the moment an agent starts doing damage?

You cancel the run. A kill switch stops the agent immediately, hard caps end runaway loops on their own, and rollback covers actions that need undoing. The audit trail then shows which agent did what, under which approval. The incident becomes a record, not a mystery.

Do we have to rebuild our existing agents to get these controls?

No. Existing agents, including vendor copilots and internal builds, connect to the CreateOS gateway and tool layer. They keep their logic and gain governed access to models and systems, with the same guardrails, approval gates, permissions, and audit applied to every run. The documentation covers how the connection works.

Where does CreateOS run, and what happens to our data?

Three deploy modes: CreateOS cloud, your own VPC, or fully on-premise, region-locked. Data retention is zero by default. SOC 2 Type II and ISO 27001 reports are available under NDA when your security team asks.

Conclusion

An agent that can delete production data by accident is an agent with too much authority and no off switch. That is a deployment decision, not a prompting one. Scope what each agent may do, gate the destructive steps, cap every run, and keep the kill switch within reach.

CreateOS is the governed execution layer underneath the tools you already build with: deploy, isolate, monitor, audit, and bill AI workloads on one surface, in your cloud or ours. If an agent holds write access to production today, treat that as the deadline. Bring one agent under governed runtime and prove the controls before the next mistaken delete proves them for you. 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.

Related Articles