The Enterprise AI Control Layer

Ask how an enterprise intends to keep an AI capability safe and the answer is usually a description of the model — a better one, a more carefully tuned one, a system prompt with the rules written into it very firmly. That answer has a structural problem. The model is the part of the design most likely to be replaced, least likely to behave identically twice, and completely unable to enforce anything. You can improve it and improve it and never arrive at safety, because safety was never a property of the model. It is a property of what the model is allowed to do.

That "allowed" is a thing. It has to live somewhere, be owned by someone, and be designed on purpose. In most AI architectures as they are actually described, it is not designed at all — it is scattered across prompt text, a few conditionals, and the assumption that whoever configured the credentials was thinking carefully that day.

The layer you already have

This will sound less new than it is. Almost every enterprise landscape already runs one. Nobody drew it as a box on the architecture diagram, but it is unmistakably there.

It is the release strategy on the payment run. The approval matrix that changes shape above a value threshold. The tolerance on a match, and what happens outside it. Dual control on a bank master data change. The authorisation model that decides whether a role can post at all, and to which company codes. The exception queue somebody works every morning. The report that reconciles what one system believes against what another one holds.

None of that is in the ERP because the ERP is clever. It is there because at some point someone acted alone, or twice, or on the wrong entity, and the organisation wrote down a rule so it would not happen again. Eighteen years in finance and treasury systems and I can tell you the shape of that layer without knowing your company: it is the accumulated scar tissue of everything that has ever gone wrong.

An AI capability arriving into that landscape does not get to skip it. It gets asked the same questions the layer asks everything else, and if the answers do not exist, the honest position is that the capability is not ready — which is the applied version of the argument that enterprise AI is an architecture problem before it is a model problem.

Three layers, not two

The design most teams reach for has two layers. Systems of record at the bottom, AI at the top, credentials in between. The AI reasons, the systems hold state, and the connection is whatever access someone provisioned during the pilot.

The design that survives contact with an audit has three:

• The systems of record hold state and remain authoritative. They are the only place anything is true.
• The AI or agent layer reasons. It interprets unstructured input, classifies, drafts, proposes, explains. It is good at exactly the things rules are bad at, and it holds no authority.
• The control layer sits between them and decides whether anything from the second is allowed to reach the first — in what form, under whose identity, within what limits, with whose approval, and with what left behind in the log.

The third layer exists in the two-layer design too. It has simply been implemented as a paragraph of prompt text and a broadly-scoped service account, which is a control layer in the same sense that a note on a door is a lock.

What the control layer owns

Four of those deserve more than a row.

Deterministic rules and thresholds. The strongest instinct to resist is letting the model do work that a rule already does correctly. If the calculation is defined, calculate it. If the policy says approval is required above a value, the control layer evaluates that comparison — it does not ask the model whether approval seems necessary. A model asked to apply a rule will usually apply it. "Usually" is not a control standard, and it is not a standard you can evidence to anyone. Give the model the work that is genuinely ambiguous, and give the rules the work that is genuinely rules.

Action limits. This is the control most often missing, because in a human process it was never needed. A person could only process so many items before going home. An agent has no such property. Limits on how many actions per run, how much cumulative value per window, and how many consecutive failures before it stops are not caution — they are the thing that turns a bad afternoon into a small bad afternoon.

The kill switch. It has to be operable by whoever is on call at the time, in seconds, without a release. Not a feature flag that requires a deployment, and not "we'll revoke the credential" if nobody on the rota knows how. A stop control that has never been tested is a plan, not a control.

Exception routing. Every capability meets input it should not act on. The design question is whether that produces a routed exception with the evidence attached and an owner, or a confident answer produced anyway. The second one is the failure mode worth designing against first, because it is silent — nothing errored, an output arrived, and the fact that the system was guessing is visible only in a log nobody read. This is the same output contract and failure-handling discipline applied at the boundary where actions become real.

An instruction is not a control

This is the sentence I would put above the whole architecture.

A control has two properties that prompt text cannot supply. It is enforced by something that cannot be persuaded, and it fails closed when it is unsure. Prompt text has neither. It is input to a probabilistic process, which means it can be outweighed by other input, reinterpreted under a case nobody anticipated, or quietly weakened when someone edits the prompt for an unrelated reason and does not realise a control was living in paragraph four.

There is also a testing argument, and I find it more persuasive than the philosophical one. You can write a test for a threshold. You can write a test for an authorisation. You cannot write a test for a sentence — only a sample, which tells you the model complied on the cases you tried.

"

A control that lives in a prompt is a control the model can be talked out of.

So write the rule in the prompt if it helps the model behave well. Then enforce it somewhere the model does not get a vote.

Enforce it twice, in two different places

Controls belong in the control layer and in the target system, because the two know different things.

The control layer knows intent and context. Which user asked. What the agent proposed and why. Which policy applies. Whether a threshold was crossed. Whether an approval exists and who gave it. It can stop an action early, explain the refusal in business terms, and route it somewhere useful.

The target system knows none of that, and it is still the more important gate — because it is the last one before state changes, and it holds whether or not your control layer was reached. If someone connects a second client to the same credential, calls the interface directly, or misconfigures a route during a busy release, the target system's own authorisation model is the only thing still standing.

That is not redundancy for its own sake. It is the reason a scope defined in the control layer must also exist as a real, narrow authorisation in the system being written to, which is exactly the question that where an agent sits relative to your existing systems forces you to answer.

The division of labour

Underneath all of this is one principle, and it is worth stating plainly because every decision above is an application of it.

Models reason. Rules constrain. Systems hold state. Humans own consequential decisions. The workflow-level version of that split is the anatomy of an AI-native workflow.

Most trouble in AI designs comes from moving a responsibility across one of those boundaries. A model asked to constrain — to be its own guardrail. A rule engine asked to interpret an ambiguous email. State held in a conversation instead of a system, so nobody can query it or reconcile it. And, most expensively, a consequential decision handed to a component that cannot be accountable for it, which is really a decision about automation, augmentation and autonomy taken by default rather than on purpose.

The control layer is where that division is made concrete. It is the component that keeps the model in the reasoning business.

Designing it on purpose

A few things I would hold to when building one.

Make it a real component with an owner, not a set of habits distributed across whoever wrote each integration. If the answer to "where is the approval requirement enforced" is three different files, it is not a layer.

Give actions one choke point. Every write, every external side effect, every irreversible thing goes through the same place. Convenience shortcuts around the layer are how it stops being one, and they are always added for a good reason at the time.

Version it like configuration and test it like code. Thresholds change, policies change, scopes change — and each of those is a functional change that someone should be able to find later.

Log at the grain of a single action, not the grain of a dashboard. Aggregates cannot answer the only question that ever actually gets asked, which is about one specific record on one specific day. Done properly, this is also the raw material for production observability, and the two are cheaper to build together than separately.

And make identity the first decision rather than the last, because almost every other control in the layer resolves to it — which is why what the agent is acting as deserves a design conversation of its own.

What I would decide

Stop trying to buy safety in the model and build the layer that owns it. Name the three layers explicitly so the middle one exists on the diagram rather than in the prompt. Put identity, permissions, deterministic rules, thresholds, approvals, segregation of duties, validation, limits, logging, a stop control and an exception route in it, and for each one, be able to say what breaks if it is missing. Enforce twice — once where you know why, once where it counts. Never let a control live only in prompt text. And keep the model doing the thing it is genuinely good at, which is reasoning about ambiguity, not policing itself.

None of this is new. That is rather the point: the enterprise worked out how to constrain powerful, fallible actors long before it had this one, and the answer is not a better actor. It is a layer.

See also agent identity: who is the AI acting as? and why enterprise AI is an architecture problem.