aigw
Use case

Let teams self-serve within guardrails

The platform team should not be a ticket queue for AI access, and opening the door should not mean losing control. aigw lets you set the guardrails once and let teams move inside them.

The problem

Every new team or app needs model access, a key, and a budget. If that runs through the platform team, they become the bottleneck. If they hand it out freely, governance slips: no budget, no policy, no idea who has what. You want self-service and control at the same time, which usually feels like a trade-off.

How it works

The platform team defines the guardrails: which models are available, the budgets, the data-loss and access policies, and who is allowed to change what through role-based access. Teams then create their own keys and onboard their own apps, and each key inherits those guardrails automatically. Roles keep a team inside its own scope.

What you get

  • Self-service keys and model onboarding, inside central guardrails, with no ticket.
  • Role-based access, so a team manages its own workspace and nothing else.
  • Budgets, data-loss policy, and access policy inherited by every new key, so “self-serve” never means “ungoverned.”
  • A management API to define all of it as code today, with a Terraform provider for enterprise, so your guardrails live in version control and change through review.

See the management API and keys.