Octoryn Platform
Octoryn Runtime
A runtime for governed AI-enabled applications, connecting models, policies, tools and operational systems.
Overview
Octoryn Runtime is the execution layer for AI-enabled applications that need to act, not just chat — it connects models, policies, tools and operational systems under one governed flow. Rather than letting an application call a model and fire off actions directly, Runtime places identity, authority, policy, approval, execution, monitoring and replay between intent and effect, so every action is classified and handled according to its risk. It is for organisations putting AI-driven behaviour close to real systems — creating records, triggering workflows, moving data — where "the model proposed it" is not an acceptable audit answer. Runtime is in private preview and is being validated against real governance requirements with early partners.
How it works
Establish identity and authority
Each request runs under a known identity with a defined scope of authority, so the runtime knows who or what is acting and what they may do.
Classify the action
Proposed actions are classified as read-only, reversible or irreversible, which determines how much scrutiny and approval each one needs.
Apply policy
Policies decide whether an action may proceed, needs human approval, or must be refused, and the decision itself is recorded.
Execute through governed tools
Approved actions run through defined tool interfaces to operational systems, with sensitive-data boundaries enforced along the way.
Monitor and replay
Every step — provenance, model and version, policy decision, tool call, approval, output and verification — is captured so an action can be reviewed or replayed later.
Key capabilities
Action classification
Runtime treats read-only, reversible and irreversible actions differently, reserving stronger controls and approvals for what cannot be undone.
Policy between intent and effect
A model's suggestion does not become an action until policy permits it, keeping “propose” and “dispose” separate.
Human approval and escalation
Higher-risk actions can require a person to approve, with clear escalation paths when something falls outside policy.
Sensitive-data boundaries
The runtime enforces where sensitive data may and may not flow as actions cross into external tools and systems.
Evidence and replay
Each action carries a tamper-evident record of its provenance, decisions and outputs, and can be replayed for review.
Fail-closed behaviour
When a check cannot be satisfied, the default is to stop rather than proceed unsafely.
What it is not
- It is not a fully independent agent that acts without oversight — higher-risk actions are designed to route to human approval.
- It is not a model or a model provider; it governs how models are allowed to act, not the reasoning inside them.
- It does not make risk disappear; it makes actions classified, bounded and reviewable rather than promising a risk-free outcome.
Integration
Runtime connects to operational systems through defined tool interfaces, and to identity and policy sources your organisation already runs, so actions execute against your systems rather than a walled garden. It records provenance and decisions in a form that can be exported for your own audit and review. The specific systems, connectors and data flows are assessed per engagement, and the supported surface is limited during private preview.
Deployment options
- Managed cloud
- Our cloud account
- Private cloud / VPC
- On-premises
Example use cases
- An AI-assisted process that can read freely but must obtain human approval before any irreversible change to a system of record.
- Routing model-proposed actions through policy so that data-sensitive steps are refused or redacted before they reach external tools.
- Producing a replayable evidence trail for AI-driven actions to satisfy internal review after the fact.
- Operating the same governed application across managed cloud, customer cloud or on-prem without rewriting its control logic.
Frequently asked questions
How is Runtime different from just calling a model API?
A direct API call turns a model's output into action with nothing in between. Runtime inserts identity, action classification, policy, approval and an evidence trail between intent and effect. The point is that irreversible actions are governed, not fired automatically.Does Runtime act on its own?
It can carry out low-risk, reversible actions under policy, but higher-risk and irreversible actions are designed to require human approval. The model proposes; people decide where it matters. This is deliberate, not a limitation to be removed.Can we run Runtime in our own environment?
Deployment patterns including customer cloud, private cloud and on-prem are part of the design intent, since portability matters for governed workloads. The exact options for your case are assessed per engagement. Runtime is in private preview, so availability 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 Gateway
Private previewA controlled AI gateway so model access passes through organisational policy instead of scattered API keys.
- Audience:
- Security, platform and data teams standardising enterprise model access.
Octoryn Privacy
PilotSensitive-data controls: detection, redaction and residency-aware handling across the AI path.
- Audience:
- Privacy, risk and compliance functions in regulated organisations.
