ARCHITECTURE

Designed for zero-trust agent systems

See where policy runs, records are signed, and evidence becomes independently verifiable.

SYSTEM OVERVIEW

End-to-end architecture

SDK

in-process

Runs inside your application. Governs documented provider, framework, and tool routes with no network hop for local policy evaluation.

Ingest API

stateless

Receives signed events from the SDK. Validates signatures. Routes to the ledger. Horizontally scalable, stateless.

Ledger

append-only

Append-oriented event storage with daily Merkle roots and external anchors for independent verification.

Dashboard

query & export

Query, search, and export audit records. Generate compliance evidence packages. Role-based access control.

SIGNED DEPLOYMENT COVERAGE

Assert the boundary. Do not assume it.

Coverage attestations identify what a deployment expected to bind, what actually bound, and what remains excluded.

Name the deployment

Bind workload, environment, SDK version, and deployment identity into one bounded statement.

Declare required boundaries

Record the exact provider, framework, MCP, tool, or application-function symbols expected to enforce, plus explicit exclusions.

Sign what was observed

Sign the binding report so a verifier can compare the deployment claim with the public SDK contract. The attestation does not invent visibility into calls the process never intercepted.

OPT-IN STRICT EXECUTION

Commit the decision before the call

On selected unary OpenAI, Anthropic, and Gemini methods, strict mode requires a signed receipt, positive admission, and durable checkpoint before the provider is contacted. Ordinary wrappers remain broader; strict mode is narrower and fails closed on unsupported surfaces.

Bind the exact action

The cleaned provider request, target, identity, policy context, and requested scope are bound into one decision.

Sign the receipt

A configured device key signs the decision receipt so later verification does not depend on the runtime's API key alone.

Admit and commit

The exact receipt must be positively admitted and saved to a durable atomic checkpoint before execution can begin.

Start once

Only an allowed, still-matching invocation reaches the selected provider. Unsupported strict surfaces fail closed.

Record the outcome

A signed terminal outcome or explicit uncertain state stays bound to the admitted decision and durable journal.

CRYPTOGRAPHIC CHAIN

From event to proof

HMAC-SHA256 Signing

Each emitted SDK event is signed over a canonical decision record and linked to the previous signature. Ingest verifies the chain and adds a server countersignature.

Merkle Tree Indexing

Accepted events are folded into a daily, domain-separated Merkle tree. The versioned root binds the accepted event fields for that day and supports independent verification.

WORM Storage

Merkle roots can be written to S3 Object Lock. Governance mode protects the retention window but can be bypassed by specifically authorized AWS principals; compliance mode is available by agreement.

GitHub Anchor

For maximum transparency, Merkle roots can be committed to a public or private GitHub repository. This creates an independent, timestamped witness of your audit trail.

The full proof story lives on Govern & Prove

DATA FLOW

What stays local vs. what reaches obsvr

Stays in your infrastructure

API keys and credentials
Provider authentication
Application state
Content excluded or redacted by policy
Caller-owned request objects

Reaches obsvr

Signed event metadata
Content hashes (SHA-256)
Policy evaluation results
Token counts and model identifiers
Merkle tree positions
Captured prompt/response values when configured

RESILIENCE

What happens when obsvr is unreachable

Policy failure behavior is configured; audit delivery is asynchronous and bounded. The SDK records the loss classes it can see instead of promising lossless delivery.

Policy stays in process

Local policy evaluation continues without a network round trip. External-policy failures resolve according to the configured fail-open or fail-closed mode.

Delivery is bounded

Signed events enter a bounded in-memory queue. Overflow and terminal delivery failures are counted; future chains can declare the loss with signed gap markers.

Recovery has explicit limits

A graceful flush drains retained work when delivery recovers. Abrupt process death or an undeliverable gap marker can still leave evidence unavailable, so local counters and operations matter.

ISOLATION

Multi-tenant by design

Every tenant is cryptographically and logically isolated. Namespaces enforce strict boundaries across the entire stack.

Tenant-bound API keys and server-side attribution
Customer-scoped daily roots and storage prefixes
Tenant-scoped RBAC for dashboard access
Customer-scoped dashboard and evidence access
Storage-path and authorization checks at backend boundaries