For Chief Technology Officer
Enforcement at the decision boundary.
OBEXGATE operates inside the decision loop, not alongside it. Every governed action is evaluated before it executes. The architecture is non-bypassable, the verdict is auditable, and the deployment topology fits the environment you already run.
If it is not in the execution path, it is not control.
Not outside the stack. Inside the execution path.
Observer Mode shows how your system behaves
Enforce Mode blocks actions before execution
If an action violates policy, it does not run
Where it sits
Inside the decision loop, not bolted to the side.
The category failure mode is control outside the execution path: dashboards, attestations, and log review that see the problem after the system has already acted. OBEXGATE sits before commit authority, where the decision can still be stopped.
Most AI governance products observe. They tail logs, score outputs, and surface incidents after they occur. OBEXGATE evaluates before the action commits. The verdict is the gate. If the action does not meet requirements, it does not execute.
This is enforced through topology, not configuration: a non-bypassable execution boundary, runtime-owned commit authority, and no state mutation outside the verification gate.
Operational difference. Without enforcement: violations are logged after execution. With enforcement: actions are evaluated before execution, violations are prevented, and evidence is produced as a side effect.
Issued by: Information Commissioner's Office (ICO)
What it does in production
Eight things, running continuously.
→ Discovery
Identifies registered systems, unregistered agents, embedded AI, and unmanaged workflows.
→ Admission
Validates structural requirements, policy alignment, and operational readiness before a system is allowed to operate under governance.
→ Evaluation
Applies regulatory frameworks, internal policy, and control logic to every action.
→ Enforcement
Blocks non-compliant actions before execution.
→ Decision trace
Records what was evaluated, which frameworks applied, and why the verdict was returned.
→ Continuous monitoring
Tracks behaviour, system state, and compliance alignment.
→ Drift detection
Identifies drift, inconsistencies, and policy gaps.
→ Decommissioning
Performs structured teardown with sealed audit records.
Deployment topology
Same enforcement. Different environments.
Deployment is driven by governance context, not technical preference. The evaluation layer remains consistent across deployment modes.
| Mode | Where it runs | What you control |
|---|---|---|
| SaaS multi-tenant | OBEXGATE-hosted, shared infrastructure | Configuration, governed actions, audit access |
| SaaS dedicated | OBEXGATE-hosted, single-tenant | Tenant isolation, custom rules, dedicated support |
| SDK / library mode | Embedded inside your application stack | Full integration control, in-process enforcement |
| Partner cloud | Your AWS, Azure, or GCP account | Infrastructure, network policy, key management |
| Federated | Distributed across business units or regions | Local data residency, central policy authority |
| On-prem | Your data centre, your LLM | Full air-gap option, no external dependency |
| Sovereign cloud | Jurisdiction-bound deployment | Controlled encryption, in-region processing |
Adoption
Observer Mode first. Enforcement when ready.
Observer Mode evaluates every action and produces the verdict without blocking. Same evaluation engine. Different verdict treatment.
When the team is ready, enforcement activates without redeploy.
See where it would sit in your environment.
Six questions. Personalised regulatory map, cost basis, statutory exposure. Or schedule 30 minutes with someone who has architected this before.