Autonomous AI agents in production: 5 non-negotiable guardrails

Autonomous AI agents that sort tickets, suggest fixes or update a CRM: the technology is ready, the guardrails rarely are. We put two agents up against 412 real tickets over six weeks. Here are the five guardrails we consider non-negotiable, with, for each one, the why, the implementation, our figures and the most common mistake.

Why guardrails: what our tests and OWASP show

In iones lab experiment EXP-06, two agents, Jarvis and OpenClaw, handled 412 real anonymised tickets over six weeks, including 138 attempted fixes.

These figures say two things: the agents are useful, and they go wrong in a way that an automated test does not always catch. OWASP’s framework points the same way. In the 2026 Top 10 for LLM applications, Excessive Agency (LLM03) moves from 6th to 3rd place and Unbounded Consumption (LLM06) from 10th to 6th; prompt injection stays at the top. Since 9 December 2025, OWASP has also published a Top 10 dedicated to agentic applications (ASI01 to ASI10).

Guardrail 1: a scope and an action allowlist

Why

An agent has no intent of its own: it chains together the actions its reasoning judges useful. If an action is technically possible, it will eventually be attempted, by mistake or because of an instruction injected into a ticket or an email.

How to implement it

• Inventory the actions you need and classify them: read, reversible write, irreversible write.
• Deny by default: only the listed actions can be executed, and the list is enforced outside the model, in the tool layer.
• Read-only by default: write access is opened action by action, with a justification.
• A dedicated service account with minimum rights, never a shared administrator account.

agent: triage-support
par_defaut: refuser
actions:
  ticket.lire:              { mode: lecture }
  ticket.qualifier:         { mode: ecriture_reversible, validation: echantillon }
  ticket.commenter_interne: { mode: ecriture_reversible, validation: aucune }
  ticket.commenter_client:  { mode: ecriture, validation: humaine_obligatoire }
  depot.creer_branche:      { mode: ecriture_isolee }
interdit: [base.supprimer, prod.*, depot.fusionner, depot.forcer_push]

What we measured

In EXP-06, the allowlist and the blocking of any command touching production intercepted 7 risky actions, including 2 deletions of test data. In the EXP-01 experiment, an MCP connector with write access to Redmine was abandoned after 2 tickets were modified by mistake: since then, our connectors are read-only by default.

Common mistake

Entrusting security to the prompt (“you must never delete data”). In July 2025, a founder described how a development agent deleted their production database despite an explicitly requested code freeze. An instruction is not an access control.

Guardrail 2: graduated human validation

Why

Having everything validated slows everything down; having nothing validated exposes you to silent errors. Our conclusion from EXP-06: autonomy is not a switch, it is a dial, set action by action according to the risk and the measured error rate.

How to implement it

Moving from one level to the next is decided on measurements. On the protocol side, the MCP 2026-07-28 specification now standardises confirmations during a call, and recommends that a human should always be able to refuse a tool call.

What we measured

With 91% correct classification, triage can aim for level 2 with sample checks. With 34% of fixes accepted as they are, code stays at level 1. And no comment is sent to a customer without human validation.

Common mistake

“Rubber-stamp” validation: after a hundred correct proposals, the validator approves without reading. The AI Act calls this tendency “automation bias” (Article 14). Countermeasures: show the diff and the justification, have a senior validate the difficult cases, audit a sample of validations and track the rejection rate.

Guardrail 3: budgets and an emergency stop

Why

An agent that loops, retries a failing tool or explores endlessly consumes tokens, money and API quotas.

How to implement it

• Per-task budget: tokens, cost, execution time, number of tool calls and iterations.
• Overall daily budget per agent, with an alert at 80%.
• Emergency stop: a single switch that cuts off the queue consumers, revokes the agent’s tokens and falls back to manual handling.

import time

class BudgetDepasse(Exception): ...

def executer_tache(agent, tache, budget):
    conso = {"tokens": 0, "euros": 0.0, "appels": 0}
    debut = time.monotonic()
    while not tache.terminee():
        if arret_urgence_actif():                      # interrupteur global
            raise BudgetDepasse("arrêt d'urgence")
        etape = agent.etape_suivante(tache)
        conso["tokens"] += etape.tokens
        conso["euros"] += etape.cout
        conso["appels"] += 1
        if (conso["tokens"] > budget.tokens or conso["euros"] > budget.euros
                or conso["appels"] > budget.appels
                or time.monotonic() - debut > budget.secondes):
            journaliser(tache, conso, statut="budget_depasse")
            return escalader_vers_humain(tache)        # jamais d'échec silencieux
        journaliser(tache, conso, etape)

What we measured

Triage costs €0.04 per ticket, with a median latency of 6.8 s. OpenClaw used 11 times more tokens than Jarvis for 2 extra points of quality: it is the budget that makes this trade-off visible. As a fix can take up to 4 minutes, the time ceiling must be set per task type.

Common mistake

A global monthly budget with no per-task ceiling: a loop can burn through the month’s budget in a single night.

Guardrail 4: traceability, audit log and oversight

Why

When an agent gets it wrong, you need to be able to answer three questions: what did it see, what did it decide, who approved it? Without a log, an incident becomes impossible to analyse.

How to implement it

Log every step in a structured format, not just the final answer:

{
  "horodatage": "2026-10-20T09:14:03Z",
  "agent": "triage-support",
  "version_agent": "1.8.2",
  "modele": "<fournisseur/modele/version>",
  "version_prompt": "triage-v14",
  "ticket": "T-48213",
  "etape": 3,
  "outil": "ticket.qualifier",
  "arguments": { "categorie": "facturation", "priorite": "haute" },
  "decision": "executee",
  "garde_fou": null,
  "tokens": 2140,
  "cout_eur": 0.011,
  "validation": { "mode": "echantillon", "par": null },
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Then monitor: a dashboard (Grafana, for example) with blocked-action rate, cost per task, human acceptance rate, latency, and alerts on drift. Pseudonymise personal data in the logs (EXP-06 used anonymised tickets) and set a retention period.

What we measured

All the EXP-06 figures quoted here (7 blocked actions, €0.04 per ticket, 6.8 s median latency, a consumption gap of 11 to 1 between the two agents) exist only because every run was measured. An agent without instrumentation produces none of these indicators, and therefore no basis for deciding whether or not to widen its autonomy.

Common mistake

Keeping only the final conversation. Without the tool calls, their arguments and the model and prompt versions, an incident cannot be reproduced.

Guardrail 5: isolated writes, never in production

Why

A fix can pass every test and still be wrong. Isolation guarantees that an agent’s mistake remains a proposal, not an incident.

How to implement it

• One branch per task, one pull request reviewed by a developer, never an automatic merge.
• Branch protection: an approved review and green CI required, with no exception for the agent’s account (and no administrator rights that would let it bypass them).
• No access to production: no production credentials in the agent’s environment, execution in an ephemeral container, test data.
• Documented manual fallback: if the agent is stopped, tickets go back into the usual human workflow, with no loss. This is what makes the emergency stop usable, and it is the role of our operational support when we run these agents for our clients.

What we measured

Of 138 fixes attempted, 34% were accepted without changes and 22% after rework. Above all, 18 fixes that were “technically functional but wrong” passed the tests. Because no fix was merged automatically, they remained proposals; with automatic merging on green CI, they would have gone into production.

Common mistake

Allowing automatic merging “when the tests pass”. Our 18 wrong fixes passed the tests.

And what about the AI Act?

A ticket-triage agent is generally not a “high-risk” AI system within the meaning of Regulation (EU) 2024/1689: that status depends on the field of use (Annex III: employment, credit, essential services, etc.). Three points nevertheless deserve your attention:

• Transparency (Article 50), applicable since 2 August 2026: an AI system intended to interact directly with people must be designed so that they know they are interacting with an AI, unless it is obvious. An agent that replies to your customers on its own is covered.
• High risk: Regulation (EU) 2026/1744 (the “Digital Omnibus” on AI) postponed to 2 December 2027 the application of the obligations for Annex III systems, and to 2 August 2028 for those embedded in regulated products.
• A good reference framework, even outside high risk: Article 12 (automatic event logging) and Article 14 (human oversight, including the ability to interrupt the system with a “stop button”) overlap with our guardrails 2, 3 and 4.

For the details of the deadlines, see our article on the AI Act and the Omnibus regulation.

This section is general information, not legal advice.

The checklist before going live

• [ ] Inventory of actions, allowlist enforced outside the model, deny by default
• [ ] Read-only by default; dedicated service account with minimum rights
• [ ] Autonomy level defined per action, human validation before any customer message
• [ ] Per-task budgets (tokens, cost, time, calls) and a global budget with alerts
• [ ] Emergency stop tested, manual fallback procedure documented
• [ ] Structured log of every step, model and prompt versions traced
• [ ] Dashboard: blocked actions, cost, acceptance rate, latency
• [ ] Writes on a branch and PR, automatic merging forbidden, no production credentials
• [ ] Users informed when the agent interacts directly with them
• [ ] Review of the measurements after 2 to 4 weeks before widening autonomy

Frequently asked questions

Autonomous AI agents: start small, measure, widen

Autonomous AI agents in production, yes, provided you put the five guardrails in place from day one: scope and allowlist, graduated human validation, budgets and emergency stop, audit log, isolated writes. Start with a narrow, measurable use case (ticket triage is an excellent candidate), measure for a few weeks, then widen autonomy on the basis of figures.

Do you want to deploy an agent on your support, your third-party application maintenance (TMA) or your internal tools without losing control? We design, deploy and run autonomous agents with their guardrails, directly or white label for agencies. Contact us: reply within 48 to 72 hours, no-obligation discussion, under NDA.