Compliance

Provider compliance policies let you guarantee that requests are only ever sent to model providers (Anthropic, OpenAI) that meet your organization's regulatory requirements. When a request would go to a provider that doesn't meet the policy, Halfbill blocks it before any data leaves Halfbill.

Requirements

Enable a policy under Settings → Compliance in the dashboard and toggle the requirements you need:

On Halfbill Code, enable No AI training directly under Settings. It uses the same fail-closed provider policy described below, but the other requirements are not available on Halfbill Code.

Every requirement is fail-closed: a provider passes only if its published data policy explicitly satisfies the requirement. If an attribute is unknown for a provider, that provider is treated as non-compliant.

Before enabling Zero data retention (ZDR), set the organization's data retention to Metadata Only and disable response caching in every project. While ZDR is active, Retain All Data and project response caching are unavailable, gateway response caching is bypassed, provider prompt-cache markers are stripped, and Responses API requests must set store: false. Disable ZDR before turning payload retention or caching back on.

Existing policies that use the deprecated No prompt logging rule continue to enforce their original provider-routing behavior. The legacy rule is no longer available for new configuration and does not enable the gateway-level ZDR controls described above.

The settings page shows a live Provider Impact preview of which providers are allowed (green) and which are blocked (red) under the current policy, so you can see the impact before saving. Hovering a blocked provider lists exactly which requirements it does not meet — a missing certification, its data policy, or a provider-list restriction.

Provider & model restrictions

Beyond attribute-based requirements, the Provider & Model Restrictions card lets you block or allow individual providers and models:

• Blocked providers / blocked models — deny lists. A listed provider or model is always blocked, even when it satisfies every requirement above.
• Allowed providers / allowed models — fine-grained allow lists. When non-empty, only the listed providers (or models) may be used; everything else is blocked. An empty list applies no restriction.

Deny lists always win over allow lists, and both compose with the requirements above — an allow-listed provider must still satisfy every active certification and data-policy requirement.

Choosing a compliant provider

The provider dropdowns are policy-aware, so you can tell before adding a provider to a list whether it satisfies your policy:

• A green shield marks a provider that meets every active certification and data-policy requirement.
• A red shield marks a provider that does not; the requirements it misses (for example "May log prompts") are listed under its name.
• The "Only providers that meet policy requirements" toggle at the top of the dropdown hides incompatible providers entirely.

These indicators evaluate the requirements only — deliberately ignoring the allowed/blocked lists themselves — so an active allow list never paints every other provider red while you're deciding what to add to it.

Elsewhere in the dashboard (for example the API-key provider filter), the colored dot next to a provider is simply the provider's brand color and carries no compliance meaning.

These restrictions are organization-wide and take precedence over member-level and API-key-level IAM rules: they are enforced after IAM evaluation, so no user-, team-, or key-level allow rule can grant access to a provider or model the compliance policy excludes.

Enforcement

When the provider of a model does not meet the policy, Halfbill returns a 403:

{
	"error": {
		"message": "This request was blocked by your organization's provider compliance policy. No available provider for gpt-5.5 meets the required certifications or provider/model restrictions. Contact your Halfbill admin to adjust the policy."
	}
}

Each block is recorded as a security event so administrators can review what was rejected and why.

Safety identifiers

Providers that offer an abuse-attribution identifier receive an opaque, random value that Halfbill generates once per organization. It contains no personal data — no email address, user id or organization name — and it is the only thing that ties a report of abusive traffic back to an account.

Whether Halfbill forwards this identifier depends on the upstream API. Any safety_identifier you set on a request yourself is ignored — the value is always the one derived from your organization.

Access Control

Only organization owners and admins can view and change the compliance policy.

Project-scoped developer members cannot see the policy itself, but they can browse the org's available models read-only on the Models page. This is the recommended way for developers to discover what they can call without being granted additional permissions.

Related

• Org Models Directory — see per-model eligibility under the active policy in the dashboard.
• Guardrails — detect and block harmful or sensitive content.

Get Started

Halfbill Code subscribers can configure No AI training under Settings. Contact us for the complete provider compliance policy.