Security by construction

Keep provider credentials centralized, encrypted, and out of application code.

A secure enterprise AI gateway for centralized provider credentials, SSO, scoped workload keys, tenant-bound encryption, guardrails, and audit evidence.

Working sandbox capture
Security by construction controls in the working console.Current interface evidence: Signals named · Tools bounded · Pre-provider. This sanitized capture contains no customer secrets or prompt bodies.
KMS encryption context per tenant and credential
Self-service OIDC/SAML SSO, exact group rules, and virtual workload keys
Metadata-private tool and MCP authorization boundary
Self-service SCIM lifecycle with optional federated-login enforcement
In plain language

Reduce the number of places that can leak a provider credential.

Applications receive revocable workload keys rather than raw provider secrets. The gateway resolves tenant and policy context first, selects an eligible credential, and decrypts that credential only for the provider call. Operational telemetry is metadata-minimized by default.

The practical resultA compromised application key can be disabled without rotating every provider account or searching repositories for copied secrets.
For the operating team

Keep identity, credentials, and support access separated.

Customer administrators and AI Gateway HQ staff use isolated identity tenants and explicit access boundaries.

What administrators configure
Workload identity

Issue scoped virtual keys and bind policy, rate, budget, and environment controls to each one.

Provider secrets

Write encrypted credentials with tenant and credential encryption context; never return the secret value.

Administrative access

Use OIDC, built-in roles, mandatory customer/staff MFA, and time-bounded support authorization.

Agent tool boundary

Authorize bounded tool and MCP metadata at the model boundary without turning the gateway into an untrusted-code executor or retaining tool arguments and results.

What happens to each request
  1. 01
    Identify

    Bind the request to an organization, workload, environment, user, and declared execution context.

  2. 02
    Evaluate

    Apply policy and local attack signals before any provider credential is decrypted.

  3. 03
    Act

    Allow, deny, cap, reroute, or observe the request with a stable reason code.

  4. 04
    Evidence

    Write authorized metadata for review without persisting prompt or response bodies by default.

See the working control

Bring accounts under control without returning their keys.

The console identifies each upstream account and its health while provider secrets remain write-only.

  • 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
Follow the operating workflow
Provider boundaryBring accounts under control without returning their keys.

The console identifies each upstream account and its health while provider secrets remain write-only.

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.

01

No prompt warehouse by default

The hosted ledger retains operational metadata, policy reasons, bounded tool names/types/MCP hosts, counts, cost, and timing—not prompt/response content, tool schemas, arguments, or results.

02

Common enterprise identity

An owner can add OIDC or public SAML metadata, verify the Cognito provider, map exact external groups to fixed roles, and issue a connection-bound SCIM 2.0 credential without a support ticket. SAML metadata and signing keys are checked during lifecycle changes and on a bounded schedule; the console exposes hash-only fingerprints, key count, last attempt, and the exact fail-closed trust expiry. Provisioning can be paused independently from active-user login enforcement; SCIM groups cannot grant gateway roles. Custom roles are not currently included.

03

Verifiable releases

Production changes require infrastructure review, code and dependency scanning, active web security tests, software inventories, and signed release artifacts. Restore drills run in isolated environments and are reported as engineering evidence—not as a contractual recovery time or SLA. Independent penetration testing and formal assurance remain separate work.

Evidence, not assertions

Inspect access decisions without broadening data collection.

Current controls provide identity, tenant, policy, cost, timing, and outcome metadata. Formal certification and customer-specific validation remain separate work.

Review security boundaries and current status Read the plain-language AI gateway guide Review live-request governance Use the 12-test enterprise evaluation
  • 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 AI Gateway HQ staff see our provider keys?

The console treats provider credentials as write-only. Runtime decryption is tenant-bound. Staff access must be separately authorized, although external penetration testing is still required before high-risk production use.

Does the product support SAML and SCIM today?

Yes. Organization owners configure tenant-pinned OIDC or SAML 2.0 sign-in, exact external-group-to-built-in-role rules, and connection-bound SCIM 2.0 user and group lifecycle from the console. SAML metadata and signing keys are checked during setup and on a schedule; only hash-and-expiry evidence is retained, overlapping rollover keys extend trust safely, and expired trust blocks login. SCIM login enforcement can require an active provisioned identity without allowing SCIM groups to grant roles. Owners can separately scope portfolio administrators and analysts to an entire portfolio, selected custom groups, individual approved PortCos, or an explicit combination. Custom roles, general delegated identity administration, access-review campaigns, and live third-party conformance evidence are not currently included.

Is AI Gateway HQ SOC 2 or HIPAA certified?

No certification is claimed. The architecture and evidence model are being built toward later assurance work, but certification and regulated-use validation are still required.

Start safely

See 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.

Start guided setup