Skip to content
How it works

One gateway, in front of every provider.

A request enters, is authenticated, judged against policy, and either forwarded or refused — then written to a tamper-evident record. Here is exactly where each decision happens, and how the gateway lands in your infrastructure.

Your apps & agents
MCP-based agents
↓
AssuranceOps Gateway
01 Authenticate → 02 Enforce policy → 03 Route → 04 Audit
reads policy from config / YAML writes to the audit trail — JSONL · Postgres
↓
Allowed
forwarded unmodified
Denied
blocked before a token is spent
↓
allowed requests continue to
OpenAI · Anthropic · MCP servers
01

Authenticate

Clients hold virtual keys. Real provider credentials never leave the gateway.

02

Enforce policy

Providers, models, tools, MCP servers, input size, and budgets are evaluated per request.

03

Forward or block

Allowed requests pass through unmodified. Denied requests fail before a token is spent.

04

Audit

Every request is written to an immutable trail, priced, and attributed by activity.

How a request is judged

Every request runs the same ordered gates. Deny always wins, and each allow-list is default-deny — anything not explicitly permitted is rejected.

Authenticated request
↓ pass
01 Provider On the approved provider allow-list? deny → 403
↓ pass
02 Model Permitted for this caller and route? deny → 403
↓ pass
03 Tools & MCP Requested tools and MCP servers allowed? deny → 403
↓ pass
04 Limits Within input-size and budget caps? deny → 403
↓ pass
05 Data PII / PHI policy satisfied for this route? deny → 403
↓ all gates pass
Allowed — forwarded unmodified, then written to the audit trail.

Self-hosted by design

The gateway, policy, and audit trail run inside your infrastructure. Provider credentials never reach clients, and request content is sent only to the provider or MCP server that policy approved.

Your infrastructure
AssuranceOps Gateway
Policy
config · YAML
Audit trail
JSONL · Postgres
↓
only approved traffic leaves · credentials never do
Model providers · MCP servers

Adopting the gateway

Three steps stand between a pilot and production — none of them is an application rewrite.

01

Deploy in your infrastructure

The gateway is a single static binary with a Docker Compose quick start. For production, the shipped Helm chart runs it highly available on Kubernetes — budget and rate-limit counters are shared across replicas through Postgres, and separate liveness and readiness probes keep rolling updates safe.

02

Point your applications at it

Clients keep calling the standard OpenAI and Anthropic API paths. Adoption is a base-URL change plus a virtual key — no SDK swap, no application rewrite, and streaming responses pass straight through.

03

Bind teams to policy

Each client key or directory group maps to a named policy — or starts from a shipped compliance pack. Policy is plain YAML with secrets referenced by environment variable, so it is reviewable, versionable, and safe to commit.

The guarantees behind the diagram

The properties security and platform leaders ask about first — each one is architectural, not a configuration flag someone can forget.

Credentials never reach clients

Real provider keys are referenced by environment variable, resolved at startup, and injected only at the moment a request is forwarded. The config file never contains a secret, and clients only ever hold revocable virtual keys.

Access is managed in your directory

Users authenticate with JWTs from Entra ID, Okta, Google Workspace, or ADFS. Directory groups map to policies — fail closed — and every audit record carries the actual user, not just a key. Service accounts keep virtual keys.

Fail closed is the architecture

Anything the gateway cannot authenticate, parse, route, or that policy does not explicitly permit is rejected before a token is spent. An unknown policy is a deny, not an error.

The record is complete, wherever a request stops

Allowed, denied, over budget, or rejected at the front door — every terminal path writes exactly one audit record. There is no code path that skips the trail.

Endpoint assurance

A signed control loop for every managed endpoint.

Governance does not stop at the gateway. AssuranceOps brings the same fail-closed discipline to pilot endpoint releases: exact signed artifacts, bounded delivery, anti-rollback checks, health-gated rollout, and evidence that follows the update.

Managed endpoints moving through controlled rollout rings with health and rollback signals.
Signed artifacts move through bounded rollout rings; health earns promotion, while rollback remains an explicit evidence-bearing outcome.
  1. 01

    Sign and pin the release

    A closed release manifest binds the exact version, payload, and updater identity. Endpoints verify it against a locally pinned Ed25519 key.

  2. 02

    Verify, stream, and stage

    The agent accepts only a fixed HTTPS origin, with redirects disabled, strict size bounds, streamed SHA-256 checks, and no-clobber local staging.

  3. 03

    Reject rollback

    Monotonic release sequence and semantic-version checks refuse stale or replayed artifacts before an update can advance.

  4. 04

    Promote by ring

    Target rollout rings and scheduled health gates keep a release scoped until observed fleet health earns the next promotion.

  5. 05

    Recover by design

    The updater is fixed-purpose: sealed product profiles, fixed service adapters, no arbitrary shell execution, and rollback after a failed health confirmation.

  6. 06

    Return lifecycle evidence

    Content-minimized, predecessor-linked receipts preserve staged-to-committed or rollback history for the operator evidence plane.

Desired statesigned Release payloadbound Rollout healthgated Applied statechained

See it run against your own traffic.

Request access for a deployment walkthrough, or run the open-source demo first.

By joining, you agree to our Privacy Policy and Terms.