HaloHalo
Concept preview — nothing here is built or purchasable yet
Governed model access

Your AI calls already work. Point them through one gateway and they're governed.

Gateway sits between your product and the model providers you already use. Same SDK, same request shape — the base URL is the only thing that changes. What's different is everything Gateway does to the traffic in between.

Request early access →
client.py
from openai import OpenAI

- client = OpenAI(base_url="https://api.openai.com/v1")+ client = OpenAI(base_url="https://gateway.halogrc.ai/v1")
# everything below is unchanged
response = client.chat.completions.create(
    model="gpt-4.1",
    messages=messages,
)

Direct AI model provider access has a gap nobody's closing for you

01

You can't say what leaves your perimeter

Your product sends customer data — prompts, documents, context — straight to a third-party model provider. When a customer's security team asks exactly what left your systems and where it went, "we call the API directly" isn't an answer they can act on.

02

You can't see per-customer margin

Model spend is a single line on a single invoice. If one end-customer's usage pattern is quietly unprofitable, you find out from the P&L, not from the request that caused it.

03

You have one provider and one story

A single-provider dependency is fine until an enterprise buyer's business-continuity questionnaire asks what happens when that provider has an outage, and the honest answer is "so do we."

What happens between your request and the model

Every call routes through the same pipeline, regardless of which provider ultimately serves it.

01
Request in
Your call arrives at Gateway’s OpenAI-compatible endpoint. No SDK changes.
→
02
Policy routing
Relay picks a provider under your policy, with every decision logged.
→
03
Provider call
The request executes against the chosen provider, with failover on outage.
→
04
Audit & meter
Route, policy version, and cost are logged immutably and attributed to the end-customer.

What Gateway does

One interface, multiple providers

Governed routing across model providers behind a single, OpenAI-compatible API — change a base URL, not your code.

Immutable routing audit

What ran where, under which policy version, recorded on every request — not reconstructed after the fact.

Quantum-resistant transport encryption

Every hop — inbound, outbound to providers, and self-hosted backends — negotiates TLS 1.3 with a post-quantum key-exchange group, not just TLS 1.3 alone.

Per-customer cost attribution

Every request is metered and attributed to the end-customer that triggered it, not averaged across your book.

Provider failover

A single provider outage routes around itself instead of becoming your outage.

What we'll claim, and what we won't

Gateway is pre-launch. We'd rather understate what it does than let a claim outrun the infrastructure.

What's true today

  • ✓Routing decisions are logged and auditable, tied to a policy version.
  • ✓Every hop negotiates TLS 1.3 with a post-quantum key-exchange group.
  • ✓Existing OpenAI-compatible tooling works by changing one base URL.
  • ✓Contracting entity is Singapore-based, with local billing and terms.

What we won't claim

  • ✕Data residency in Singapore or anywhere else — infrastructure currently runs on US-backed hosting.
  • ✕Avoidance of US-headquartered providers or the CLOUD Act.
  • ✕Any hosting-jurisdiction guarantee about which countries a request can or cannot route through.
  • ✕Any SOC 2, ISO certification, or specific uptime figure for Gateway.
Get in touch

We're validating this before we build the rest of it

If you're routing AI traffic to a third-party provider today and want a clean answer for what leaves your perimeter, tell us about your setup. There's no product to sign up for yet — this is a conversation about whether Gateway is worth finishing.

Prefer email? Write to [email protected].