Platform · Layer 3 · Generally Available
Sovereign Agent. The governance layer for every AI action.
Live today. Agent identity, five-layer policy evaluation, cryptographic audit, human-in-the-loop oversight — the gate every AI action passes through. Deployed as the platform foundation, or standalone for enterprises already building on LLMs.
The problem
Every enterprise AI deployment needs a governance layer — and Sovereign Agent is that layer.
Your systems of record enforce fine-grained auth. Off-the-shelf agents inherit none of it. Your data carries PII, PHI, or classified tags that must stay inside your tenancy. Your compliance org needs every decision replayable and every call fully logged. The gap sits at the governance layer the category skipped — and Sovereign Agent fills it, live today.
How it works
Five checkpoints. One governed action.
Every AI action flows through the same five checkpoints, regardless of the model, the tool, or the deployment mode. The gate is the product.
Agent request
Any AI action bound for a system of record enters the governance layer before it executes.
Identity & trust
Trust Registry verifies the agent's cryptographic identity, capability manifest, and current trust tier.
Five-layer policy
Access Broker evaluates employment, compliance, role, device/network, and action policies — in parallel.
Decision
Allow, deny, or route to a human for approval. Risk-scored, policy-versioned, deterministic.
Audit-logged action
Provenance records the decision and its rationale as a tamper-evident event — independently verifiable for seven years.
Data stays inside your environment. Every action is identity- verified, policy-filtered, and cryptographically logged — whether the agent runs in GovCloud, on-prem, or fully air-gapped.
See it defined
Policy your engineers write, review, and ship.
The five-layer evaluation is declarative. Each policy is a file in your repo — branched, pull-requested, CI-tested, and diffable like any other code artifact. Pure policy-as-code. Compliance can read it. Engineers can test it. Auditors can verify it matches the events produced.
Every field below has a corresponding line in the audit event it produces.
# policy/portfolio-agent.yaml
# versioned in git · code-reviewed · CI-tested
agent: portfolio-summary-agent
trust_tier: GOLD
layers:
employment:
require: active_employee
source: okta
compliance:
require: [finra_licensed, training_current]
source: workday
role:
allow: [portfolio-analyst, senior-pm]
deny: [intern, contractor]
device:
require: [managed, mtls_cert]
network: [corp_vpn, zscaler]
action_rate:
limit: 100/min
burst: 150
on_threshold_exceeded: route_to_hitl
audit:
retention: 7y
worm: true
merkle_chain: trueRepresentative policy · one of many shipped per agent
See it run
Every agent action, independently verifiable.
A single agent request generates a tamper-evident event — thought, policy evaluation (with per-layer latencies), tool call, observation, decision, response. Merkle-chained to its predecessors. Seven-year WORM retention. Your auditor can verify completeness from the signed audit record alone.
This is the evidence that powers every claim on our trust page.
Agent portfolio-summary-agent-v3 (trust tier: GOLD)
Request 2026-04-22 14:32:17.041 UTC
├─ Thought "Pull Q3 client portfolio risk exposure"
│
├─ Policy check ✓ ALLOWED
│ Layer 1: employment active 0.04 ms
│ Layer 2: compliance current 0.11 ms
│ Layer 3: role portfolio-analyst 0.08 ms
│ Layer 4: device managed + mTLS 0.06 ms
│ Layer 5: action-rate 47 / 100 per min 0.02 ms
│ ───────────────────────────────────────────────────────
│ total 0.31 ms
│
├─ Tool call rbac_query("portfolio", client_id=***)
├─ Observation "23 holdings · 4 flagged for review"
├─ Decision summarize + redact PII
└─ Response delivered · logged
Event hash 3f2a9c…b7e1
Parent hash 8d1c4f…f42c
WORM retention 7 years · externally verifiableRepresentative event · client identifiers redacted
Three products, one layer
Buy the bundle. Or just the piece you need.
Each is a standalone product. Each generates the artifacts the other two build on.
Product 1
Access Broker
Sub-millisecond authorization with five-layer policy evaluation — the gate every request passes through.
Central Policy Engine evaluates employment, compliance, role, device/network, and action-level permissions in parallel. Risk-scored. Routed to human-in-the-loop when threshold is exceeded. Policy-as-code: versioned, reviewable, testable — the same way your engineers ship code.
Product 2
Trust Registry
Agent identity, capability manifests, behavioral drift detection.
Cryptographic identity per agent. Behavioral baselines update continuously. Anomalous agents are throttled, suspended, or revoked — automatically.
Product 3
Provenance
Cryptographic audit. 7-year WORM. Independently verifiable.
Every session recorded as a tamper-evident tree. Regulators verify completeness from the signed record alone.
What each team gets
One product. Three audiences solved.
For compliance
Regulator-verifiable audit from signed records alone. Policy versioned like code. Every action replayable. Seven years of WORM retention.
For security
Your existing RBAC/ABAC model is inherited, not bypassed. Declarative PII boundaries. Sub-ms authorization across five parallel policy layers.
For AI platform teams
Additive to AWS AgentCore, Azure, or your existing LLM stack. Three adoption patterns: SDK, gateway proxy, or standalone broker. Slots in alongside what you already run.
Integration
Three ways to adopt. Pick the one that matches your stack.
Additive by design. SA slots in alongside AWS AgentCore, Azure's agent stack, or a runtime you built yourself — your model layer stays yours, your existing stack stays in place.
Pattern 1 · SDK
In your agent runtime.
Import the library, wrap each tool call. Policy checks run inline; the audit trail is produced by your own process.
from sovereign import guard
@guard(tier="GOLD")
def run_tool(ctx, call):
return client.invoke(call)Teams building agents in-house on LangGraph, CrewAI, or a custom runtime.
Pattern 2 · Gateway proxy
In front of your model and tool calls.
Point an existing agent at an SA endpoint. Zero code changes in the agent itself; policy and audit run at the boundary.
# no code change — just redirect OPENAI_BASE_URL=\ https://sa.yourorg.internal/v1 SA_AGENT_ID=portfolio-agent
Vendor agents you can't modify or legacy pipelines mid- migration.
Pattern 3 · Standalone broker
Between your agents and your systems of record.
Run SA as a central gate for a heterogeneous fleet. Every agent negotiates with the broker before it touches a system of record.
N agents
|
v
[ SA broker ] <-- one policy set
|
v
M systems of recordPlatform teams governing many agents against many systems, with one central policy surface.
In production today
40M+ documents governed at a top-tier US financial services firm. PII retained in tenant.
Where Sovereign Agent shows up.
See a governed agent run end-to-end.
30-minute walkthrough: one request, all five policy layers, the audit event it produces. Your hardest governance constraint is the brief.