EDEFENSIVE INTELLIGENCE
Defensive
Intelligence
OBEL GaaS - API access by partnership, not self-serve signup

OBEL GaaS

The governance control plane for non-deterministic software.

Data scrubbing, policy enforcement, consequential-action gating, human approval, and tamper-evident audit - 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.

Talk to usRead the API docs

Usage-based pricing, set per partnership - not a self-serve plan.

Not a mockup

Every capability above is a real request against production.

Who this is for

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. 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

Six endpoints. One control plane. Real production traffic already.

Data Scrubbing

POST /v1/scrub

Strip sensitive data before it reaches a model.

The same PII/secret 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

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

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.

Full API reference and connector guide →

How it's priced

Usage-based, not per-seat.

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.

Partnerships, not signups

Stop building governance. Embed it.

Bring your use case. We'll walk through the API against your specific integration and scope a partnership that fits your volume and deployment needs.

Talk to usHow OBEL protects data