Ask a vendor how their product stops employees sending confidential material to an unapproved AI model, and you will often be shown a settings page. An administrator unticks a model, or turns on a data-protection option, and the option disappears from the employee’s screen. The demonstration is convincing. It is also, very often, a description of the interface rather than of a control.
The distinction matters most in regulated work, where the question is not whether a rule exists but whether the organisation can show that it held. This article sets out why a rule enforced only in the interface does not hold, what it takes for it to hold, and the questions that separate the two.
The interface is the least trustworthy place to enforce a rule
An interface is the part of a system that is closest to the user and furthest from the organisation’s authority. It runs on machines the governance team does not watch, it is updated on its own schedule, and it is designed to be convenient. Those are good properties for a workspace and poor properties for an enforcement point.
Consider three ordinary situations.
- A stale client. An administrator disables a model this morning. A laptop that has been asleep since last week wakes up with last week’s configuration. If the only thing standing between the employee and the disabled model is the list of options the client shows, the employee can still use it until the client refreshes.
- A modified client. Anyone who can alter the application, or call the same backend without it, is not bound by rules the application enforces on itself. That includes curious power users, well-meaning scripts and, in the worst case, malicious software on the device.
- A second path. Plugins, tools and agents often reach models and services through routes the main interface does not mediate. A rule applied to the chat window says nothing about the document summariser that calls the same provider directly.
None of these requires bad intent. They are the normal texture of software in a real organisation. A control that fails in any of them is a convenience, not a control.
What it means for a rule to hold
For a rule about AI use to hold, it has to be applied at a point that every relevant request must cross, by a component that does not depend on the goodwill of the thing it governs. Three properties follow.
One boundary, crossed by everything that matters
If some requests can reach a model without passing the enforcement point, the enforcement point is advisory. The boundary has to cover chat, document tools, agents and plugins alike: every model and tool request that the product controls. Anything outside that boundary should be described honestly as outside it.
Separation from the interface
The component that enforces policy should be separate from the component that presents choices to the user. The interface can still hide a disabled model, and it should, because that is a better experience. But hiding is a courtesy. Refusal happens elsewhere, and it happens even if the interface is outdated, altered or wrong.
Checks on what actually leaves
It is not enough to check what the user typed. Between the prompt and the outgoing request there are often attached documents, retrieved passages, system instructions and tool arguments. The only reliable check is on the final payload, assembled and ready to send. If protection, such as replacing sensitive values with tokens, is applied along the way, the payload should be checked again afterwards, because the check that matters is the last one.
Local enforcement, central policy
Where should that enforcement point live? One option is a central proxy that all traffic passes through. That can work, but it means sending the organisation’s working content to the proxy, which is itself a new concentration of sensitive material and a new dependency.
Synainesi takes a different approach. Its design separates the place where policy is decided from the place where it is enforced. Policy is defined centrally, in Cloud Admin, so that there is one authoritative statement of which providers, models, tools and actions are allowed. It is enforced locally, by Guard, a separate runtime on the employee’s device that every Synainesi-controlled model and tool request must cross. The design rule is stated plainly: a provider or model disabled by organisation policy must be refused by Guard even if a stale or compromised client attempts to use it.
Keeping enforcement on the device has a second benefit. The organisation can govern AI use without routing everyone’s work through a central service, because the decision is made next to the content and only evidence about the decision needs to travel.
Local enforcement has limits too
Moving enforcement onto the device does not make it magic. A local runtime can only govern the requests that pass through it; it does not stop someone opening a browser and pasting text into an unrelated service. It needs up-to-date policy, which raises the question of what it should do when it cannot reach the policy source. And it has to be protected from the software around it. These are design problems to be solved explicitly, with defined behaviour when policy is stale or unavailable, rather than reasons to fall back on the interface.
The honest position is a scoped one: within the boundary a product controls, rules should be enforced somewhere the interface cannot switch off; outside that boundary, the product should not claim control at all.
Questions that separate controls from settings
- If I disable a model now, what stops a client that has not refreshed? The answer should name a component other than the client.
- Do plugins, tools and agents cross the same enforcement point as chat? If not, which do not?
- Is the check made on the final outgoing payload? Or only on the text the user entered?
- What happens when the enforcement point cannot get current policy? Is that behaviour defined and documented?
- What is outside the boundary? A trustworthy answer includes limits.
A settings page is where a rule is expressed. A control is where it is kept. In regulated work, it is the second one that has to be shown.
Related: the principles behind Synainesi, and why agents need permissions rather than trust.