Contain the Model

1. Executive Summary

For years, enterprise AI governance meant trusting the model and checking its work afterward. That assumption is ending. In October 2026, Microsoft's chief executive publicly urged the industry to treat AI models as insider risks — to assume they are compromised, contain them from the start, and separate the supply of intelligence from the authority over it.

For enterprises automating real business processes, the practical question is no longer whether to contain AI, but what contains it. This paper argues that the strongest answer already exists: a mature, deterministic rules engine that sits between the model and everything it touches. The model recommends. The rules engine decides what actually happens — and records it.

appRules was built this way. Its rules engine has been running enterprise processes in production for more than a decade, and AI was added inside it — not the other way around.

2. The Industry Says It Out Loud

On October 10, 2026, Microsoft CEO Satya Nadella published an article on X, Models as Insider Risks in the Super Intelligence Era. His starting point is blunt: unlike traditional software, today's models can't be traced to a specific code path — yet enterprises are giving them access to sensitive data and the ability to take mission-critical actions. His answer is containment:

He describes an emergency brake that lets any authorized person pause or shut down a model mid-task, and sets out principles for the systems around models: model diversity, observing everything through tamper-proof, human-readable evidence, continuous verification, independent controls, independent auditability, and incident disclosure. He also makes clear that responsibility can't be outsourced — a model provider's assurances do not relieve the organizations deploying it.

A day earlier, Microsoft President Brad Smith made a similar point in plainer terms, warning that AI today is “less regulated than a carton of milk.”

When the leaders of one of the world's largest technology companies say this publicly, enterprises should take it as a design requirement — not a debate.

3. Separate the Model From What Governs It

The most important idea in Nadella's article is architectural, and he states it in a single sentence:

He is explicit that the controls governing what a model can access and what actions it can take must sit outside the model. If the same model that produces an answer also decides what to do with it, there is nothing to contain it — a compromised or mistaken model simply acts.

This is precisely the appRules architecture. The model supplies the intelligence; the rules engine holds the authority. In appRules, an AI response never acts on its own. It flows into Conditions, Decision Tables, and validated Actions — business rules that a human can read, test, and sign off on — and only those rules change data in enterprise systems.

4. Contain What the Model Sees and Says

Containment doesn't begin when a model acts. It begins with what the model is given. Nadella points to the practices enterprises already use for powerful insiders — establishing identity, limiting privileges, logging activity, and drawing containment boundaries. For an AI model, limiting privileges starts with limiting what it can see.

In appRules, every prompt is built in the SmartPrompt Builder, and the context a model receives is chosen deliberately. The Context Picker lets builders select the specific context variables a prompt draws on — the fields and values from real, governed data sources that the task requires, and nothing more. The model never gets open-ended access to enterprise data; it gets exactly the context the workflow hands it.

The SmartPrompt Builder contains what the model says, too. Its prompt and context engines give a model a specific, deterministic role — such as a condition evaluation engine that returns only a clean true or false — so the model's output is a narrow, checkable answer that the rules engine can act on, not open-ended text it must interpret. And with Partial Preview, the fully merged prompt and context can be inspected before any AI call is made: the evidence of what the model will see exists before the model sees it.

5. Why a Mature Rules Engine

Nadella's article doesn't call for a new kind of magic. It calls for an engineering approach: wrapping unpredictable models in deterministic system design, human oversight, and dependable operating procedures — with industry standards wherever today's fall short.

He also points out that this isn't new territory. Enterprises have spent decades refining how to contain powerful actors inside the organization, and he grounds the need for external controls in an information-security principle dating back to the 1970s. Strong, deterministic system design around a non-deterministic model is exactly what an enterprise rules engine is.

A containment layer invented alongside the AI it governs inherits the AI's immaturity. A mature rules engine brings years of hardening to the problem from day one.

6. The Containment Principles, Mapped

Each of the principles in Nadella's article maps to a capability appRules provides today.

Principle	How appRules Delivers It
Separate the supply of intelligence from the authority over it	The rules engine, not the model, decides what happens. AI output passes through deterministic Conditions, Decision Tables, validated Actions, and post-conditions before anything changes. AI advises; appRules acts.
Containment	An emergency brake: an authorized person can pause or stop a running workflow mid-task from the Admin Center — including scheduled workflows.
Model diversity	Model Cross-Validation runs multiple models, and rule-based Result Selection Options and Deadlock Resolution — not another model — decide what their combined results mean.
Observe everything	Tamper-proof logs capture every run — activities, data source operations, AI model calls, condition results, and actions — alongside AI reasoning notes and readable Action Chain tables.
Verifiability	Every property is validated as it's configured, Validate Workflow checks the entire workflow on demand, every run is validated before it starts, and Partial and Full Preview test prompts and responses before production.
Independent controls	What a model sees is defined by the SmartPrompt Builder's Context Picker, and what a workflow can do is defined by its Conditions and Actions — all outside the model. Sensitive records are locked with the Secure button.
Independent auditability	The evidence comes from the platform, not the model: deterministic rules evaluate each step, and tamper-proof logs record the outcome independently of the intelligence being validated.

7. Cross-Validation, Governed by Rules

Running several models on the same decision is one of the most effective ways to avoid depending on a single model, and Nadella encourages using models to test and verify each other. But he also warns where that can lead: an opaque model inside an opaque orchestration layer, watched by another opaque model — nested black boxes. His prescription is model diversity — no single model as the only basis for an important outcome, and no model checking its own work — with the controls sitting outside the models.

appRules addresses this directly. In Model Cross-Validation, no model judges another model. A deterministic rule decides what their combined results mean. Builders choose the rule in advance:

• Return the most common model result — majority agreement
• Accept the result only if all model results are the same — unanimity for the most critical decisions
• Accept the result if at least one cross-validation model matches the primary — confirmation of a primary model
• Execute a custom activity — for example, routing the decision down a different path or to human review instead of guessing
• Proceed to the next workflow activity

And when models cannot agree, Deadlock Resolution defines in advance what happens next — so disagreement becomes a governed outcome, not an AI's judgment call:

• Return the primary AI provider model result — defer to a designated primary model
• Return Invalid (False) as the workflow activity execution result — a fail-safe: when the models can't agree, nothing proceeds as if they had
• Return a specific value — a predetermined, known-safe default
• Execute a custom activity — for example, escalation to human review
• Proceed to the next workflow activity

The fail-safe option matters most for containment. A compromised or mistaken model can't win a disagreement by default — the rules engine can be set to treat any unresolved split as invalid, exactly as a conservative human reviewer would.

8. GuardRailed Automation: Containment by Design

Containment works best when it is designed in, not bolted on. appRules governs AI across the whole lifecycle of every automation:

Two companion papers explore these layers in depth: GuardRailed Design for AI Workflows and GuardRailing AI.

9. Conclusion

Nadella closes his article with a line every enterprise architect should keep in mind:

For enterprise automation, that is not a research agenda — it is an architecture. Separate the supply of intelligence from the authority over it. Let a mature, deterministic rules engine decide what happens. Give authorized people the power to stop any run. Record every decision in tamper-proof logs. appRules has delivered that architecture for more than a decade — and brought AI inside it.