The governance control plane for non-deterministic software.
Data scrubbing, reversible tokenization, policy enforcement, consequential-action gating, human approval, injection detection, tool-call classification, usage governance, and tamper-evident audit with compliance export - the same engines that govern OBEL's own product, exposed as one API. Embed governance into your AI product instead of building it.
For platforms embedding AI into products they sell to their own customers - not an end-user tier.
Usage-based pricing, set per partnership - not a self-serve plan.
How it fits into your platform
Not a proxy. A call-out at the moment it matters.
Your Platform
A prompt, an agent tool call, or a data request about to happen
OBEL GaaS
Scrub · tokenize · classify · policy · approve
Your Platform Proceeds
Cleaned data and a verdict back - the model call, tool execution, or storage is still yours
Every call, regardless of outcome
Appended to your org's hash-chained audit ledger
Not a mockup
Every capability above is a real request against production.
This exact call scrubs the payload, appends a hash-chained event to your org's audit ledger, and returns the cleaned text plus a structured hit list - no separate logging step, no sandbox mode.
You're shipping AI inside a product. Your customers are asking who governs it.
Platform vendors
The problem
You've added AI features to your product. A regulated customer - a bank, an insurer, a government buyer - asks what governs the model calls, who approves consequential actions, and whether any of it is auditable. Building that yourself means owning a scrubbing engine, a policy DSL, an approval workflow, and a tamper-evident log - none of which is your product's actual value.
What GaaS does
Embed OBEL GaaS instead. One API call answers each question with infrastructure already carrying real production traffic - not something built under deadline for one deal.
Agent framework builders
The problem
Your framework lets developers wire up autonomous agents with real tool access - file systems, APIs, payment rails. Every deployment of your framework needs its own answer to "what stops the agent from doing something irreversible," and today that answer is whatever each developer happens to build.
What GaaS does
Point agent tool calls through /v1/actions/evaluate. Consequential and irreversible actions get gated and routed to a human by default, consistently, across every deployment of your framework.
Regulated-industry SaaS
The problem
You sell into finance, healthcare, or government, and your own AI features now need to meet the same bar your core product already meets - EU AI Act, NIST AI RMF, SOC 2, ISO 27001/42001, APRA CPS 230/234. Retrofitting that bar into an AI feature you shipped fast is expensive and slow.
What GaaS does
GaaS's audit chain and access-control layer map directly onto those frameworks' evidence requirements - the same mapping OBEL's own compliance reporting already produces.
Live today
11 endpoints. One control plane. Real production traffic already.
Data Scrubbing
POST /v1/scrub
Strip sensitive data before it reaches a model.
The same ARGUS-i detection and sovereign classification engine that protects OBEL's own chat traffic, callable directly. Emails, credentials, financial data, and org-defined patterns are detected and redacted; a sovereign classification score flags content that should never transit at all.
Real-time detection and redaction, sub-second per call
Sovereign classification score (PSPF-aligned) on every response
Org-configurable rule set - same engine, no new integration per rule
Reversible Tokenization
POST /v1/tokenize
Protect it from the model. Get it back for yourself.
Scrubbing destroys the original value - tokenization preserves it, encrypted, behind a session you control. Emails, phone numbers, card numbers, and more become stable tokens a model can reason about structurally, without ever seeing the real data.
Same entity, same token, across every call in a session
Original values recoverable via /v1/detokenize - nothing lost, nothing exposed
Encrypted server-side; your integration never handles the token map
Policy Engine
POST /v1/policies
Declare rules once. Every call answers to them.
Define allow / warn / block / require-approval rules matched on event type, risk tier, or caller-defined resource type - most specific match wins. Every governed call (scrub, action evaluation, access check) is evaluated against the same rule set, so policy doesn't fragment as integrations grow.
Declarative rules, not per-integration conditional logic
Falls back to a simple risk-tier default for orgs with no custom rules
One rule set governs data, actions, and access checks alike
Consequential Action Gating
POST /v1/actions/evaluate
Gate the actions that can't be undone.
Submit a proposed action with a risk tier - reversible, consequential, or irreversible - and the policy engine decides whether it proceeds automatically or waits on a human. Publishing, financial transfers, deletions: classified before they execute, not audited after the fact.
Per-org configurable risk threshold, or fully custom rules
Same gate for a chatbot, a workflow, or an autonomous agent
Decision recorded before the caller is told to proceed
Access & Data Control
POST /v1/access/check
Decide what a caller may read or retain - before it happens.
Every read or retain request is checked against the org's configured classification ceiling and retention policy before it's granted. A caller asking to retain data above policy is blocked at the gate, not flagged in a report three weeks later.
Hard ceiling by data classification, independent of any policy rule
Configurable retention window enforced at the point of the request
Same evaluator as every other GaaS surface - one place rules live
Human-in-the-Loop Approval
POST /v1/approvals/:id/decide
A person signs off on what the policy engine flags.
When a call trips a policy rule or risk threshold, it lands in a structured approval queue with full context - the action, the data, the rule that triggered it. Approve, reject, or let it expire; the outcome is itself an audited event.
List, filter, and decide pending approvals via API
Full context on every request: action, risk tier, submitted data
Every decision - and who made it - becomes part of the record
Tamper-Evident Audit
GET /v1/audit/events
One hash-chained ledger. Verifiable, not just claimed.
Every scrub, policy decision, approval, and outcome is appended to a per-org, hash-chained, append-only ledger. Call the same endpoint that writes it to recompute every hash and get a live verdict - altering a past entry breaks every hash after it, and that's detectable independently of OBEL.
Hash-chained: prevHash + entry content → entryHash, per org
GET returns a live-recomputed integrity verdict, not a static log
Full lineage: scrub → policy decision → approval → outcome
Prompt Injection Detection
POST /v1/injection/check
Catch hijacked instructions, not just leaked data.
A separate concern from scrubbing: detects text trying to override an LLM's instructions, whether it came from a user or from tool/retrieval output your agent is about to read. Gate agentic tool calls and RAG chunks on injection risk independently of any PII check.
Scores user input and tool/retrieval output separately
Returns a block recommendation by severity - enforcement is your call
Same engine that protects OBEL's own CLI-proxy traffic
Agent Tool-Call Classification
POST /v1/agent/tool-call
Know what a tool call resembles before it runs.
Submit a tool name, description, and parameters before executing it, and get back which MITRE ATT&CK techniques the call resembles - discovery, credential access, exfiltration - the same classification OBEL runs internally on its own agentic traffic.
Deterministic classification - no LLM call, no added latency budget
Flags reading SSH keys, cloud credential dumps, and exfil-shaped commands
Feeds the same policy engine as every other GaaS surface
Usage & Cost Governance
GET /v1/usage
Know your governed-call volume before the invoice does.
Every governed call counts against the org's current calendar month. Configure an optional cap per partnership; calls beyond it return 429 instead of failing silently or running up an unexpected bill.
Derived directly from the audit ledger - nothing to drift out of sync
Checking usage never itself counts against the cap
Per-org monthly cap configurable by your account team
Compliance Export
GET /v1/compliance/export
Hand over the evidence, not a support ticket.
Export the org's audit ledger for a date range as JSON or CSV, with a chain-integrity verdict included, so your customer's auditor gets a self-contained answer instead of a request that lands on your engineering team.
JSON or CSV, filterable by date range and event type
Chain-integrity verdict included in every export
No UI to build - one endpoint per partner, however many customers they have
Integration
One key, every endpoint.
REST API
Direct calls from any backend, authenticated with an org API key (`Authorization: Bearer obel_sk_...`).
Separately scoped keys
GaaS keys are distinct from OBEL Developer CLI-proxy keys - each only works for its own surface, so a leaked key can't reach the other.
SDKs
Thin client libraries wrapping the REST surface - in development.
GaaS is priced on governed-call volume - scrub calls, policy evaluations, access checks, approvals - with committed-use bands set per partnership. There's no per-seat pricing here: the caller is your product, not an individual user.
Deployment options - shared SaaS today, customer-VPC and air-gapped for regulated and sovereign buyers - are scoped per partnership as volume and requirements grow.
Built and backed by ninthLABS
Not a side project. A dedicated team running this in production.
OBEL and GaaS are built and operated by ninthLABS Ventures - the same team architecting ARGUS-i, running it against OBEL's own product traffic, and maintaining the infrastructure your integration would depend on. When you embed GaaS, you're not adopting a solo founder's side project - you're plugging into infrastructure a formidable engineering team builds and supports full-time.
Integration support, not just an API key
ninthLABS' Professional Services team - the same group that onboards OBEL's Enterprise and Government customers - can scope and support your GaaS integration directly: technical onboarding, policy configuration, and ongoing optimisation as your usage grows.