ArchitectureHow Obiguard works — from request to ledger

One inspection layer.
Every model your
org touches.

Obiguard sits in front of your AI calls as a lightweight proxy. Prompts and responses pass through the inspection pipeline — where policy is evaluated, violations are surfaced, and evidence is written to the ledger. Streamed responses are checked once delivered.

01 / The Proxy

Drop-in. No model changes.

Obiguard speaks the same API as OpenAI, Anthropic, Bedrock, Vertex, and Azure OpenAI. Point your existing SDK at our gateway — nothing else changes.
STEP 01 · ROUTE

Your SDK, unchanged

Set OPENAI_BASE_URL (or the equivalent for Anthropic, Bedrock, Vertex) to your Obiguard gateway endpoint. All existing code continues to work.

# one env var
$ export OPENAI_BASE_URL=
  https://gateway.obiguard.ai/v1
→ traffic now flows through Obiguard
STEP 02 · INSPECT

Inline inspection pipeline

Each request and non-streamed response passes through the inspection pipeline: PII detection, injection classifiers, and your custom Policy Sets — all evaluated before the call completes. Streamed responses are evaluated after delivery.

prompt → inspect → block
response → inspect → redact
response → inspect → flag
in-path · before the call completes
STEP 03 · ENFORCE

Policy decision & action

If a violation matches a Policy Set, Obiguard takes the configured action — block, redact, flag, or hold for human review. Held requests wait in the Review Queue for approval or rejection.

policy_set: no-pii-in-responses
action: block
review_queue: true
→ written to audit log
02 / Platform Components

What's inside the platform.

Each component is independently useful — together they give you complete visibility and control over every AI agent in your organisation.
GATEWAY

Inspection proxy

A lightweight HTTP proxy that speaks OpenAI, Anthropic, AWS Bedrock, Google Vertex, and Azure OpenAI. Evaluates each request and response against your active Policy Sets before forwarding.

POLICY ENGINE

Policy Sets & Criteria

Policy Sets group enforcement rules (Criteria) and are assigned to specific AI Agents. Each rule defines a guard or criterion, a scope (prompt, response, or both), and an action. Policy Set versions move from draft through pending review and approved to published.

VIOLATION PIPELINE

Violations & Review Queue

Every policy breach creates a Violation record with the full event context. Violations can be auto-resolved or routed to the Review Queue for human annotation. All decisions are written to the Audit Log.

REGISTRY

AI Agents & Use Cases

A project-scoped registry of every AI Agent and Use Case your team has defined. Agents are linked to Policy Sets — ensuring enforcement follows the workload. Use Cases capture the business intent behind each agent.

LEDGER

Audit Log

Timestamped records of requests, policy decisions, and configuration changes, exportable to CSV or JSON for auditors.

GOVERNANCE

Controls & Criteria

Org-level Controls define what behaviour is prohibited or required. Each Control maps to one or more Criteria, and carries an approval workflow with segregation of duties — a submitter cannot approve their own control.

ASSURANCE

Evaluation service

An embedded Project Moonshot backend from AI Verify Foundation. Benchmark runs (cookbooks and recipes) and red-teaming attack modules execute against a registered agent; api-service resolves the provider connector and injects the token per run, so the portal never handles a credential.

ETHICS ENGINE

Nightly bias evaluation

A scheduled job runs at 03:00 UTC, samples ~17% of the previous day’s traces, and scores each against six LLM judge criteria. Fully asynchronous — it reads traces after the fact and never sits on the request path.

COMPLIANCE

Framework coverage

A coverage endpoint computes, per framework category, whether your live platform activity evidences it — covered, partial, or not covered — across NIST AI RMF, ISO/IEC 42001, OWASP LLM Top 10, Malaysia’s AISCF, and Singapore’s MGF for GenAI. Each mapping records the standard edition it was made against.

03 / Integrations

Works with your existing stack.

Obiguard is complementary to your AI gateway, not a replacement. It adds the governance layer that routing tools leave out of scope.
AI PROVIDERS

Any OpenAI-compatible endpoint

OpenAI, Anthropic, AWS Bedrock, Google Vertex AI, Azure OpenAI, and any self-hosted model behind an OpenAI-compatible API. No special SDK required — just change the base URL.

OpenAI · Anthropic · Bedrock
Vertex AI · Azure OpenAI
+ any OpenAI-compatible host
EVIDENCE

Export for your auditors

Export request records, policy decisions, and the Audit Log to CSV or JSON, plus framework coverage as CSV, for an ISO/IEC 42001 audit without manual evidence collection.

export → csv · request records
export → json · complete record
+ framework coverage csv
04 / Deployment

SaaS or inside your VPC.

Obiguard runs wherever your data needs to stay. In-memory processing in SaaS mode means content is never stored — only the policy decision and metadata reach the ledger.
SAAS

Hosted by Obiguard

Connect in minutes. Content is processed in-memory and never stored. Only policy decisions and metadata are persisted. Ideal for teams that want governance without infrastructure overhead.

VPC

Deploy in your cloud

Run Obiguard inside your AWS, GCP, or Azure VPC. Outbound traffic is limited to the model providers and services you configure. Enterprise customers receive private container images with a Docker Compose quickstart — your team owns the deployment, we own the updates.

RESTRICTED

Restricted networks

For regulated industries that limit outbound connectivity. Obiguard runs behind an internal image mirror with outbound traffic limited to the destinations you allow. Fully air-gapped operation is on the roadmap.