Integrate once.
Govern centrally.
Route anywhere.

The AI governance layer between your apps and every model: cloud, LiteLLM or your own GPUs. One endpoint for access, data residency, cost and audit.

Get startedRead the docs
  • OpenAI-compatible
  • Fail-closed residency
  • PII guardrails
Applications connect through the REDtone gateway to cloud, on-premise and GPU backends; one path is blocked by policy

How it works

Northbound, an OpenAI-compatible API your applications already speak. Southbound, any provider, gateway or runtime. In the middle, the controls REDtone owns.

REDtone AI Gateway: applications on top, the gateway's control planes in the middle, AI providers and infrastructure below; all traffic passes through the gateway
Northbound. OpenAI SDKs, LangChain, n8n, chatbots and copilots — with a gateway key instead of a provider key.
Gateway. Tenant, project, user, policy, budget, placement, audit and compliance in one Go core.
Southbound. Commercial providers, LiteLLM, vLLM and Ollama, private models on-prem, and specialised services.

The product is the control planes

Backends change every quarter. These do not. Each one is a screen in the portal and a row in a table you can audit.

Key card, key and padlock

Identity & Access

Virtual API keys per tenant and application, hashed at rest and shown once. Per-key request and token rate limits. REDtone ID sign-in for the portal.

A shield routes traffic to an internal data centre and blocks the path to the cloud

Governance & Routing

Every tenant and key carries a data classification. Restricted requests reach internal backends only. Fail-closed: no permitted backend, no call.

An ID card behind a red shield, a padlock and a masked data block

Data Protection

PII and secrets are found before a request is routed, then recorded, masked, kept in Malaysia or blocked, by policy per tenant and key.

See it work
Coin stacks beside a budget gauge

FinOps & Quota

Token usage read from the backend, cost from a price table per backend and model. Monthly budgets that alert or stop traffic, with a REDtone credit limit on top. Usage by tenant, key, model and day.

Dashboard, log entries and a magnifying glass

Observability & Audit

A request log for every call: who, which backend and region, first-token latency, and why it failed. That log is the residency evidence. Prometheus metrics and an admin audit trail.

Personal data stays where it belongs

Every prompt is checked before it leaves the gateway. MyKad numbers, card numbers and secrets are masked, kept in Malaysia or stopped, by a policy you can watch before you enforce it.

Documents with personal data pass through a red shield: locked blocks go on to the cloud, some stay in an on-premise data centre, one is stopped at a barrier
  1. 1

    Detect

    MyKad, Malaysian phone numbers, email, card numbers, passports, bank accounts and API secrets are found in the gateway itself; names and addresses by Presidio. All before the request is routed.

  2. 2

    Decide

    Each rule records, masks (non-streamed answers get the real values back), keeps the request on internal backends in Malaysia, or blocks it. Set per tenant, with overrides per key.

  3. 3

    Prove

    Start in monitor mode and see what a policy would do to real traffic, then enforce it. Findings keep the type, a hash and a masked sample, never the value.

One request, through the guardrail
Your app sends

Please refund RM 120 to IC 880214-14-5523, card 4111 1111 1111 1111. Call me on 012-345 6789.

3 findings · MYKAD, CREDIT_CARD, MY_PHONE → mask · enforce
The model receives

Please refund RM 120 to IC [MYKAD_1], card [CREDIT_CARD_1]. Call me on [MY_PHONE_1].

Or, with keep in Malaysia, the request goes unchanged to an internal backend only; with block, it never leaves.

Bring your own backend, or use REDtone's

Provider-agnostic and gateway-agnostic. Connect your own with a name, a base URL and a key, or start on the models REDtone already runs. Either way, the same policies apply.

One gateway hub plugged into a server rack, a cloud and a GPU server

LiteLLM

Your existing LiteLLM proxy becomes one backend. It keeps the provider keys and the protocol translation; the gateway keeps the governance.

How to connect

OpenAI-compatible

vLLM, Ollama, SGLang, a vendor gateway, a partner's API — anything that answers /v1/chat/completions plugs in unchanged.

How to connect

Private & local models

An on-prem inference server marked as an internal location. Confidential and restricted traffic routes here and nowhere else.

How to connect

REDtone backend

No provider accounts or keys to manage. Use the models REDtone already connects, billed through your tenant and governed like the rest.

See available models

Available models

Leading AI brands behind one endpoint, governed by REDtone. Call them by name, or by a REDtone alias.

OpenAI

Frontier chat and embeddings

Google Gemini

Fast multimodal chat and speech

Anthropic

Careful assistants for writing and code

DeepSeek

Reasoning and code at a low price

Qwen

Open-weight chat, strong in EN and ZH

Mistral

European open-weight and commercial models

Meta Llama

Open-weight, a common on-prem choice

Google Gemma

Lightweight open models for private and edge

Zhipu GLM

Bilingual chat and agent models

Change two lines. Keep your code.

Every OpenAI SDK, LangChain and agent framework works as before. Migrating from LiteLLM? The model names can stay.

  1. 1

    Get a tenant

    Your REDtone contact creates the tenant and invites the first owner. Members, keys and budgets are self-service after that. Contact REDtone

  2. 2

    Create an API key

    Sign in with REDtone ID and create a key for each application. It is shown once and can be revoked any time. Sign in to get a key

  3. 3

    Point your code at the gateway

    Set the base URL and swap the key. Call a model by its own name or a REDtone alias. More samples

app.py · OpenAI SDK
from openai import OpenAI
 
client = OpenAI(
−    api_key="sk-...",
+    base_url="https://ai.redtone.com/v1",
+    api_key="rt-...",
)
 
reply = client.chat.completions.create(
    model="redtone/chat-default",
    messages=[{"role": "user", "content": "Hello from REDtone"}],
)