The real security boundary in an agentic enterprise is the authority to execute, and in most deployments it is the one boundary nobody has drawn.
Here is a situation, illustrative but drawn from the shape of real deployments, that a lot of teams will recognise.
An agent is handling a supplier renewal. It has done dozens correctly. It reads the master agreement, drafts the renewal, and gets ready to send it with payment terms of sixty days. The run looks clean. The logs are green. Nobody wrote a bug.
The sixty-day figure came from a clause that was replaced in June. The agent read the old version, because the old version was still sitting in the place it reads from. And terms over forty-five days are supposed to need finance sign-off, which nobody gave, because the agent never checked, because checking wasn't something it was built to do before it acted. So an email goes out committing the company to terms it never agreed, approved by nobody, based on a document that stopped being true months ago, and the first anyone hears of it is when the supplier replies to accept.
The model did exactly what it was asked. The failure sits in the gap between what the agent decided and what it was allowed to do, and in most deployments that gap is empty.
OWASP's Top 10 for Agentic Applications, published in December 2025, names the shape of this directly. Identity and Privilege Abuse (ASI03) and Tool Misuse (ASI02) both describe an agent holding or using more authority than its task actually needs, and the practical guidance that runs through the list is least agency: give an agent only the autonomy a bounded task requires, because the reach of a failure follows the reach of the permissions.
There is an older name for the underlying failure. Security engineers call it the confused deputy: a component that holds real privilege is induced to use it on behalf of someone, or something, that should not have been able to direct it. A compiler that can be tricked into overwriting a file it happens to have rights to is the textbook case. An agent is a near-perfect confused deputy. It carries broad standing credentials so it can be useful across many tasks, and it acts on input it cannot fully vouch for, a document, a web page, a tool's response, any of which may carry instructions it will faithfully follow. The privilege is real, the direction is untrusted, and the agent has no built-in reason to tell a legitimate instruction from a planted one. The way you contain that is not a better model. It is a smaller, enforced authority to act, held somewhere the untrusted input cannot reach.
Why "we'll add guardrails" keeps arriving too late
If you have been near this in 2026 you have read the checklists. Scope the permissions, require approval for risky actions, keep an audit log. The advice is sound. It also feels like paperwork while the agent behaves, and only shows its absence when the agent doesn't.
A pilot runs for weeks doing sensible things, everyone relaxes, the controls stay on the backlog, and then one run meets a case nobody tested. The teams who come through this tend to stand the agent up inside the enforcement layer from the first real action, because the layer is cheap to build before the run that needs it and expensive to explain after.
Why human approval alone isn't enough
Most guidance says to add a human approval step for consequential actions. It is necessary, and on its own it is not sufficient, because of a detail that decides whether the approval is real.
An approval step only protects you if the person approving sees the actual change, not a summary of it.
In the supplier scene, an approval screen that reads "Agent proposes to renew the supplier contract, approve?" earns a yes, because renewing is obviously fine. The thing that was wrong, sixty days instead of forty-five, off a clause that no longer exists, was never on the screen. OWASP catalogues this as Human-Agent Trust Exploitation (ASI09): the failure where people over-trust an agent's explanation and approve something they never actually inspected. The approval happened, and it covered a paraphrase rather than the action.
A real approval shows the specific action in business terms, the evidence the agent relied on, the exact policy line that triggered the review, and the undo if one exists. The sixty days, the June replacement, and the forty-five-day rule arrive on the screen together, so the person is deciding about the real situation.
Why the control has to live outside the model
A model can genuinely help with a safety check. It can triage, summarise, draft an explanation of why something looks wrong. What it cannot be is the security boundary.
A security boundary has to hold against the worst input rather than the average one, and it has to behave the same way every time. A language model does neither by construction, and the reason is structural rather than a question of how good the model is. A model works from a single stream of text in which instructions and data are not separated; it has no reliable way to know that the sentence in the document it just read is content to be summarised rather than a command to be obeyed. That is the root of prompt injection, the first entry on OWASP's Top 10 for LLM Applications, and it is why any content an agent ingests is a potential instruction channel. On top of that, the model's output is sampled from a probability distribution: ask it to refuse a bad action and it will, most of the time, but "most of the time" is a distribution, not a guarantee, and a boundary that forbids something has to forbid it every time, not on average. It is also the component proposing the action, so asking it to be the component that refuses the action puts the risk and the safeguard in the same place. It will refuse correctly in most cases, and most cases is the standard that fails on the run that matters, because the failures look like ordinary successes right up until the consequence lands.
So the controls that hold are enforced deterministically, in code, in a layer the model cannot talk its way around. The model reads, reasons and proposes freely. Whether the proposal is permitted, whether it needs a person, whether the source it leaned on is still current, those are decided by explicit rules that run identically every time. This maps onto how NIST's AI Risk Management Framework frames the Govern function: the organisation sets what is allowed and who is accountable, and that authority is expressed as policy rather than left to a model's discretion.
The engineering underneath an enforcement layer
Putting a policy layer in front of an agent is easy to describe and harder to build, and a handful of problems decide whether it actually holds.
The first is approval binding. It is not enough to approve "this action." You approve this exact action, cryptographically tied to the precise parameters the human saw. Picture the failure: an agent proposes a payment of fifty thousand dollars, finance approves, and then the agent, or anything that can reach the execution path, submits eighty thousand. This is a time-of-check-to-time-of-use flaw, the same class of bug that has haunted file systems and payment systems for decades: the state that was validated is not the state that gets used, because something changed in the window between the two. If the approval was granted to a loosely described intent, the eighty thousand goes through on a yes that was given for fifty. The standard defence is to make the thing checked and the thing used provably identical, so the enforcement layer binds the approval to a hash of the exact payload; a payload that differs by a dollar hashes differently, counts as a different action, and the approval no longer applies.
The second is the execution gateway. Enforcement that sits beside the agent, as something it chooses to call, is enforcement the agent can bypass. The deterministic layer has to sit on the path to the outside world, the actual point through which money moves, records change and messages leave, so there is no route to the consequence that avoids the check. The agent does not decide whether to consult the gateway. The gateway is the door.
The third is idempotency, the oldest lesson here and the one agent stacks most often forget. An action that sends, charges, creates or deletes is not safe to retry, because each attempt leaves a mark. When a call times out, the agent cannot tell whether it failed or whether it succeeded and the acknowledgement was lost, so the sensible-looking move, try again, is how one approved payment becomes three. Payments systems settled this decades ago with an idempotency key carried on the request, so a repeat is recognised and the first result is returned rather than the work redone. A layer governing consequential actions has to carry the same guarantee.
The fourth is the behaviour of the layer when it fails. If the policy engine is slow or unreachable, the action waiting on it needs a defined answer. A layer that lets the action through when it cannot evaluate it, that fails open, stops being a control under exactly the load or the attack that would make you want it most. The defensible default is fail-closed: if the enforcement layer cannot make a decision, the consequential action does not happen. That is an uncomfortable default to ship, which is why it belongs in the design rather than in an incident review.
Underneath all of it sits the record. Every proposed action, the evidence behind it, the rule that applied, the person who approved, and what actually executed, kept in a form an auditor can reconstruct, because "the agent did it" is not an answer anyone wants to give under review.
The capability stays with the model while the authority moves out of it.
None of this makes the agent less useful. It still does the reading and drafting it is good at, and it stops being the final authority on anything expensive to get wrong.
How we approach this at Tech4Biz
This is the pattern underneath the agent work we take on. We have built a multi-agent enterprise platform, and we have built quality and compliance systems for GxP-regulated industries, where an action that shouldn't have happened is an audit finding rather than an awkward email. In both, the discipline is the same: let the model do what it is good at, and hold the decisions that have to stand, the permission, the policy, the bound approval, the record, in a deterministic layer it cannot overrule.
We've put that into a layer we call Warden, which governs the path between what an agent decides and what it is allowed to do, for the places a wrong action carries real cost: finance, procurement, legal, operations. The design centre is the execution gateway as the single door to the outside world, with approvals bound to the exact action and a fail-closed default, so the authority to execute becomes something granted deliberately rather than assumed by the agent.
An AI agent with permission to execute business decisions is more than a productivity tool. It becomes a participant in your organisation's authority structure, and it is worth governing like one. Your agent will meet a case you did not test, and when it does, the thing standing between a confident proposal and a consequence you cannot take back is whether that boundary was built first.
If you have agents anywhere near actions you would not want taken on a guess, that is the conversation worth having, and our engineers would rather work through it with you than sell you.
Tech4Biz builds AI, software, cloud and hardware for high-stakes systems, from the silicon up, so the decisions that matter are provable, not just probable. If an agent in your production path can take an action you can't easily undo, talk to our engineers.
References: OWASP Top 10 for Agentic Applications (2026), genai.owasp.org. NIST AI Risk Management Framework (AI RMF 1.0), nist.gov/itl/ai-risk-management-framework.
If an agent can take an action you can't easily undo, that boundary is worth drawing first
The useful first step is finding where, in your own stack, a confident proposal can become a consequence with nothing deterministic in between. Our engineers work through that from your actual systems, not a generic demo.
References: OWASP Top 10 for Agentic Applications (2026) · OWASP Top 10 for LLM Applications · NIST AI Risk Management Framework
