Octoryn Platform
Octoryn Gateway
A controlled AI gateway so model access passes through organisational policy instead of scattered API keys.
Overview
Octoryn Gateway is a controlled point of access for AI models, so that model use passes through organisational policy instead of API keys scattered across laptops, scripts and teams. It sits between your applications and one or more model providers, handling central access, provider routing and fallback, sensitive-data detection and redaction, residency-aware routing, logging and cost controls. It is for organisations that have moved past a single experiment and now face the real problem of many people calling many models with no consistent policy, visibility or spend control. Gateway is in private preview, and its provider coverage and controls are still being extended with early partners.
How it works
Route through one entry
Applications call the Gateway instead of a provider directly, so there is a single governed path for model access.
Authenticate and authorise
The Gateway checks who is calling and what they are permitted to use, so provider keys are not handed out to individuals.
Inspect and redact
Requests are screened for sensitive data, which can be detected and redacted before leaving your boundary or being sent to a provider.
Route by policy and residency
Traffic is directed to an appropriate provider based on policy, residency requirements and availability, with fallback if a provider is unavailable.
Log and control cost
Each call is logged for visibility, and cost controls apply so spend can be monitored and bounded across teams.
Key capabilities
Central access, no scattered keys
Provider credentials live behind the Gateway rather than in individual hands, reducing the sprawl of unmanaged keys.
Provider routing and fallback
The Gateway can route across multiple providers and fall back when one is unavailable, reducing dependence on any single vendor.
Sensitive-data detection and redaction
Requests can be inspected for PII and other sensitive content, and redacted before they reach an external provider.
Residency-aware routing
Traffic can be routed to respect where data is permitted to be processed, which matters for organisations with residency obligations.
Logging and visibility
Model calls are logged centrally so an organisation can see what is being used, by whom and for what.
Cost controls
Usage can be monitored and bounded so model spend does not accumulate silently across teams and projects.
What it is not
- It is not a model or a model provider; it is a governed path to whichever providers you choose to use.
- It does not by itself make model outputs correct or safe — it controls access and data flow, not the quality of a model’s answers.
- Redaction is a boundary control, not a promise that no sensitive data can ever pass; detection has limits and is configured per engagement.
Integration
Gateway is designed to sit in front of your applications with minimal change to how they call models, presenting a consistent interface while it handles provider connections behind it. It can connect to your identity source for authentication and export its logs to your own monitoring and audit systems. The specific providers, residency routes and redaction rules are assessed per engagement, and provider coverage is limited during private preview.
Deployment options
- Managed cloud
- Our cloud account
- Private cloud / VPC
- On-premises
Example use cases
- Consolidating dozens of individually held provider keys behind one governed entry point with central visibility.
- Detecting and redacting PII in prompts before requests are sent to an external model provider.
- Routing traffic to keep certain workloads within a required processing region while falling back across providers for availability.
- Giving finance and platform teams a central view of model usage and spend across the organisation.
Frequently asked questions
Does Gateway lock us into particular model providers?
No — the intent is the opposite. By routing through a common entry point it aims to reduce dependence on any single provider and make switching or falling back easier. You choose which providers to connect. Coverage is still expanding during private preview.Can Gateway stop sensitive data reaching a provider?
It can detect and redact sensitive content such as PII before requests leave your boundary, and enforce residency-aware routing. This is a boundary control with limits, configured per engagement, not a guarantee that nothing sensitive can ever pass. Detection rules are tuned to your context.Do our applications need major changes to use Gateway?
It is designed to present a consistent interface so applications point at the Gateway rather than each provider, keeping changes modest. The exact integration effort depends on your current setup and is assessed per engagement. Gateway is in private preview, so the supported surface is still limited.
All capabilities
Octoryn Builder
Private previewBuild production applications that emit portable, reviewable source code — not a locked-in low-code runtime.
- Audience:
- Engineering teams and organisations building internal and customer-facing software.
Octoryn Runtime
Private previewA runtime for governed AI-enabled applications, connecting models, policies, tools and operational systems.
- Audience:
- Teams operating AI inside real workflows and systems of record.
Octoryn Privacy
PilotSensitive-data controls: detection, redaction and residency-aware handling across the AI path.
- Audience:
- Privacy, risk and compliance functions in regulated organisations.
