When enterprise LLM use was mostly chat, its worst failure was a wrong answer that a human read, caught, and corrected. Embarrassing, occasionally costly, usually recoverable. The moment that system can call APIs, run queries, change configurations, and trigger workflows, the failure stops being a wrong answer and becomes a wrong action. It can also become many wrong actions at once. Most enterprise security systems were designed around humans doing sensitive work sequentially: one screen, one click, one approval, one audit event. Agents do not have that shape. They can fan out tool calls, retry, fork plans, and make a bad assumption useful at machine speed. Most of the conversation about enterprise AI risk is still about hallucination rates. The harder problem in 2026 is authority: what an agent is allowed to act as, what it can touch, how each action gets authorized, and what happens when it’s wrong.
See also: What You Need to Know About Scaling Agentic AI
A wrong answer that executes is an incident
Walk through a boring example. An agent is asked to update some records. The model generates a perfectly valid UPDATE statement, but two reasoning steps earlier, it hallucinated a date, and that date is now in the WHERE clause. The query runs. No error is thrown. Rows are silently overwritten, and the agent reports success, because structurally, it succeeded.
Nobody notices for six weeks. If your ordinary backup retention is thirty days, the original data may be gone from the restore path that most teams actually know how to use.
This is the failure mode that separates agents from chatbots: actions can succeed structurally while failing semantically. The agent did exactly what it was told. What it was told was wrong. There’s no stack trace for that, no 4xx response, no alert. A hallucinated paragraph sits in a chat window waiting to be read; a hallucinated WHERE clause compounds.
Prompts are not permissions
The most common mistake I see in early agent deployments is treating the system prompt as an authorization layer. “Only modify records belonging to the current user.” “Never delete data without confirmation.” These are suggestions to a language model. They are not controls on a production system, and the difference matters the first time the model misreads context, gets prompt-injected by untrusted input, or confidently executes with incomplete information.
Authorization has to live outside the model, enforced where the tools are. Role-based access control gets you part of the way, but agent failures concentrate at the edges coarse RBAC often misses: right tool, wrong resource; right table, wrong tenant; right operation, wrong parameter. Constraining that requires fine-grained authorization at the tool layer or in a dedicated authorization service: not just which tools an agent can call, but which operations, with which arguments, against which resources.
There’s a structural consequence here that’s easy to miss. A production agent stack has two identity boundaries, not one. Inbound: Who is allowed to invoke this agent? Outbound: What authority does the agent hold when it calls a tool? Conflating them is one of the most common sources of exposure I encounter, because the agent silently inherits whatever the human who invoked it could do, then acts with patience and parallelism the human never had.
Bulk actions are where the blast radius hides
The scariest tool in an agent system is rarely named deleteEverything. That one at least looks like a loaded weapon. The dangerous ones look normal: updateRecords, syncAccounts, reconcileInvoices, archiveUsers, grantAccess. In human hands, those are operational conveniences. In an agent’s hands, they are bulk CRUD APIs with a reasoning engine in front of them.
Bulk create, read, update, and delete access should never be granted because it made a demo easier. It should be a deliberate product and security decision. If an agent can update 10,000 rows, it needs a preflight count, tenant and resource boundaries, parameter validation, a dry run, an explicit maximum, idempotency, a rollback artifact, and approval when the blast radius crosses a threshold. If that sounds like overkill, compare it to the cost of explaining that the model “meant well” while it updated every active customer record in the wrong region.
Read access deserves attention, too. We talk about CRUD as if the scary letters are C, U, and D. Bulk reads can be just as bad when the agent is exposed to prompt injection or compromised context. A system that can summarize one customer file is a feature. A system that can read every customer file and post the answer into the wrong workflow is a data breach with nicer grammar.
An agent is a principal. Treat it like one.
The moment an agent can execute tools, it’s a principal in your systems, the same as a service or an employee. It has an identity, it holds permissions, and it leaves traces. The forward-looking pattern is to stop letting agents run as a raw user session. Every tool call should preserve the human attribution, but execute under a separate agent workload identity with its own policy, so you can always answer who asked and what acted.
From there, least privilege applies with more force than usual, because the principal in question can be manipulated by anything it reads. Permissions start at zero and escalate through trusted workflows, not standing grants. A diagnostic agent gets no mutation rights at all. Credentials are scoped to the task and expire with the session. When the work ends, access ends, rather than lingering because nobody got around to revoking it.
One practical rule helps: separate recommendation from execution. The agent that investigates a problem should not automatically be the agent that fixes it. Let one agent produce a plan, evidence, and a proposed action set. Let a narrower executor carry out only the approved operations. This is boring security architecture. Boring is good. Boring means the incident review has fewer surprises.
Plan for the failure you didn’t prevent
Guardrails lower the probability of a bad action. They do not get it to zero, and pretending otherwise is how you end up explaining a silent data corruption to an audit committee. Production readiness has three properties: containment (how much damage can one wrong action do?), detectability (how fast do you find out, including when nothing visibly errored?), and reversibility (how cheaply can you undo it?).
Concrete patterns get you there:
- Write-ahead logging for intent. Before any mutation-capable tool call, the agent writes an immutable record of what it intends to do, why, the expected effect, and the rollback plan. If you can’t replay what the agent thought it was doing, only what it did, you haven’t deployed an agent so much as a blind spot.
- Reversible-by-design tools. Soft deletes over hard deletes, versioned writes over overwrites, compensating actions over one-way doors. Where a tool genuinely can’t be reversible, scope it to low-impact resources or gate it behind a human.
- Circuit breakers with real authority. Stop conditions on action count, spend, anomaly rate, and permission denials, with the power to pause workflows, revoke credentials, and drop the agent to read-only. Enforced in infrastructure. A stop condition written in the prompt is a suggestion, and we’ve already covered what suggestions are worth.
- Two-phase execution. The agent produces a structured plan, the plan gets validated or simulated, and only then does anything commit. This single pattern converts a large class of silent failures into visible ones before the first row changes.
- Rate limits and concurrency limits on tools. Not just API rate limits for vendor protection, but business limits for blast-radius control: rows changed per run, tenants touched per run, dollars spent per run, permissions granted per run, workflows triggered per minute. The fact that an agent can do fifty things in parallel does not mean your production systems should let it.
I learned the value of that last pattern before agents existed. At SpaceX, I ran the CI/CD systems used for rocket launches, and about 24 hours before one launch, our automated checks failed. The engineers who built the system knew the error and knew the fix, but we still spent hours in a conference room debating whether to trust the automation or redo the checks by hand. Our automation wasn’t the problem; what we lacked was visibility into exactly what it was about to do. Systems that act need to show their work before they act, or the humans around them will, rationally, refuse to trust them.
The questions to answer before production
Moving an agentic workload from proof of concept to production should require a yes to each of these:
- Does every agent have its own identity, scoped permissions, and time-bounded credentials, separate from the humans who invoke it?
- Is there a break-glass workflow that revokes an agent’s credentials mid-failure without taking the whole platform down?
- Can you reconstruct any action after the fact: tool calls, parameters, retrieved context, permissions used, and the agent’s stated rationale?
- Are bulk CRUD tools explicitly designed with dry runs, maximums, authorization checks, concurrency limits, and rollback paths?
- Can a new model or prompt version reach production without passing automated evaluations? (The answer needs to be no.)
None of these are model-quality questions. A better model makes wrong actions rarer and changes nothing about what happens when one occurs. That part is decided by how you built the system around it.
Many enterprise risk processes were built around human actors and deterministic software, and agents break their assumptions by adding new principals, new execution paths, new delegation chains, and new data flows all at once. The teams that deploy agents safely this year won’t be the ones with the most capable models. They’ll be the ones who treated identity, authorization, observability, and recovery as the actual product. Whether your agent hallucinates is the wrong question. When it does, and it acts on it, the question is whether your systems can contain it, catch it, and undo it. Hallucination is a model problem. Authority is yours.
