The Agent That Did Too Much
In Q1 2025 a small SaaS company deployed an autonomous data cleanup agent in their production environment. The agent had write access to their primary customer database. Over a weekend, the agent processed 14,000 customer records, applied a transformation that the team had not anticipated, and corrupted 9,000 of them. Recovery took 31 hours of engineering time plus a customer apology cycle. The incident report identified the root cause as missing guardrails. The agent's prompt had not anticipated the specific edge case that triggered the bad transformation.
This incident, and dozens of similar ones across 2024-2025, established the operational reality of agentic AI: agents that can take actions inherit the blast radius of those actions. An agent with read-only access can mislead. An agent with write access can corrupt. An agent with both plus tool integrations can cascade failures across systems.
OWASP's LLM Top 10 v2.0 explicitly addresses excessive agency as one of the top risks in production LLM applications (OWASP, LLM Top 10 v2.0, 2024). Production agentic systems in 2026 require explicit guardrails in four layers. Skipping any layer leaves a class of failure modes uncontrolled.
The Four Layers
Production agentic guardrails operate in four layers. Each layer catches failure modes the others miss. Together they bound the agent's behavior in ways that the agent itself cannot reliably bound.
The first layer is input validation. Before the agent processes a request, the input is checked for prompt injection, jailbreak attempts, malformed structure, and out-of-scope content. The check is structural and does not rely on the model recognizing the threat. Tools like Lakera Guard, Protect AI, and the major cloud providers' content moderation APIs handle this layer.
The second layer is action authorization. Before the agent takes an action, the action is checked against an explicit policy. Which agents can take which actions, against which resources, with which constraints. Read-only by default. Write access is granted narrowly. Destructive actions require human confirmation. The policy is enforced at the action site, not at the prompt.
The third layer is output filtering. After the agent produces output, the output is checked for sensitive content, policy violations, factual errors against verifiable claims, and structural correctness. Output filtering catches failures that input validation and action authorization miss because the model produced unexpected content.
The fourth layer is audit and rollback. Every action the agent takes is logged with full context. The logs support post-action forensics and, where possible, automatic rollback of actions that subsequent checks identify as wrong. The audit trail also supports regulatory requirements (EU AI Act high-risk system documentation, audit obligations in regulated industries).
A system with all four layers operating correctly catches most failure modes. A system missing any one of them has a class of failures uncontrolled.
What Each Layer Actually Stops
The first layer (input validation) stops prompt injection, jailbreaks, and adversarial inputs. It does not stop a well-formed input that the agent will misinterpret.
The second layer (action authorization) stops the agent from doing things it should not be allowed to do. It does not stop the agent from doing the wrong subset of things it is allowed to do.
The third layer (output filtering) stops sensitive information from leaking and obvious wrong outputs from being shown. It does not catch subtle wrongness that passes filter checks but is incorrect.
The fourth layer (audit and rollback) stops incidents from becoming unrecoverable. It does not stop the incident itself.
The layers compound. A motivated attacker or unfortunate input combination has to defeat all four layers to cause a sustained incident. Most attacks defeat one or two and are caught by the others.
The Action Authorization Pattern That Works
Of the four layers, action authorization is the one that most teams under-invest in. The pattern that works in production has three properties.
Actions are scoped per workflow, not per agent. An agent that supports both a low-risk workflow and a high-risk workflow runs different action authorization policies for each. The agent's identity does not grant blanket privileges.
Destructive actions require explicit confirmation, either from a user (synchronous workflows) or from another check (asynchronous workflows). The bar for "destructive" is set conservatively: deleting data, modifying customer records, sending external communications, anything with monetary impact.
Action history is rate-limited and pattern-detected. An agent that suddenly performs 100 actions in a minute when the typical rate is 10 per minute triggers an automated pause and human notification. This catches both runaway agents and successful attacks.
The teams that have implemented these three properties have not had the data cleanup incident in the opening story. The teams that have implemented none of them remain at risk.
The Compliance Side
For regulated industries, the four-layer guardrail framework produces documentation that satisfies regulatory requirements as a side effect.
EU AI Act Article 14 requires meaningful human oversight for high-risk AI systems. The action authorization layer's confirmation flows produce evidence of human oversight at decision points.
EU AI Act Article 12 requires automatic record-keeping. The audit layer produces the record.
DORA in financial services requires ICT incident reporting within 24 hours of a major incident. The audit layer produces the timeline; the action authorization layer's pattern detection produces the alerting.
The teams that build guardrails for safety and compliance simultaneously pay the cost once for two outcomes. The teams that build them separately pay twice and produce worse versions of both.
The Cost of Each Layer
Each guardrail layer has a cost. Knowing the costs helps the prioritization.
Input validation costs roughly 50-100ms latency per request plus the licensing or operational cost of the validation service. For high-volume workloads this can be a meaningful line item.
Action authorization costs engineering effort to define and maintain the policy plus latency for the policy check (usually under 50ms per action). The engineering effort is concentrated up front; the runtime cost is small.
Output filtering costs latency similar to input validation plus licensing or operational cost. For workloads where output structure matters, additional engineering effort for output schema validation.
Audit and rollback cost storage for the audit logs (significant at scale) and engineering effort for the rollback infrastructure. The cost is real but lower than the cost of unrecoverable incidents.
For a moderate-volume production agent, the total cost of all four layers is typically 10-20 percent of the underlying inference cost. The cost prevents incidents that would cost much more.
What Logiciel Does Here
Logiciel works with engineering teams operating production agentic systems where the guardrails were under-built and incidents have started accumulating. The work is typically structured around the four-layer model with priority on whichever layer is the most exposed.
The HITL Architectures framework covers the human oversight design that integrates with action authorization. The AI Security Threat Modeling framework covers the threat-side analysis that informs guardrail design.
A 30-minute working session is enough to assess your current guardrail coverage against the four layers.
Frequently Asked Questions
Which layer should I implement first?
Action authorization, almost always. The blast radius of unauthorized actions exceeds the blast radius of input or output content issues for most workloads. Input validation and output filtering are usually addressed by managed services; action authorization requires your own design.
How do I handle prompt injection specifically?
Defense in depth. Input validation catches obvious injections. Structured prompt construction separates trusted system content from untrusted user content. Output filtering catches the most damaging consequences. None of these alone is sufficient; the combination is.
Do guardrails reduce model capability?
Marginally, in well-designed systems. Aggressive over-filtering can produce systems that refuse legitimate requests. The tuning exercise is finding the threshold where unsafe outputs are caught and legitimate ones are not. Most production systems converge to a tuning that catches most issues with manageable false-positive rates.
How do I test guardrails?
Red teaming. Internal red team attempts to defeat the guardrails on a regular cadence (monthly minimum). External red team engagement quarterly or after major changes. The guardrails that are not tested do not work.
How do guardrails differ for multi-agent versus single-agent systems?
Action authorization complexity grows with agent count because each agent has its own scope. Audit trails grow more complex because actions cross agent boundaries. Input and output filtering are similar. Multi-agent systems should typically have stricter guardrails because the coordination introduces failure modes that single-agent systems do not have. Sources: - OWASP LLM Top 10 v2.0, 2024 - European Commission, EU AI Act timeline - Anthropic, "Building effective agents," 2024
