Before an AI Agent Touches Customer Data: Six Production Gates It Must Pass

An agent demo runs on clean inputs, helpful test data, and a patient operator who already knows the right answer. Production is different. The data is incomplete, contradictory, and sometimes adversarial. The stakes are real. And the person watching the output is not the person who built the system.

A successful demonstration proves that an agent can complete a task. It does not answer the questions a production owner has to answer: what happens when data is missing, who is allowed to change what, how are failures detected, who is responsible when the agent is wrong, and whether the organization can reproduce and investigate what it did.

The gap between a prototype and a production system is wider than most teams expect. The first systematic study of agents in production, covering 86 practitioners across 26 domains, found that reliability is the single hardest problem teams face, and that most teams solve it through systems-level design rather than model improvement (Pan et al., 2025). Anthropic’s own engineering team reached the same conclusion after shipping a multi-agent research system to production: “the last mile often becomes most of the journey,” and minor issues that would be harmless in traditional software can derail agents entirely (Anthropic, 2025).

What follows is a go/no-go framework I use with teams preparing to put an agent in front of real data. Six gates. Each one governs a single decision. Each one has an evidence requirement and a pass condition. None of them is about the model.

Gate 1: Is the workflow bounded?

Before discussing models, define the exact job. A production agent is not a general assistant. It is a system that executes one workflow, with named inputs, named outputs, and a named stopping condition.

Map the workflow before you touch the agent:

Trigger: what starts it? A user message, a scheduled job, an event in an upstream system.
Inputs: what data does it receive, in what format, with what permissions attached?
Tools: what can it call, what does each tool do, and what does each tool cost?
Decisions: where does the agent decide between options, and where does it follow a fixed rule?
Outputs: what does it produce, where does it go, and who reads it?
Stopping condition: when is the job done? How many steps are allowed before it must stop or escalate?
Reversibility: which actions can be undone, and which cannot?

The production study found that 68% of deployed agents execute at most 10 steps before a human intervenes (Pan et al., 2025). That is not a limitation. It is a design choice. Short, bounded workflows fail in bounded ways.

Pass condition: the workflow can be drawn as a bounded sequence with named exceptions, a maximum step count, and one accountable owner.

Gate 2: Is the data boundary understood?

Most agent projects die here. Not because the model is wrong, but because nobody mapped where data enters, where it moves, and where it persists.

Start with a data-flow diagram. Draw every component: the user, the agent, the model, the retrieval system, every tool, every log sink, and every external service. Then trace the data through it.

For each data path, answer four questions:

Classification: what is the sensitivity of this data? Public, internal, confidential, restricted?
Access rights: who is allowed to see this data? Does the agent’s identity carry the right scope, and only the right scope?
Retention: where is this data stored, for how long, and who can delete it? Prompts, responses, tool-call arguments, traces, and evaluation datasets all count.
Exposure surface: can this data appear in logs, in vector stores used by other agents, in evaluation sets reviewed by vendors, or in model training data?

The threat is not only accidental leakage. Indirect prompt injection is now a documented attack class: malicious instructions embedded in retrieved documents, emails, or API responses that hijack agent behavior (Gulyamov et al., 2026; OWASP LLM01). An agent that reads untrusted content and then acts on it is the standard production failure.

The data boundary also determines the deployment topology. For regulated data, the choice between a public API, a private cloud, and an on-premises model is not a preference. It is a compliance decision with cost, latency, and capability consequences.

Pass condition: every data transfer, storage location, and access decision is documented in a diagram someone outside the build team can read.

Gate 3: Can reliability be measured before release?

One accuracy number is not an evaluation. It is a marketing claim.

A production evaluation set should cover the full distribution of situations the agent will meet in production, not only the easy cases:

Normal tasks: the common path.
Ambiguous requests: inputs that could reasonably mean two things.
Missing and conflicting information: data that is incomplete or contradictory.
Tool failures: timeouts, rate limits, malformed responses.
Permission violations: cases where the agent should refuse.
Prompt injection and malicious documents: adversarial inputs designed to change the agent’s behavior.
Multi-step compounding errors: cases where a small early mistake cascades.
Cases requiring refusal or escalation: the agent must recognize what it cannot do.

Recent work on enterprise agent evaluation makes the cost of accuracy-only thinking concrete. Optimizing purely for task completion produces agents that are 4.4 to 10.8 times more expensive than cost-aware alternatives at comparable performance. Worse, a single run can show 60% accuracy while eight repeated runs of the same task drop to 25% consistency (Mehta, 2025). An agent that is right once and wrong twice on the same input is not production-ready, no matter what the best run shows.

The CLEAR framework (Cost, Latency, Efficacy, Assurance, Reliability) predicts production success far better than accuracy alone, with a correlation of 0.83 versus 0.41 (Mehta, 2025). The lesson is direct: measure cost, latency, safety behavior, and run-to-run consistency alongside accuracy, or do not claim you have measured reliability.

The production study adds one more uncomfortable fact: 74% of deployed agents still depend primarily on human evaluation (Pan et al., 2025). Human review is necessary, but it does not scale and it does not catch the failures that only appear under load.

Pass condition: the team has a versioned evaluation set covering all eight categories above, defined release thresholds for each metric, and regression testing that runs on every prompt, model, or tool change.

Gate 4: Does the agent have limited authority?

An agent with broad permissions is the easiest way to ship a demo. It is also the fastest way to cause a production incident.

Least privilege for agents means three things, and all three are required.

First, identity. The agent is a first-class principal, with its own managed identity, a named owner, and a documented purpose statement. Not a shared secret, not a reused service account, not the credentials of whoever happened to build it (Microsoft Security, 2026).

Second, scope. Permissions are task-based, not team-based. Read access before write access. Separate roles for evidence gathering and for remediation. Time-limited elevation for anything beyond the baseline, with automatic drop-back when the workflow completes. The common failure pattern is quiet and incremental: an agent starts as a reader, the workflow expands to include fixes, the team grants broader access rather than redesigning the role, and nobody revisits it.

Third, tool binding. The agent sees only a curated, allowlisted set of tools. High-impact operations (delete, export, send, transfer, deploy) require explicit approval bound to the exact action, not blanket pre-authorization. OWASP classifies unchecked autonomy as “Excessive Agency” (LLM08) and lists tool abuse, privilege escalation, and goal hijacking as primary attack vectors in its AI Agent Security Cheat Sheet.

A practical authority ladder for any agent:

Answer questions from data it can read.
Recommend an action a human reviews.
Prepare an action for human approval.
Execute reversible actions autonomously.
Execute consequential actions only with step-up approval.

Move the agent up one level at a time, only when the level below has passed its evaluation threshold. Never start at level 4.

Pass condition: the agent has a dedicated identity, task-scoped RBAC, a tool allowlist, and a documented authority level that matches the evidence you have, not the evidence you hope to have.

Gate 5: Can failures be detected and reversed?

Traditional software fails in recognizable ways: an error code, a stack trace, a metric that crosses a threshold. Agents fail in semantic ways that traditional monitoring does not catch. A tool call returns 200 OK and the agent acts on a hallucinated result. A retrieval system returns plausible but wrong context. A step succeeds technically while the overall task drifts off course.

The operational layer needs four things.

Tracing. Every run is traced end to end: model version, prompt version, retrieval version, tool versions, inputs, outputs, and decisions at each step. Without full traces, a reported failure cannot be reproduced, and an unreproducible failure cannot be fixed. Anthropic’s production team found that without full tracing, user reports of agents “not finding obvious information” were impossible to diagnose (Anthropic, 2025).

Outcome monitoring, not just uptime. Track task outcomes (success, partial, failure, escalation), not only latency and token usage. Alert on unusual action patterns: repeated retries, tool calls outside normal hours, cost spikes, actions on resources the agent rarely touches.

Kill switches and rollback. A fast way to disable the agent identity, revoke its credentials, and roll back its last actions. This is tested the same way feature reliability is tested. If you have never practiced disabling the agent in a real scenario, you do not have a kill switch. You have a hope.

Incident response. A defined procedure for what happens when the agent does something wrong. Who is paged? Who investigates? Who communicates externally? Who decides whether to redeploy or roll back?

The cost dimension lives here too. Agents consume tokens at 4 to 15 times the rate of chat interactions (Anthropic, 2025), and unbounded loops can drain a budget before anyone notices. OWASP lists Denial of Wallet as a recognized attack class in its AI Agent Security Cheat Sheet. Budget caps, retry limits, and chain-depth limits are not optional.

Pass condition: a failed action can be detected, explained, contained, and recovered from within a defined time window, using evidence the system already collects.

Gate 6: Is there an owner and operating model?

The question that kills most agent projects is not technical. It is: who runs this on the day the original team leaves?

An agent in production is a living system. Prompts drift in effectiveness as models change. Evaluation sets go stale. Tools get deprecated. Costs creep up. New failure modes appear under load that no one predicted. Without a named owner and a documented operating model, the system degrades silently until it fails in a way nobody can explain.

Define, before launch:

Business owner: the person accountable for the outcome the agent produces.
Technical owner: the person accountable for the agent’s behavior, performance, and maintenance.
Evaluation maintenance: who updates the evaluation set, how often, and against what new cases.
Change approval: how prompt changes, model upgrades, and tool additions are reviewed and approved.
Runbook: the documented procedures for common incidents, including the kill switch from Gate 5.
Cost tracking: cost per successful task completed, not cost per token. Token cost hides behind task complexity.
Support expectations: what users can expect, what they cannot, and where they escalate.
Success criteria for scaling, redesigning, or stopping: the conditions under which the agent gets more scope, gets rebuilt, or gets retired.

Handover documentation is not a deliverable. It is a living artifact. If the last update is older than the last prompt change, the documentation is wrong.

Pass condition: a named owner exists for performance, risk, cost, and maintenance, and that person can answer “what does this agent do, what does it cost, and what happens if it breaks” without asking the original builder.

The production-readiness scorecard

Put the six gates into one table. Use it before launch, and revisit it on every material change.

Gate	Evidence required	Status
1. Bounded workflow	Workflow map, step limit, exceptions, owner
2. Data boundary	Data-flow diagram, access map, retention policy
3. Evaluation	Versioned eval set across 8 categories, release thresholds, regression tests
4. Authority	Dedicated identity, task-scoped RBAC, tool allowlist, authority level
5. Recovery	Full tracing, outcome monitoring, kill switch tested, incident procedure
6. Ownership	Named owners, runbook, cost-per-task tracking, change-approval process

One failed gate does not necessarily kill a project. Some gates can be partially met with compensating controls. But a gate that has no evidence at all should stop uncontrolled deployment. An agent that cannot answer “what happens when it fails” should not be allowed to act on data it cannot undo.

What this framework does not do

Passing all six gates does not guarantee safety. It does not eliminate hallucinations, prevent every prompt injection, or make the system immune to model drift. What it does is move the decision from “does the demo work” to “do we have evidence this system can operate under real conditions.” That shift is the difference between a team that ships agents and a team that ships incidents.

The teams that succeed with agents in production are not the ones with the best model. They are the ones who bounded the workflow, mapped the data, measured reliability honestly, limited authority, planned for failure, and named an owner before launch.