Security and Data Handling

Where we stand, stated plainly

AI Rule Engine is built by a small team. We do not hold a SOC 2 attestation, we do not yet offer a DPA or a BAA, and the product has not had an independent third-party penetration test. Some vendors leave those facts to be discovered in the questionnaire. We would rather you know now.

What we do have is an architecture that makes the usual answer unnecessary for the deployments where it matters most. On a dedicated host the entire runtime lives inside your own Azure subscription, through an Azure Marketplace managed application. Every production run, its inputs and outputs, its trace, its logs, its uploaded files, and its AI prompts stay there. Paired with Azure OpenAI the model calls stay in your tenant too. The compliance boundary is one you already own and already assess.

Two things are ours whichever way you deploy, and we would rather name them here than have you find them later. The first is authoring: your rules, their version history, your user accounts, and the audit trail live in our control plane by design. The second is test data, which is the item on this page most likely to matter to you and least likely to be guessed.

If a current SOC 2 report or a signed BAA is a hard gate for you today, we are not a fit yet, and we will tell you that on the first call rather than the fifth.

Where your data lives

Two deployment shapes, and the difference matters more than any other line on this page.

Dedicated host, in your Azure subscription: Included with Enterprise for up to three environments. The Azure Marketplace managed application deploys the runtime, its database, storage account, key vault, and message queue into a subscription you own. Everything a run touches stays there: execution history, run traces, run logs, uploaded files, storage-action output, human approval forms, and the AI prompts and completions themselves. None of it transits our infrastructure. The boundary is one your existing controls already cover.
The control plane is ours on every tier: Authoring lives in our control plane whichever way you deploy: your projects, rulesets and their version history, conditions, action sets, releases, user accounts, and the audit trail. That is the design, not an oversight. Read the boundary table below before your review, because one item in it surprises people.
Shared host, operated by us: The default on Free, Pro, and Team. Runs on Microsoft Azure in our subscription, with each organization and environment isolated at the data layer. On this shape both the runtime and the control plane are ours, so the boundary table below describes what we hold rather than what we hold in addition.
Region: The shared host runs in a single Azure region. A control plane in a specific region is available as a Data Residency arrangement rather than a self-serve setting, so ask before assuming a region requirement is met.

Tenant isolation

Isolation is enforced on the request path, not by convention in query code.

Organization and environment scoping: Every request resolves an organization and environment from the caller credential before any handler runs, and data access is scoped to it. A credential issued for one environment cannot read another.
Per-environment credentials: Application API keys and MCP tokens are bound to a single environment and to the rulesets they are allowed to run. A key is not a general-purpose account.
Named human approval: A run that pauses for human review can only be opened by someone signed in and holding the organization and environment that raised it. The approver is recorded on the resulting decision, so an approval can be attributed afterwards rather than only counted.
Scoped agent access: Each MCP token carries its own access level for rulesets, stored files, and log entries, from none through read to read-write. An AI agent gets exactly the surface you granted it and nothing else.

Identity and access

Single sign-on, directory-driven provisioning, and organization-level access policy. SSO, IP allowlisting, and custom roles are Enterprise features; the session and credential policy starts on Pro.

SSO over OIDC and SAML 2.0: Per-organization identity providers with full id_token validation on the OIDC path and signed-assertion validation on the SAML path. Identity-provider-initiated login is opt-in rather than on by default.
Verified domain capture and enforced SSO: Claim a domain by DNS verification, then require every user on it to sign in through your provider. Sign-in discovery returns the same shape for known and unknown addresses, so it cannot be used to enumerate accounts.
SCIM 2.0 provisioning: Entra ID and Okta push users and groups directly, with group-to-role mapping and deprovisioning. The plan entitlement is re-checked on every SCIM request, because a directory sync keeps running long after a plan changes.
MFA enforcement that fails closed: When an organization requires MFA, a provider that does not assert it is refused rather than assumed compliant. That deliberately rejects consumer Google sign-in, which carries no such claim. SSO logins inherit whatever your own provider enforces.
Session and credential limits: Idle timeout in minutes, a maximum session lifetime in days (14 by default), and a cap on how long an API key or MCP token may be issued for. With a cap set, a credential created without an expiry is refused.
IP allowlist: Literal addresses or CIDR ranges permitted to reach an organization. Evaluated against the forwarded client address, so we treat it as defence in depth on top of authentication rather than as a control that stands on its own.
Custom roles and access review: Define roles against the permission set rather than choosing from fixed tiers, and run a periodic review of who holds what. The organization owner cannot be locked out by either.

Audit and evidence

Two separate records: what people did to the system, and what the system decided. Both are designed to be read long after the fact.

Append-only audit trail: Administrative and security-relevant events are written to a container that is appended to and never edited, capturing the actor and the originating address. Available from Team; retention is unlimited on Enterprise and capped by plan below it, and deliberately kept separate from run-log retention so shortening operational logs never shortens the audit trail.
Export and SIEM streaming: Enterprise can export the trail as CSV or JSON, and stream events to an HTTPS sink as they happen. Streaming runs off the Cosmos change feed, entirely off the request path, so a slow sink cannot slow down the operation being audited. Delivery is at-least-once: treat the event id as an idempotency key.
Inference traces on runs: A run can record every rule that fired, in what order, and the values each condition matched on, plus every change it made to the context. This is what makes a decision explainable rather than merely logged.
Signed release evidence: Each publish produces an evidence record signed with RSA-SHA256 using the same key published at the application JWKS endpoint. Anyone holding the public key can verify that the logic in force on a given date has not been altered since, without trusting us to assert it.
Compliance Archive: An Enterprise add-on that writes a retained archive and exports it on a schedule to a storage account you own, with a manual trigger so an administrator can prove the destination works before relying on it.

Data protection and secrets

Standard Azure platform protections, plus how credentials are held.

Encryption: Data is encrypted in transit over TLS and at rest by the underlying Azure services (Cosmos DB and Azure Storage encrypt at rest by default). Audit sink credentials are additionally encrypted with AES-GCM before storage.
Secrets handling: Platform secrets are held in Azure Key Vault and referenced rather than stored in application configuration.
Your AI provider keys: You bring your own keys for Anthropic, OpenAI, Azure OpenAI, Google, and xAI. Model calls bill to your provider account under your own terms with that provider, and you can revoke a key without involving us.
Outbound request guarding: Customer-configured destinations, including audit sinks, are checked against server-side request forgery before they are called.

Availability and recovery

What exists for getting back to a known-good state.

Tenant backup and restore: Download a whole-tenant backup on demand, configure where a scheduled backup is written, and restore from one. Enterprise feature.
Version history: Rulesets, conditions, and action sets keep version history, so reverting a single rule does not require a tenant restore. Depth is capped by plan and uncapped on Enterprise.
Deployment pipelines: Promote a tested release between environments rather than editing production directly, with releases retained per plan for rollback.

AI providers and what is sent to them

Worth being precise about, because this is usually the question behind the question.

Only what a rule sends: A model is called only where a rule action calls one. Rules that use no AI action send nothing to any provider. The deterministic parts of a decision never involve a model.
Keeping model calls inside your boundary: On a dedicated host paired with Azure OpenAI, prompts and completions stay within your own Azure tenant end to end.
Provider terms are yours: Because you supply the provider keys, the data handling and training terms that apply are the ones between you and that provider.

What we hold, and what stays with you

On a dedicated deployment, the split below is exact. On a shared host both columns are ours, so read this as the list of categories rather than a boundary.

Which data stays in your Azure tenant and which lives in the AI Rule Engine control plane
Data	Where it lives	Notes
Run inputs, outputs, and execution history	Your tenant	Every production run, its context, and its result.
Inference traces and run logs	Your tenant	The rule-by-rule reasoning behind each production decision.
Uploaded files and storage-action output	Your tenant	Written to the storage account in your own subscription.
Human approval forms and their responses	Your tenant	Including whatever decision context the form carries.
AI prompts and completions	Your tenant	Sent from your environment to the provider you configured, using your key.
Your AI provider keys and MCP tokens	Your tenant	Held in your environment, revocable by you without involving us.
Environment settings and variables	Your tenant	Configuration your rules read at run time.
Projects, rulesets, conditions, action sets, and version history	Our control plane	The logic itself, and every prior published version of it.
Test cases and stored test runs	Our control plane	This is the exception worth knowing. A test case stores the input context you gave it, and a stored run keeps the assertion values, log tail, and inference trace from executing it. If someone authors a test from a real record, that record and the reasoning over it are held by us, on every tier. See the note below.
User accounts, roles, and SSO or SCIM configuration	Our control plane	Identity and access, including directory-provisioned users.
Audit trail and signed release evidence	Our control plane	Deliberately outside the tenant so it survives a tenant being torn down.
Billing, usage counts, and support correspondence	Our control plane	Run counts and seat counts, not run contents.

About test data, specifically

Test cases and stored test runs live in our control plane on every tier, including dedicated. A test case holds the input context it was written with. A stored run holds the assertion values, the log tail, and the full inference trace from executing it, because that is what makes a failing test diagnosable.

That is fine for synthetic data and not fine for a real record. The way people write tests is to copy the case that broke, so this is a live risk rather than a theoretical one. Until test storage moves into the tenant environment, treat test cases as data you are handing to us, and use de-identified or synthetic inputs. If that constraint does not work for you, tell us, because it moves the fix up our list.

Subprocessors

Third parties in the path of the hosted service. Your own AI providers are not listed: you supply those keys and contract with those providers directly. On a dedicated deployment, the hosting, database, and storage rows are your own Azure subscription rather than ours.

Subprocessors used by the hosted AI Rule Engine service
Provider	Purpose
Microsoft Azure	Hosting, database, storage, messaging, and key management
Microsoft Entra ID	Optional sign-in with a Microsoft work or personal account
Google	Optional sign-in with a Google account
LinkedIn	Optional sign-in with a LinkedIn account
Stripe	Subscription billing and payment processing
Anthropic	Platform authoring features such as template and project generation
hCaptcha	Bot protection on public forms

This marketing site

Third parties used by the ruleengine.ai marketing site
Provider	Purpose
Google Analytics	Aggregate traffic measurement on this marketing site, off unless you allow it
Calendly	Scheduling on the consultation page
hCaptcha	Bot protection on contact forms

The questions your reviewer will ask

Do you have SOC 2?

No. AI Rule Engine does not hold a SOC 2 attestation today and we will not imply otherwise. If a current SOC 2 report is a hard requirement for your review, we are not a fit yet.

Will you sign a DPA or a BAA?

Not today. We do not yet offer a Data Processing Agreement or a Business Associate Agreement. For regulated data the honest path is a dedicated deployment in your own Azure subscription, where the data stays inside a boundary your existing agreements already cover.

Does any of our data reach your infrastructure on a dedicated deployment?

Production runs do not: inputs, outputs, traces, logs, uploaded files, and AI prompts all stay in your subscription. Authoring does, by design: rules, version history, user accounts, and the audit trail live in our control plane. So do test cases and stored test runs, which keep the input context, the assertion values, the log tail, and the inference trace. That last one is the exception people do not expect, so use de-identified or synthetic data in test cases.

Can our data stay in our own cloud?

Yes, on a dedicated host. Enterprise includes up to three environments deployed into your own Azure subscription through an Azure Marketplace managed application. Rule data, execution history, uploaded files, and prompts stay in your tenant, and paired with Azure OpenAI the model calls do too.

How do we get our data out?

Whole-tenant backup download and restore, scheduled backup to a storage account you own, audit export as CSV or JSON, and the Compliance Archive add-on for scheduled export to your own storage. There is no export you have to ask us to run for you.

Has the product had a penetration test?

Not an independent third-party test. We are not going to describe internal review as something it is not. You are welcome to test a dedicated deployment in your own subscription under your own program.

How do we report a vulnerability?

Email security@ruleengine.ai with the detail needed to reproduce it. We will confirm receipt and keep you updated through remediation, and we will not take action against anyone reporting in good faith.

Reporting a vulnerability

Email security@ruleengine.ai with enough detail to reproduce the issue. We will confirm receipt, keep you updated through remediation, and we will not pursue action against anyone who reports in good faith and does not access other customers' data.

Please do not test the shared host against other tenants. If you want to test the product itself, ask us and we will point you at a dedicated deployment you can run in your own subscription.

Still have questions before a demo?

Send the questionnaire. We will answer it as written, including the rows where the answer is no.