Enterprise controls
Policy management, provider allowlisting, budget enforcement, and compliance controls for enterprise deployments.
Ethen provides a set of controls for enterprise deployments: policy-based approval governance, provider allowlisting, budget enforcement, and credential isolation.
Provider allowlist
Projects can configure a provider allowlist to restrict which AI providers are eligible for use:
- When a project has any allowlist entries, only explicitly allowed providers are considered for routing.
- Providers with no matching entry are denied by default.
- When no allowlist is configured (the default), all available providers are eligible.
Allowlist enforcement requires configured Supabase storage. If storage is unavailable, the check fails closed: provider access is denied unless GATEWAY_BYPASS_ALLOWLIST_CHECK=true is set (local development only).
Budget enforcement
Projects can configure spending limits scoped by time period:
| Limit type | Scope | Description |
|---|---|---|
daily_usd | Per project | Total estimated cost in a UTC calendar day |
monthly_usd | Per project | Total estimated cost in a UTC calendar month |
monthly_tokens | Per project | Total tokens (input + output) in a UTC calendar month |
When a limit is exceeded, the Gateway rejects subsequent chat completion requests from that project. Budget enforcement follows the same fail-closed policy as provider allowlisting — requests are denied when storage is unavailable (bypassable in development).
Approval policies
Enterprise deployments can define approval policies that govern when human-in-the-loop approval is required. See the approval governance guide for the full policy schema and lifecycle.
Key enterprise-relevant policy capabilities:
| Capability | Description |
|---|---|
| Risk-level thresholds | Actions at or above a configurable risk level require approval |
| Action blocking | Specific risk levels can be blocked outright |
| Auto-execution limits | Low-risk actions can auto-execute up to a configurable count |
| Justification requirements | Policies can require a written justification for approval |
| Escalation contacts | Unresolved approvals can be routed to a designated contact |
Credential isolation
Enterprise deployments can isolate credentials per project:
- Gateway BYOK — each project stores provider credentials encrypted with AES-256-GCM, scoped to that project only. See the BYOK operational guide.
- Gateway API keys — each key is bound to a single project and environment (
liveortest). Cross-project access is rejected with a403error. - Desktop credential store — provider credentials for the local runtime are stored via Electron
safeStorage, isolated from the Gateway credential system.
Fail-closed policy
The Gateway applies a consistent fail-closed policy for enterprise controls. When the backing storage (Supabase) is unavailable:
| Control | Behaviour |
|---|---|
| Provider allowlist | Deny access (bypassable in dev) |
| Budget enforcement | Deny access (bypassable in dev) |
| BYOK credential resolution | Credentials unavailable; fall back to server-level env vars |
Review-required statements
The following enterprise control claims have not been independently verified:
- Allowlist enforcement and budget enforcement both rely on Supabase storage availability. The fail-closed policy is implemented but has not undergone independent penetration testing.
- Policy enforcement boundaries and risk-level thresholds depend on the approval framework runtime and have not been independently audited.