A tenant boundary diagram with the rule engine, Azure OpenAI, and an MCP endpoint inside it

If you are the person who has to sign off on where the data goes, “we use AI” is not an answer. You need to know which subscription the compute runs in, which resource the model call lands on, who holds the keys, and what an external client can reach.

This post lays out how AI Rule Engine answers those questions when you run it on dedicated hosting, and what changes when you let AI agents talk to it over the Model Context Protocol.

Draw the boundary first

Dedicated hosting deploys AI Rule Engine into your own Azure subscription rather than shared infrastructure. Compute, data, network, and keys are yours. Your rules, run history, execution logs, and stored files live in resources you own, under your own networking and identity controls, covered by the same compliance posture as the rest of your Azure footprint.

Then point the AI steps at your own Azure OpenAI resource in the same subscription. Native Azure OpenAI support means you select your own deployment rather than routing prompts through a third party. There is no vendor hop for the model call and nobody else holding your prompts or completions.

The result is worth stating plainly, because it is the part an architect gets asked to defend: the decision logic, the data it reads, and the model call it makes are all inside your tenant. Not “encrypted in transit to us.” Inside.

Dedicated environments are also not metered per run and have no minimum interval between scheduled runs, since they are running on your own resources. Capacity planning is a conversation with your own subscription, not with a pricing page.

The determinism argument, briefly

There is an architectural reason to put a rule engine between your AI and your business decisions, separate from where it runs.

A language model is a probabilistic component. Pricing, eligibility, limits, and approvals are not: they are policy, and policy has to produce the same answer twice and explain itself afterward. AI Rule Engine keeps those two responsibilities apart. The model handles the language work: reading a document, classifying a request, drafting a summary. The rules make the decision, in a decision table your risk and compliance people can actually read, with a firing-by-firing trace of why each outcome happened, versioned and auditable, with human approval where you require it.

That separation is what makes the AI usable in a regulated process at all. We wrote it up in more depth in Your AI Agent Shouldn’t Guess Your Business Rules.

Now let agents in, on your terms

An AI Rule Engine environment can act as an MCP server, so an MCP-capable client such as Claude, Cursor, or VS Code connects to your environment and calls your RuleSets as tools. On dedicated hosting that endpoint is in your subscription, behind your own network and identity controls, like every other service you run.

What matters architecturally is how narrow you can make the grant.

Off by default. The MCP server stays off until an administrator turns it on for the environment.
The token is the boundary. A connection token can run every RuleSet in the organization, or only an explicit allow-list. Each allowed RuleSet becomes exactly one callable tool with a declared input and output shape, so an agent invokes a governed decision instead of roaming your data.
Resource access is granted separately, per kind, per level. Stored files, run context files, log entries, and log attachments each get no access, read only, or read and write. Storage access can be pinned to a single folder prefix.
Writes stay inside the same walls. A write grant is still confined to the token’s allowed RuleSets, its folder prefix, and its environment.
Tokens expire and revoke. Set an expiry when you create one; deleting a token cuts off any client using it immediately.
Interactive clients go through consent. A client connecting over OAuth sends the user to a consent screen where the connection and its scope are approved, and connected apps can be reviewed and revoked later.

Agents can also run a RuleSet’s test suite, which is what lets an assistant close its own loop: propose a rule change, run the tests, read the failures, fix, repeat, without anyone handing it production access.

The honest caveat about agents

Here is the part to take to your security review rather than around it.

Everything above keeps execution inside your boundary. An external AI client is still an external AI client. Whatever a tool returns to it, that client’s own model provider processes. Putting the engine in your tenant does not change that, and no vendor diagram should imply otherwise.

What it does change is how much you have to trust the agent, because you decide exactly what the tool returns. Design each MCP-exposed RuleSet as an interface rather than a window: return the decision and the reason, not the record. Grant read access to the folder the agent needs, not the container. Give a tool per task, and a token per client. Then an agent’s compromise is bounded by a scope you wrote down, and the sensitive material never enters the prompt in the first place.

A pattern that survives review

Put together, the shape is:

Dedicated hosting in your subscription, so the engine, its data, and its logs never leave your tenant.
Azure OpenAI in the same subscription for the language work, with no third-party hop.
Rules as the decision layer, deterministic, versioned, traced, with approvals where policy demands them.
MCP, scoped per client, so agents call the decisions you chose to expose and see only what those tools return.

Each layer is separately auditable, which is usually the real requirement behind “is this AI thing safe.”

Talk to us about dedicated hosting on the Enterprise page, or visit RuleEngine.ai to try it.

The AI Rule Engine Team