SLAIF API Gateway — Controlled AI Access and Service Exposure

One gateway, two directions

In one direction, the SME consumes AI. Employees, applications, workshops, and autonomous agents use gateway-issued keys to reach approved external models without receiving the organisation's real provider credentials.

In the opposite direction, the SME provides AI. Customers, partners, or internal applications use the same OpenAI-compatible interface to access an SME-owned model or specialist AI service behind the gateway.

The dual role connects SLAIF's simplified access objective with proof-of-concept operationalisation: one control plane for safely using other organisations' AI and safely exposing AI services developed locally.

The implementation is available as a tested RC-beta foundation. It is not a production, compliance, security-certification, or SLA claim.

View SLAIF API Gateway on GitHub

Overview

SLAIF API Gateway is an open-source, self-hosted, OpenAI-compatible control plane for organisations that consume external AI and expose AI services of their own. In the outbound direction, employees, applications, workshops, and coding agents use gateway-issued keys while provider credentials remain server-side. In the opposite direction, approved clients use the same standard interface to access an organisation-owned OpenAI-compatible backend or reviewed native service module. The gateway applies explicit model, endpoint, capability, quota, budget, rate, concurrency, validity, routing, accounting, and audit policy to both directions.

Outcome

One organisational gateway for controlled access to external providers and controlled publication of locally developed AI services. Existing OpenAI-compatible clients normally change only OPENAI_API_KEY and OPENAI_BASE_URL. Operators receive key lifecycle management, provider and route configuration, PostgreSQL-backed quota and accounting state, safe usage metadata, an admin dashboard, a CLI, and self-hosted deployment tooling.

Service Card

Category	Infrastructure and data-related services
Domain	AI Infrastructure, API Management, Governance, Usage Accounting
Vertical	Cross-domain
Target users	SMEs, Research Organisations, Public Institutions, AI Developers, Platform Operators, Training Providers
Service type	Platform / API Gateway / Access-Control Service
Outputs	OpenAI-compatible API endpoint; gateway-issued keys; model and capability policies; quotas, budgets, rates and concurrency controls; usage and EUR cost metadata; audit exports; admin dashboard and CLI; provider routing; generic compatible-backend and reviewed native-module integration; Docker Compose and Nginx deployment assets.
Requirements	A self-hosted Python 3.12 and Docker Compose environment with PostgreSQL and Redis, operator-managed secrets, explicit provider or local-backend configuration, and HTTPS/reverse-proxy hardening for exposed deployments. The current SME MVP assumes one organisation per deployment and trusted full operators.
Limitations	The current implementation is an RC-beta foundation, not production, security, compliance, or SLA certification. It does not claim cryptographic multi-tenant isolation, full RBAC, MFA, SSO, exact invoice-grade billing, or universal OpenAI API compatibility. Supported endpoints and fields are explicitly bounded and unknown capabilities fail closed.
Availability	Open-source RC-beta available for bounded self-hosted evaluation
Licensing	Apache License 2.0

Why an SME needs an AI control plane

AI adoption often begins informally. One provider key is copied into developer environments, notebooks, workshop instructions, internal applications, and coding-agent profiles. This is convenient for the first experiment but quickly creates operational questions that a small team cannot answer reliably:

Who can use which provider and model?
How can one user be revoked without rotating everyone?
How much did one application, project, or autonomous agent consume?
Can a workshop key expire automatically?
Can an agent use text inference but not provider-hosted tools?
Can the organisation change provider without rewriting every client?
How can a locally developed AI service be exposed without rebuilding authentication and accounting?

SLAIF API Gateway addresses these questions as one organisational control plane. It is self-hosted, open source, and compatible with standard OpenAI clients for the explicitly supported API subset.

One gateway, two opposite request flows

The most important property is its dual role. An SME can be an AI consumer and an AI provider at the same time.

flowchart LR
    subgraph CONSUME["Flow 1 - SME consumes external AI"]
        STAFF["Employees applications workshops and agents"] --> GATE1["SLAIF API Gateway"]
        GATE1 --> EXTERNAL["OpenAI OpenRouter or approved provider"]
    end

    subgraph PROVIDE["Flow 2 - SME provides its own AI"]
        CLIENTS["Customers partners or internal clients"] --> GATE2["SLAIF API Gateway"]
        GATE2 --> LOCAL["SME owned compatible backend or reviewed module"]
    end

Technically, both flows enter the same gateway API. Organisationally, their direction is opposite:

AI consumption moves an SME request outward to an external provider.
AI provision moves a client request inward to an SME-owned model or specialist service.

The gateway applies the same key, policy, routing, quota, accounting, and audit foundation to both.

Flow 1: controlled consumption of external AI

Users receive gateway-issued keys, not the organisation's unrestricted OpenAI or OpenRouter credential. For every request the gateway can evaluate:

key status, validity period, owner, institution, and cohort;
allowed providers, models, endpoints, and route capabilities;
request, token, and EUR limits;
rate and concurrency controls;
supported tools and explicitly denied hosted authority;
configured routing, pricing, and currency conversion metadata.

After admission, the gateway replaces the client credential with the real server-side provider credential and forwards a reconstructed, allowlisted request. Unsupported fields and capabilities fail closed. Provider usage is used to finalise PostgreSQL-backed accounting when available.

This is particularly valuable for autonomous coding agents. An agent can receive a dedicated short-lived key with a substantial but finite budget and exactly the model and endpoint capabilities needed for its task. It does not receive the organisation's master provider credential.

Flow 2: controlled exposure of SME-owned AI

An SME may already have a useful model or specialist service but lack the surrounding infrastructure needed to make it safely usable by clients.

The gateway currently supports two integration forms:

Generic OpenAI-compatible backend routing. An operator can register a reviewed compatible /v1 backend, its server-side credential, routes, models, capabilities, and pricing metadata.
Reviewed native modules. A statically registered adapter can translate an OpenAI-shaped request into a specialist internal contract and convert the result back into an OpenAI-shaped response. The current repository includes a bounded facial-manipulation scoring adapter as the first implemented example.

Dynamic imports and arbitrary plug-ins are deliberately not allowed. Every native module is reviewed source code with an explicit request, credential, response, and accounting boundary.

This allows an SME to place the following controls in front of its own AI service:

gateway-key creation, rotation, suspension, and revocation;
per-client model and capability policy;
request limits, rates, concurrency, and validity windows;
fixed-request or token-based pricing metadata;
content-minimising usage and audit records;
an operator dashboard and CLI;
a standard OpenAI-compatible client surface.

The SME can focus on its differentiating model rather than implementing a new access-management system for every proof of concept.

One standard client configuration

For supported routes, existing applications normally need only two environment variables:

export OPENAI_API_KEY="sk-slaif-..."
export OPENAI_BASE_URL="https://gateway.example.com/v1"

The ordinary OpenAI Python client can then be used without a SLAIF-specific SDK:

from openai import OpenAI

client = OpenAI()
response = client.chat.completions.create(
    model="your-approved-model",
    messages=[{"role": "user", "content": "Hello"}],
)
print(response.choices[0].message.content)

This portability lowers onboarding cost and reduces provider lock-in at the client boundary. It does not imply support for every OpenAI endpoint or field; the gateway publishes an explicit compatibility matrix and rejects unknown capabilities.

What the control plane governs

Area	Implemented foundation
Credentials	Gateway keys are delivered once and stored as HMAC digests; upstream provider keys remain server-side.
Access policy	Per-key provider, model, endpoint, capability, validity, lifecycle, tool, rate, and concurrency controls.
Quota and cost	PostgreSQL admission reservation and finalisation for requests, tokens, and configured EUR budgets.
Routing	Explicit model routes to OpenAI, OpenRouter, compatible backends, or reviewed native modules.
Accounting	Safe token, cost-source, confidence, overrun, route, and operational metadata without prompt storage by default.
Operations	Admin dashboard, Typer CLI, metrics, audit exports, backup/restore, incident and upgrade runbooks.
Deployment	Development and production-style Docker Compose topologies with PostgreSQL, Redis, API, workers, scheduler, and Nginx.

PostgreSQL is the durable accounting source of truth. Redis is used for temporary operational limits and coordination; it does not become the only financial or quota record.

Supported API surface

The current main branch implements bounded subsets of:

GET /v1/models;
POST /v1/chat/completions, including non-streaming and SSE streaming;
POST /v1/responses and selected Responses lifecycle operations;
POST /v1/audio/speech, /audio/transcriptions, and /audio/translations;
POST /v1/embeddings;
POST /v1/realtime/client_secrets under a narrowly documented admission boundary.

The exact accepted fields depend on endpoint, provider route, model capability metadata, and key policy. Native Anthropic API compatibility is not implemented; Anthropic-family models can be reached only through a configured OpenAI-compatible provider such as OpenRouter.

Practical SME profiles

Organisation access

Issue separate staff and application keys with approved model lists, monthly budgets, expiration, and revocation without distributing provider secrets.
Agent and coding workloads

Give an autonomous agent a bounded key with conservative tool authority, concurrency, token, request, and cost limits.
Workshops and training

Create short-lived participant keys with narrow models and small quotas. A leaked participant key does not expose the upstream provider credential.
Research projects

Represent projects through owners, cohorts, templates, routes, and budgets while keeping one organisational deployment boundary.
AI service publication

Put governed OpenAI-compatible access in front of a locally developed model, ZAP-IT-like service, or reviewed specialist module.
Trusted evaluation

Use short-lived calibration keys to understand safe usage patterns before creating ordinary user policy.

These profiles compose existing controls and documented targets; they are not separate tenants or five complete one-click modes.

Architecture and request lifecycle

flowchart TD
    CLIENT["OpenAI compatible client"] --> NGINX["Nginx and HTTPS"]
    NGINX --> API["SLAIF Gateway API"]
    API --> AUTH["Key authentication and policy"]
    AUTH --> LIMITS["Rate concurrency and capability checks"]
    LIMITS --> RESERVE["PostgreSQL quota and cost reservation"]
    RESERVE --> ROUTE["Model and provider route resolution"]
    ROUTE --> OUT["External provider"]
    ROUTE --> OWN["Organisation owned backend or native module"]
    OUT --> FINAL["Usage and cost finalisation"]
    OWN --> FINAL
    FINAL --> LEDGER["PostgreSQL usage and audit truth"]
    FINAL --> RESPONSE["OpenAI shaped response"]

Prompts, completions, uploaded media, raw provider bodies, and reasoning content are not stored by default. Permitted external-provider requests still send their content to the selected provider under the organisation's provider relationship.

Security and governance posture

The gateway is designed around explicit authority and fail-closed behavior:

client authorization is never forwarded as provider authorization;
provider secrets are referenced through operator-controlled environment variables or secrets;
unknown endpoints, fields, routes, tools, and prices are rejected where policy requires certainty;
gateway keys are stored as non-recoverable HMAC values;
temporary one-time delivery secrets are encrypted and expire;
admin mutations use authenticated sessions, CSRF controls, confirmations, and audit reasons;
request content is excluded from normal usage records, logs, metrics, and exports;
safe provider errors are reconstructed instead of returning raw upstream bodies.

Self-hosting does not by itself create legal compliance. Operators remain responsible for provider contracts, data-processing terms, deployment hardening, retention, user policy, risk assessment, and applicable law.

SLAIF and European relevance

SLAIF is intended to provide a unified access point, lower SME entry barriers, deliver generic horizontal platform services, and help users operationalise proof-of-concept AI solutions. The gateway implements the missing access and governance layer between those objectives:

simplified access to external models
                +
controlled exposure of local AI services
                +
portable OpenAI-compatible clients
                +
organisational policy and accounting

This is aligned with the European direction toward trustworthy AI adoption, SME access to AI Factory resources, interoperable infrastructure, organisational control, and the movement of AI from experiments into useful services. It is an engineering foundation for responsible adoption, not an AI Act compliance certificate.

Current evidence and boundary

The repository currently describes itself as a credible RC-beta foundation for one organisation per deployment. Current main has successful CI, CodeQL, and code-quality workflows. The repository includes extensive unit and integration coverage, official-client E2E tests, browser smoke tests, Docker Compose qualification, migrations, backup/restore, Nginx validation, documentation checks, and a bounded production-appliance qualification using provider doubles.

The only published release remains v0.1.0-rc.1; later RC2 documentation is not a published release. Complete real-provider accounting qualification is not currently established.

The gateway does not claim:

cryptographic multi-organisation isolation;
full RBAC, MFA, SSO, or SCIM;
invoice-grade accounting or exact mid-request cost containment;
universal OpenAI API compatibility;
penetration-test, security, compliance, or production certification;
an enterprise support SLA.

These limitations do not negate the working SME proposition. They define the boundary for bounded self-hosted evaluation and the work required before a particular production deployment.

Explore the implementation

Open the SLAIF API Gateway repository Read the product scope Read the compatibility matrix Read the deployment guide