You Bought the Whole Stack. Who Owns the Decision?
Every layer of AI security governs what the system can do. None of them governs whether it was right.
By Thomas Tornatore, Founder of Fellowship Intelligence
The AI safety market is organized as a stack. When something goes wrong, the reflex is to add a layer: a new filter, a tighter guardrail, a better gateway, a more granular permission. The instinct is understandable, because the stack is where the visible work happens and where the budget lives. But the layer that decides whether your organization survives an AI failure is not on the stack, and no amount of spending will put it there.
It is worth walking the stack honestly, because every layer on it is real and most of it is worth buying.
At the bottom is the input. You can sanitize prompts, screen for injection, and strip the obvious attempts to talk a model into something it should not do. Above that sit the guardrails, the filters on the output that catch responses you have ruled off limits. Above that is identity and access, the work of deciding what an agent is and which systems it may touch. Above that is capability, least privilege applied to software that can act, so the agent simply does not possess the ability to take an action it was never granted. Above that is the network, the transport boundary that can stop an unverified state from crossing the wire at all. And wrapped around all of it, monitoring watches what the agent does in production, and evaluation red-teams what it might do before you ship it.
These are not marketing categories. They are genuine engineering, and an organization running AI without them is exposed in ways it should not be. Buy them. The point that follows is not that the stack is wrong. It is that the stack is incomplete in a way no further layer can fix.
Notice what every one of those layers does. Each one either limits what the agent can do or watches what the agent did. The input, capability, and network layers draw boundaries around its range of action. Monitoring and evaluation observe and test that action, before and after. Add any layer the vendors have not shipped yet, including a human dropped into the loop to approve the output, and it still falls into one of those two buckets. It limits, or it watches.
Not one of them governs whether the action the agent took was the right one.
That distinction is the whole argument, so be precise about it. There are two kinds of failure. The first is the agent doing something it was never permitted to do, and the stack is built for exactly that. A capability the agent does not have cannot be invoked by any prompt, however clever. A vault door blocks the robber regardless of intent. The second kind of failure is the agent doing something it was fully permitted to do that turned out to be wrong. No layer of the stack catches that one, because to the stack it does not look like a failure. It looks like permitted activity.
Make it concrete. A bank deploys an agent to handle servicing decisions inside a tightly scoped envelope: read the customer record, apply the policy, approve or decline within set limits. Every layer is in place. The prompts are clean, the permissions are minimal, the actions are logged, nothing crosses a boundary it should not. Then a customer in genuine hardship calls, and the agent applies the policy exactly as written and declines a forbearance that any experienced officer would have granted, because the situation was the kind of exception the policy never anticipated. Nothing broke. No control failed. The agent did precisely what it was authorized to do, and it was the wrong call. There is no layer in the stack that flags this, because no rule was violated. The only thing that catches it is a person who can look at the decision and say, that one is wrong, reverse it.
And this is not a temporary gap that a smarter layer will eventually close. The space of consequential decisions is not enumerable. You cannot write, in advance, the complete list of which permitted actions will turn out to be wrong, because that depends on context the rules cannot see. This is not a matter of opinion. NIST recently published a mathematical proof, applying Gödel’s incompleteness logic to AI guardrails, establishing that no finite set of rules is ever complete against a system operating in an open world. For any fixed set of controls, a case that defeats them exists. You can push the control down the stack as far as you like, from the words to the structure to the capability to the wire, and at every level you will have governed what the agent can do and never whether it should have. The stack has no layer for judgment, and by that proof, it never will.
This leaves an uncomfortable piece of math for anyone who built an AI program by buying layers. You have most likely spent the most on the layers that protect you least against the failure that actually reaches a customer, a regulator, or a headline. The breach you can wall off is rarely the one that ends up in front of a board. The authorized, plausible, in-policy decision that was simply wrong is the one that does, and it is the one the stack was never built to catch.
The gap, then, is not a missing control. It is a missing owner.
Here is why the owner is missing by default, and not through anyone’s negligence. Every layer of the stack has a clear owner. Security owns the controls. Engineering owns the integration. Compliance owns the policy. The business owns the use case. Ask any of them who owns the controls and you get a fast, confident answer. Ask who owns the decision the agent makes, the actual call, accountable for the outcome, and the answers come from four directions at once, which is the same as no answer at all. Ownership of the decision falls into the space between the seats. Everyone is responsible for a layer, and no one is accountable for the call. That gap is invisible during normal operation and the only thing anyone can see the moment something goes wrong.
Closing it requires being specific about what an owner is, because the word is easy to say and easy to fake. An owner is not a committee that meets quarterly to oversee a system that acts every second, and it is not an acceptable-use policy in a binder. An owner is a named individual with the authority to override the system, who does not default to its output, and who can be asked, later, why. This is not the human dropped into the loop to approve and move on. It is the one with the standing, and the obligation, to say no. Each of those properties is load-bearing. Authority to override is the one organizations quietly withhold, because overriding a system under operational pressure means stopping something the business wants to keep moving, and that authority carries a real cost. An owner without it is not an owner, only a name on the incident report. And the role cannot be set once and forgotten, because the named owner moves on, the role shifts, and a year later the accountability points at someone who is no longer there. Ownership has to be a live assignment, not an entry in a document.
A practical objection is scale. If the agent is making thousands of decisions a day, no named owner can review each one, and no sensible governance model requires it. But this does not dissolve the ownership question, it clarifies it. At volume, the owner’s job is not to review every output. It is to govern the design of the decision envelope: which decisions the agent handles autonomously, where the escalation threshold sits, and how the exception path is structured when a case falls outside what the rules anticipated. Those are consequential design choices, and they carry real accountability. An owner who has drawn that boundary with intention, who has thought carefully about what the system should handle alone and what it should surface, has discharged the obligation. One who set those parameters by convenience and then stepped back has not. The volume does not change who owns the call. It changes what owning it requires.
It is also the one thing a better stack can’t give you. IT has always joked that the real problem was never in the seven layers of the stack. Layer 8 was the user, the ID-10-T error, the fault between the keyboard and the chair. Layer 9 was the organization itself, the budget and the politics and the accountability, the part no tool ever fixed. AI just changes the cast. The agent now sits in layer 8, the seat the user used to hold, taking the actions. So the thing that has to govern it is layer 9, the same accountable human layer that always sat above the user. And layer 9 has never been a product. There is no product to buy for the person who owns the decision.
If that sounds like a soft organizational point next to the hard engineering of the stack, consider that the law is now reaching for exactly the same thing. When Colorado rewrote its AI statute this spring, it did not mandate another control. It defined, in the text of the law, what meaningful human review has to be: a designated individual with the authority to approve, modify, or override the decision, who is trained, who considers the actual evidence, and who, in the statute’s own words, does not default to the system output. A legislature, working independently of any vendor’s roadmap, wrote the named owner into law, because it arrived where the proof does. What makes an AI decision defensible is not the controls around it. It is the person accountable for it.
So the question to carry out of this is not whether your stack is good. Assume it is. Assume you bought well. The question is the one the stack cannot answer, and the one that surfaces the day an AI decision goes wrong: who owned the call. Not which layer failed. Who owned the call. In most organizations running AI today the honest answer is that no one did, that ownership diffused until it belonged to no one, and that the absence stays invisible right up until the moment it is the only thing anyone wants to know.
No one asks how many layers you bought after an AI decision goes wrong. They ask who owned the call. The work is making sure that question has a name attached to it before it is asked, not after.
Naming that owner is harder than buying another layer, and it is the work Fellowship Intelligence does with risk-sensitive organizations: defining who decides, who can override the system, and who answers when a decision is wrong. If your organization cannot name that person yet, it is worth a conversation.
On the limits of AI guardrails: Apostol Vassilev, a senior scientist at the National Institute of Standards and Technology (NIST), applied Gödel’s incompleteness theorems to AI guardrails and showed that no finite set of guardrails is universally robust against adversarial prompts; for any fixed rule set, a prompt that defeats it exists. Published by NIST and peer-reviewed in IEEE Security & Privacy.
On meaningful human review: Colorado Senate Bill 26-189, “Automated Decision-Making Technology,” signed into law May 14, 2026, repealing and replacing the 2024 Colorado AI Act (SB 24-205) and effective January 1, 2027. The quoted language is the act’s definition of “meaningful human review,” which requires a designated individual with the authority to approve, modify, or override a consequential decision, who is trained, considers the available evidence, and does not default to the system output. Colorado General Assembly.
https://web.archive.org/web/20260609152522/https://leg.colorado.gov/bills/sb26-189