Axonyx Gateway

Nothing reaches a model provider unchecked.

Axonyx Gateway sits between your applications and the AI model providers. Every request is authenticated, inspected, governed and optimised before anything leaves your perimeter.

It speaks the OpenAI chat-completions API, so putting a tool under governance means changing a base URL and a key. No rewrite, no SDK swap, no agent on the endpoint.

Book a demo   Compare editions →
Where it sits

One door in, one door out

Applications do not talk to model providers directly. They talk to the gateway, and the gateway talks to the providers on their behalf. That single change is what makes everything else possible: one place to apply policy, one place to control spend, one place that knows what happened.

Your applications

  • Internal tools & services
  • Customer-facing chatbots
  • Agents & automations
  • Developer SDKs

Axonyx Gateway

  • Identity & policy
  • Limits & budgets
  • Content inspection
  • Model routing
  • Response checks
  • Full run record

Model providers

  • Major cloud model APIs
  • Sovereign endpoints
  • Your private models
  • Self-hosted & open source

Because the gateway is independent of every model vendor, your policy, your spend controls and your evidence survive a change of provider. Swap a model, add a provider, move a workload to a private endpoint, and nothing about your governance has to be rebuilt.

How a request is handled

Fourteen checks, in the same order, every time.

There is no fast path and no exception route. Every request runs the same ordered sequence, and most of it happens before the request has cost you anything. Those fourteen checks group into five things.

1

Identify

The request is bound to a known caller and the policy that caller is entitled to, before any content is looked at. Nothing runs anonymously.

2

Contain

Rate limits, circuit breakers and token budgets apply here, so a runaway loop or a misbehaving agent is stopped while it is still free to stop.

3

Inspect

Data loss prevention and prompt-injection detection run against the content in every form it arrives in, not just the obvious one.

4

Route

Approved models only, the cheapest model that can do the job, a cache checked before the provider is called, and a fallback chain if a provider is down.

5

Answer

The response is scanned on the way back for leaked data, hallucination, bias and drift, and the whole run is written to the record before it reaches the caller.

Before you pay for it

Three ways a request ends without reaching a provider

Most AI controls sit downstream of the bill: the request goes out, the money is spent, and you find out afterwards what happened. These three outcomes all resolve inside the perimeter, before a provider is ever called.

Blocked

The content breaks a rule you set, so the request stops. The caller gets a clear refusal, and the finding is recorded against the application that sent it.

Masked

The sensitive part is redacted and the rest of the request continues. The model gets what it needs to be useful and nothing it should not have seen.

Answered from cache

A question the platform has already answered is served from cache. No provider call, no token spend, and the same governance applied to the original.

Who is calling

A request cannot talk its way into a weaker policy

Governance that can be argued with is not governance. The gateway separates what a caller has proved from what a caller has merely claimed, and only the first one is allowed to affect a decision.

The credential decides the policy

However a caller arrives, it is resolved to one identity, and the policy that applies is the policy attached to the credential it authenticated with. An application cannot borrow a more permissive rule set by claiming to be something else. The claim is ignored and the mismatch is recorded.

Attribution is recorded, never trusted

Details about the workflow, the automation step and the user being acted for are written to the run record, so an action can be traced back to the process that took it. They are never used to authorise anything or to select a policy. They prove nothing, so nothing can be gained by forging them.

This matters most where it is least visible: agent frameworks and automation platforms generate traffic on behalf of many people, across many steps, at machine speed. Traceability there has to come from the credential and the run record, not from what the automation says about itself.

Cost and resilience

Cheaper and steadier, without you doing anything

The same position in the path that lets the gateway enforce policy also lets it take money and downtime out of the problem.

Right-sized models

Simple work does not need your most expensive model. The router scores the request and sends it to a cheaper model where a cheaper model will do. It only ever moves down, never up, so nothing quietly upgrades your bill.

Budgets that hold

Daily token and monthly spend caps are checked in the path, not reconciled at the end of the month. When a cap is reached, the gateway enforces it rather than emailing you about it.

Fallback when a provider fails

Providers have bad days. A circuit breaker takes a failing one out of rotation and the request continues down a fallback chain, so a provider outage is a slower answer rather than no answer.

Governs models from

  • OpenAI
  • Anthropic
  • Google
  • Microsoft Azure
  • AWS
  • Meta Llama
  • Mistral
  • Your private models

One approved-model allowlist across all of them.

See which providers and models are covered →How unsafe outputs are stopped in real time →

What you get

Six things that come with the position, not with effort

None of this needs a change to how your teams work. It follows from every request taking the same route.

Secure by design

Content is inspected in every form it can arrive in before it leaves your perimeter, so a rule cannot be dodged by changing how the request is encoded.

Governed consistently

Policy, budgets and model allowlists are enforced the same way for every application, whether it was built last year or last week.

Cost controlled

Rate limits, budgets, right-sized routing and caching all reduce provider spend, and the Cost Explorer shows where the rest of it went.

Fully observable

Every decision is recorded against the request that caused it, so an audit question and a support ticket are answered from the same place.

Resilient

Circuit breakers and a provider fallback chain keep services answering when an upstream provider degrades or goes dark.

Easy to integrate

An OpenAI-compatible chat-completions endpoint, so it is a drop-in replacement for the client libraries your developers already use.

Deployment modes

Your cloud or ours - same gateway, same control

Two ways to run the gateway. Both give you the same checks, the same policies and the same dashboards. The only question is where it runs.

Fastest to live

Axonyx Cloud

The fully managed gateway. Point your AI traffic at Axonyx and governance switches on - we run the scaling, resilience, updates and monitoring.

  • Live in days - no infrastructure work on your side
  • Zero client-side installation across browsers and apps
  • Regional hosting and data-residency options
  • Continuous updates: new controls, models and frameworks arrive automatically

Best for: organisations that want enterprise AI control now, without running new infrastructure.

Full sovereignty

Self-hosted - Kubernetes & Docker

The same gateway, running inside your own environment. Axonyx ships as standard containers - Docker for evaluation and smaller footprints, Kubernetes for production scale.

  • Prompts, responses and evidence never leave your network boundary
  • Deploys into the container platform your teams already operate
  • Your infrastructure, your keys, your identity and network controls
  • Fits private-cloud, on-premises and regulated sovereign estates

Best for: regulated and sovereignty-driven organisations with strict data-boundary requirements.

Not sure which fits? Many customers start on Axonyx Cloud for speed, then move - or extend - into self-hosted as sovereign workloads come on board. Policies, dashboards and evidence carry across unchanged.

Getting live

Days to deploy, not months

Whichever mode you choose, the gateway is designed to slot into the estate you already have - no rip-and-replace, no code changes to the tools your teams use, no army of integrators.

Connect, don’t rebuild

Route AI traffic through the gateway - cloud or self-hosted - and governance switches on across existing applications, browsers and workflows.

Your rules from day one

Start with proven policy packs for your sector and frameworks, then tune thresholds, routing rules and controls to match your risk appetite.

Sovereign options

Choose where data lives and which providers handle which workloads - regional deployment, sovereign endpoints and data residency controls built in.

Value before the first renewal

Shadow AI surfaced, sensitive data protected and evidence accumulating from the first week - visible in the dashboard your leadership team actually reads.

Which edition

The gateway is the platform

Every Axonyx edition runs on the same gateway. What changes between them is how much you can author on top of it.

Axonyx Core

The governed gateway with the DLP and prompt-injection packs, an approved-model allowlist, the full run log and cost attribution. Everything a smaller organisation needs to put AI under control.

Axonyx Core →

Axonyx Enterprise

Adds your own rules, per-application policy, agent guardrails, budgets, quality and risk monitoring, and framework-mapped evidence.

Axonyx Enterprise →

Compare the editions

One base URL away from governed.

We will point one of your own tools at Axonyx Gateway in shadow mode, block nothing, and show you what a week of your real AI traffic actually looks like.

Book a demo