Skip to content

Use casesGovernance

One policy for which models, data and people reach your providers.

Policy written in a wiki is advice. Policy in the gateway is enforced on every request: the models a project may call, what may appear in a prompt, which environment a key can reach, and who changed any of it.

Start 14-day trialRequest a demo
Project payments · production keyExample
Modelnot on the project allowlist → 403 model_not_allowed
Promptcard number found → redacted before the call
Keyproduction only · staging connection unreachable
Auditallowlist changed by an admin, 09:42 UTC

Example policy. Pattern detection can miss things; it reduces risk, it does not remove it.

The problem

Without a control plane

  • Each team picks models and providers on its own.
  • Personal data and secrets reach a provider in a prompt, unseen.
  • Nobody can say who granted a key access, or when.

With INFRO

  • Allowlists per organization, project and key, refused with a policy error.
  • Guardrails block, redact or flag sensitive patterns in prompts and responses.
  • Every member, key and policy change in the audit log.

How it works

  1. Separate environments

    Production, staging and development, plus your own. A key belongs to one and never reaches a connection outside it.

  2. Approve models and data

    Allowlists say which models each scope may call; guardrails check prompts and responses for the patterns you choose.

  3. Control who can change it

    Roles, project access for members, SSO and SCIM from your identity provider, and an audit log of every change.

What you get

Each one is documented, and each says which plan includes it. Where no plan is named, it is on every plan.

  • Model allowlists

    Allow or block models per organization, project and key; a block-only list covers future models too.

    Docs

  • GuardrailsFrom Business

    Block, redact or flag email addresses, card numbers, IBANs, API keys and your own terms in prompts and responses.

    Docs

  • Environments

    A connection or route serves one, several or every environment; each key belongs to exactly one.

    Docs

  • Project access

    Limit a developer or analyst to some projects; the gateway refuses everything organization-wide.

    Docs

  • SSO and SCIMFrom Business

    SAML or OIDC sign-in against your identity provider, and SCIM provisioning that creates and deactivates members.

    Docs

  • Audit log

    Member, key and policy changes with actor and timestamp, in the console.

    Docs

Who it is for

  • Security teamsControls enforced on the request path, with a record of who changed them.
  • ComplianceOne place that answers which models and providers your organization uses, and under what rules.
  • Platform ownersTeams move fast inside a policy instead of waiting on a review for each model.

FAQ

Do guardrails catch everything?

No. They are pattern checks, with optional classifier checks on your own decision-model connection. Detection can miss things, and the docs say which patterns are checked.

Does INFRO store our prompts?

Prompt and completion logging is off by default. If you turn it on, you choose the retention window.

Which plan includes SSO and guardrails?

Guardrails are included from the Business plan, and SSO with SCIM from the Business plan. Allowlists, environments and the audit log are on every plan.

The full contract is in the Model allowlist docs, and every other question is on the FAQ.

Field guides

Related

All use cases

Get started

Try it on your own provider accounts.

Connect a provider, create a gateway key and change one base URL. Your providers keep billing you directly; 0% markup on model spend.

Start 14-day trialRequest a demo