Skip to content
Governance guide

AI policy enforcement before dispatch

AI usage policy is only real where it is enforced. Skyfix checks every request against the approved models, regions, data-handling rules and tool permissions before a provider sees it, from a signed bundle the gateway verified locally, and records the outcome with the request.

  • Checked in the gateway
  • Scoped keys as the contract
  • Step-up and emergency deny
The Governance › Approvals page of the Skyfix console: review cases opened from AI Firewall findings, each with a priority, an owner, an SLA and a due date.The Governance › Approvals page of the Skyfix console: review cases opened from AI Firewall findings, each with a priority, an owner, an SLA and a due date.
Review cases. Firewall findings become review cases with a priority, an owner, an SLA and a due date.Illustrative synthetic data

01

Where checks run

Policy runs in the request path, inside the gateway, from a signed runtime bundle the gateway verified with your installation's key. There is no call to the control plane per request, so policy keeps working if the control plane is unreachable, and there is no way to reach a provider around the check because the gateway is the only path out. Every decision, allow or deny, is recorded with the request.

02

What policy covers

Which providers and models a workspace, team or key may use; which regions and which data-residency rule apply to each data class; which model tiers are allowed for which environments; how prompt and response content is handled, captured, redacted and retained; which MCP tools and A2A partners are permitted; and a cost ceiling per request. Guardrail outcomes from the AI Firewall and budget status feed the same decision.

  • Provider and region allow and deny lists, evaluated before any routing preference.
  • Data-handling rules per data class: capture, redaction, retention and residency.
  • Tool and partner permissions carried on the key and checked per call.

03

Scoped keys as the contract

A scoped key is the unit of policy for an application. It carries its owner, team and application, the environments it may use, the models and tools it may call, its expiry, any IP restriction and the tags FinOps uses for attribution. A key inherits workspace rules and can only narrow them, so an application team cannot grant itself more than the workspace allows.

  • Scopes for chat, embeddings, batches, tools and agents, granted separately.
  • Expiry and rotation in the console, with every issue and revoke audited.
  • Tags read by policy and by FinOps, so one label scopes the key and allocates its cost.

04

Step-up and emergency deny

Changing policy is itself governed. Publishing a bundle, promoting a protected prompt label or changing production needs a fresh re-authentication within the step-up window and, where configured, a second person's approval. For incidents, an emergency deny stops traffic for the scope you choose and a last-known-good bundle restores a fleet in one signed action, both recorded in the audit trail.

The Governance › Audit page of the Skyfix console: a list of administrative actions described in plain language, each with the actor, category, scope and time, with filters and an export control.The Governance › Audit page of the Skyfix console: a list of administrative actions described in plain language, each with the actor, category, scope and time, with filters and an export control.
Audit trail. A bundle publication, an approval and an emergency deny are each recorded in the audit trail with actor, category and scope.Illustrative synthetic data

05

Reviewing exceptions

A denied request shows which key sent it, which rule matched, what was asked for and what happened next, on the same trace as everything else. Findings open review cases with an owner and a due date; argument policies for tools can run in audit mode first so a new rule is observed before it blocks. Exceptions are therefore decisions with evidence, not tickets with guesses.

FAQ

Questions this page answers

Where should AI policy checks run?

In the request path, before a provider sees the request, by the component that is the only path out. In Skyfix that is the gateway, evaluating a signed bundle it verified locally and recording every outcome.

Can policy restrict models by region?

Yes. Region allow and deny lists and data-residency rules per data class are evaluated before any routing preference, and a fallback provider must satisfy them too.

What happens when the control plane is unreachable?

Gateways keep enforcing the last bundle they verified. Policy publication waits; traffic does not. Evidence is buffered and synced, or, in evidence-required workspaces, requests are refused rather than served unrecorded.

How are exceptions reviewed?

From the request trace, which shows the key, the matching rule and the outcome, and from review cases that give a finding an owner, a priority, an SLA and a due date.

How is policy different from guardrails?

Policy decides what may be asked of whom: models, regions, tools, data handling, cost. Guardrails, provided by the AI Firewall, inspect the content itself for injection, secrets and personal data. Both run in the gateway and both land in the same ledger.