Start with visibility
Observe and Shadow modes report what a deterministic policy would do before an enforcing rule can interrupt production.
Policy and evidence
Enforce AI policy before a request reaches the provider.
An AI governance gateway that enforces approved models, tools, MCP access, budgets, and rollout modes before provider spend, with reason-coded audit evidence.
Organization and key-scoped policy
Observe, Shadow, and Enforce evaluation modes
Pre-spend tool/MCP declaration checks and pre-release call authorization
Reason-coded request decisions and audit metadata
In plain language
Turn a policy document into the same decision at every AI entry point.
AI governance fails when every application interprets the rules differently. AI Gateway HQ evaluates shared rules at the gateway, attaches a clear reason to the outcome, and lets administrators observe a rule's impact before it is allowed to interrupt production.
The practical resultSecurity, finance, and engineering can discuss the same request decision using evidence instead of screenshots and assumptions.
For the operating team
Roll out policy like an operational change.
Begin with visibility, narrow the scope, review affected traffic, and enforce only after the result is understood.
What administrators configure
Policy scope
Target organization, workload key, environment, client mode, model, data class, or signed attributes.
Evaluation mode
Observe what is happening, Shadow a proposed result, or Enforce a tested decision.
Explicit outcome
Allow, deny, cap, or constrain routes with stable codes that support triage and reporting.
Safe change control
Compare bounded policy and safeguard releases; restore known-good configuration only as a new, reasoned version that must pass current dependency and validation checks.
Tool boundary
Inventory function and MCP metadata; apply deny-overrides-allow names, types, hosts, and count limits before spend; then stop unoffered or unauthorized model calls before release.
What happens to each request
- 01Identify
Bind the request to an organization, workload, environment, user, and declared execution context.
- 02Evaluate
Apply policy and local attack signals before any provider credential is decrypted.
- 03Act
Allow, deny, cap, reroute, or observe the request with a stable reason code.
- 04Evidence
Write authorized metadata for review without persisting prompt or response bodies by default.
See the working control
Troubleshoot from the decision, not from a prompt archive.
The live ledger shows workload, route, reason code, upstream attempt, outcome, latency, configured cost, and audit-chain integrity.
- Rendered by the real customer console and control API
- Exercised with safe OpenAI- and Anthropic-compatible simulators
- Sanitization gate rejects credential-shaped values and private owner email
The live ledger shows workload, route, reason code, upstream attempt, outcome, latency, configured cost, and audit-chain integrity.
Control surface
Useful on day one. Explainable on day one hundred.
Each control has an operating path, an owner, and evidence that can be reviewed without collecting prompt bodies by default.
Higher-level controls stay effective
Organization posture caps the effective policy mode. A route- or key-scoped rule can narrow access, but it cannot silently weaken the organization boundary.
Agent-aware enforcement
Signed context distinguishes planning, interactive execution, CI/CD, and unattended agents. Tool profiles inventory function and MCP metadata, enforce names/types/hosts/counts before spend, and stop unoffered or unauthorized calls before release.
Evidence, not assertions
See the rule, input context, and resulting action.
Evidence is designed to show what the gateway knew and which current control applied without creating a default prompt warehouse.
Review security boundaries and current status Read the plain-language AI gateway guide Use the 12-test enterprise evaluation Govern without retaining prompt bodies Review the secure gateway boundary- Reason-coded policy, route, retry, fallback, and denial metadata
- Bounded tool names, types, MCP hosts, and authorization outcomes—without schemas, arguments, or results
- Provider-reported usage reconciliation for complete responses and supported terminal streams
- Tenant-bound credential encryption and fail-closed tenant authorization
- Signed, retryable administrative audit delivery with payloads and configuration snapshots excluded
- Clear labels separating available controls from items that still require validation
Questions teams ask
Know the boundary before you deploy.
Clear answers for buyers, administrators, and security reviewers.
Can a team test a rule without blocking users?
Yes. Observe and Shadow modes preserve the proposed decision and reason while allowing traffic to continue. Move to Enforce only after review.
Can business units override a central boundary?
The current model supports organization and workload-key policy. Delegated hierarchy and non-overridable parent controls are not currently available and should not be assumed in a pilot.
Are prompts or tool arguments stored for governance reporting?
Not by default. The hosted ledger retains operational metadata, policy reasons, bounded tool names/types/MCP hosts, counts, cost, and timing rather than prompt/response bodies, tool schemas, arguments, or results.
Does authorizing a tool make its execution safe?
No. The gateway controls what may be offered to a model and what emitted calls may be released. The client or tool host still owns user approval, least-privilege credentials, argument validation, egress policy, sandboxing, execution, and result handling.
Start safely
Start guided setupSee what the policy would do before it can block production.
Connect a provider credential, create a workload key, and begin in Observe mode. Move a tested rule to Enforce when your team is ready.