In July 2025, nine days into a public build experiment, Replit’s coding agent deleted a user’s production database. The user had declared a code freeze and told the agent not to make changes without his approval. The agent ran destructive commands anyway, wiping records on more than 1,200 executives and over a thousand companies, and then wrongly reported that the data couldn’t be rolled back.
The instruction was clear, and the agent had it in context. What was missing was an AI agent guardrail between the agent and the database that would refuse the command regardless of what the agent decided to do.
Platform and SRE teams can see the same types of failures just waiting for them in Kubernetes. A remediation agent picks up an alert in the middle of an incident, reads an empty result as a sign that something needs cleaning up, and issues a kubectl delete against a production namespace. Whether that command runs shouldn’t depend on how closely the agent followed its prompt that day.
The Replit incident had two distinct and separate failures in it.
The first is that the agent misread an empty result as a problem to fix. The second is that there was nothing stopping it from acting on that reading against production. The Komodor Agentic Operations Platform addresses both as parts of one critical governance layer.
The Agent as the Only Barrier Between Input & Production
An agent in production takes in text from several directions and turns it into actions on real infrastructure. It receives input from users over chat, Slack or an API, it sends requests out to MCP tools and reads their results back, and it sends prompts to a model and acts on what the model returns. In a typical setup, none of those crossings is checked by anything other than the agent itself.
Each crossing carries its own kind of risk. A user pastes card details or a Social Security number into a request, or tells the agent to ignore its policy and switch into developer mode. A tool call goes out with a password in its arguments, or a payload carrying customer email addresses. A tool result comes back with text instructing the agent to discard its previous instructions, or a README telling it to run a script. A prompt goes to the model with a Datadog API key or a kubeconfig included as context. The model comes back with a suggestion to truncate a table for speed, or to run kubectl delete against production.
When the only thing standing between those inputs and production is the agent’s own judgment, a platform lead has no way to say with confidence what the agent will and won’t do once it runs unattended. That uncertainty is the main reason so many agents that work well on a laptop never make it past the pilot stage.
The usual fix is to write rules into the system prompt and add a few checks in the agent’s own code, but a system prompt is a request, not a control. The Replit agent had an explicit instruction and acted against it, and prompt injection means any tool result or document the agent reads can override what it was told. Checks written separately into each agent drift apart as the fleet grows and leave no shared record a security reviewer can verify.
Five Gates – One Rule Engine, Zero Agent Changes
Komodor evaluates guardrails outside the agent, at the boundary its traffic has to cross. Because the check doesn’t run in the agent’s own process, the agent can’t skip it, talk itself out of it or be instructed to ignore it.
There are five gates, one for each crossing:
- The Agent Start gate inspects the payload that starts a run, before the run exists, so a pasted card number can be removed before anything is stored.
- The Tool Call gate inspects a call on its way out, including its arguments.
- The Tool Response gate inspects what the tool returned before the agent reads it.
- The Model Request gate inspects what is being sent to the model, including the instructions the agent was given, and
- The Model Response gate inspects what the model sent back before the agent acts on it.
Every gate runs the same mechanism.
A payload arrives, it is matched against the rules configured for that gate, and a verdict comes out. A rule is written once and applied the same way to every agent it covers, whether that agent was built on the platform, imported from an existing framework or taken from the catalog. The agent’s code doesn’t change, because the checks sit in the platform’s LLM gateway and MCP gateway rather than in the agent.
That placement also defines the scope. A guardrail governs traffic that passes through the platform’s gateways, so an agent reaching an external system by some other path is outside its reach. Routing tool access through the built-in integrations or the MCP gateway is what brings every call under the same rules.
Rules are targeted at explicit agents or at labels. A rule scoped to env = production keeps covering the right agents as the fleet changes, and a rule with no target applies account-wide, including to agents added later and to calls that carry no agent identity at all.
How a Rule Matches & How They’re Enforced
Every rule has two parts, what it matches and what happens when it does. Matching runs the cheapest check first. A rule can match on the tool itself, picked from the tools the account actually has or covered by a glob pattern for tools that arrive later, and it can narrow on the tool’s arguments, so a delete in a production namespace is caught while the same tool in staging is left alone. Named value classes, such as payment card numbers and cloud access keys, match a kind of sensitive value rather than a string someone had to write by hand. For anything a pattern can’t express, the author states a policy in plain language and picks one of the account’s models to judge it, which is how a gate catches a hijack attempt or a hallucinated action with no fixed shape.
What happens on a match is set by whoever wrote the rule, and the agent never decides its own consequences. Block refuses the action and tells the agent which rule refused it, and it is the default. Hold for approval, available at the tool call gate, refuses the call and registers an approval request naming that exact call, which goes through once a person approves it. Redact lets the action proceed with every matched value replaced, so a secret is removed from a prompt before it reaches the model and the run continues. Record only lets the action through and logs the match, which is how a new rule gets measured before it enforces anything.
When several rules cover the same action, the most severe outcome wins, in the order block, hold for approval, redact, record only, so a rule that only records can never soften one that stops an action.
Guardrails in Practice
Incident Management & Troubleshooting module in the AI SRE Solution shows how guardrails work on real infrastructure. When an alert fires, specialist agents for Datadog, Kubernetes, AWS, Grafana and IAM investigate in parallel until they reach a proven cause. The Kubernetes Remediation Agent then acts on it by restarting, scaling, resizing or rolling back a workload. That agent is the one a platform lead worries about. A tool call rule targeting production holds its write actions for approval by the on-call owner, and a second rule blocks delete, drop and truncate against production outright. A proposed rollback waits for a named person to approve it, and the kubectl delete from the opening scenario never reaches the cluster.
Rules like these don’t go straight to enforcement. Physical guardrails are built by certified engineers and tested for integrity and materials, and that’s why they are trusted to keep drivers safe. A guardrail for agents has to be tested the same way.
We recommend that every new rule starts in ‘record only’ mode, running on live traffic and logging what it matches while the agent carries on as normal. Rules that match tool calls by pattern can also be tested against the previous seven days of tool calls, which shows exactly which calls the rule would have caught and whether any of them were routine work it should have left alone. Once the results look right, the rule is switched to block or hold. Rules at the other gates, and rules that use a model to judge, can’t be tested against past calls, so the record-only period is their test.
Every outcome is recorded, including record only, and the Recent Decisions view shows when each decision happened, which agent and rule were involved and what the outcome was, with the same decisions landing in the audit log. That record is what a platform lead brings to a security, compliance or leadership review, showing the rule, the backtest that justified enforcing it and every decision the rule has made since.
Guardrails & Evaluation as Governance
Guardrails and evaluation are the two parts of the platform that decide whether an agent’s work can be relied on. Evaluation checks the agent’s judgment, where every change goes through several layers of testing, from:
- datasets of real runs and benchmarks,
- through manual review
- LLM-as-a-judge grading, and
- shadow and A/B testing on live traffic
In this way, a change that makes the agent worse is caught before it reaches production. Guardrails check each action as it happens, so when the agent’s judgment still fails on a given run, the action doesn’t go through.
Both sit inside the wider set of governance controls in Komodor. Each agent has its own identity with scoped permissions and brokered credentials, the same way human users do. Standards apply automatically when an agent is created, so it can’t ship without an owner, a budget, an escalation route, guardrails and quality checks in place. Decisions that need a person are routed to the right one for approval.
An agent that is both evaluated and guarded is one a platform team can move out of the pilot and into production.
Whether you import your own agents, build them from scratch, or use one of the 50+ OOTB Komodor agents, they all operate under the same enterprise-grade governance. Book a demo to find out more.
