How it works

One system. One job.
No AI action executes without it.

This page explains exactly how Xybern works, the architecture, the 5-stage pipeline, the verification engine, the identity layer, and the provenance vault. If you are evaluating Xybern for your organisation, this is where to start.

5
Pipeline stages
7B
Reasoning model
<50ms
Enforcement latency

SHA-256 · HMAC-SHA256 · Merkle proofs · Cryptographic agent identity

Section 01 · The execution pathway

5 stages. None optional.

Every AI action in your organisation passes through all 5 stages before it can execute. This is not middleware. This is not a monitoring layer. This is the execution path itself.

Diagram 01 — Execution flow
Agent proposes action Xybern intercepts 5-stage pipeline Enforcement decision Vault record
01
Intercept
Action captured before any system can act on it. The pipeline begins here.
02
Identify
Agent cryptographic identity verified. Authority scope established.
03
Evaluate
xybern-reasoning-v1 evaluates claims against identity, policy and jurisdiction.
04
Decide
Binary. AUTHORISE or BLOCK. Deterministic. Under 50ms. No third option.
05
Record
Immutable vault entry. SHA-256 hash chain. HMAC-SHA256 signature. Permanent.

An AI action that has not passed through all 5 stages has not been enforced. Xybern makes unenforced execution structurally impossible.

Section 02 · Each stage in detail

What actually happens inside the pipeline.

The pipeline overview names the 5 stages. This section explains what is passed in, what is checked, and what is returned at each one.

Stage 01

Intercept

Your AI system calls Xybern instead of executing directly. One API endpoint replaces the direct call to your LLM, agent framework or automation tool. The action is held inside the pipeline, it cannot proceed to any subsequent system until all 5 stages complete. There is no way to route around the interception point.

Input: proposed action + agent context + timestamp
Output: action held, pipeline initiated, interception logged
Failure: action rejected before evaluation begins, rejection recorded

Stage 02

Identify

The agent proposing the action is verified against its cryptographic identity before any evaluation begins. Xybern establishes who is acting, what their defined authority boundaries are, and whether their current behaviour is consistent with their historical baseline. An agent whose identity cannot be verified does not proceed.

Input: agent ID + cryptographic signature + behaviour context
Output: verified identity object + authority scope + trust baseline
Failure: unverified agent → blocked immediately, identity failure recorded

Stage 03

Evaluate

The xybern-reasoning-v1 model receives the proposed action, the verified identity, the current trust score, the active policy set and the jurisdictional context for this action. It decomposes the action into atomic claims, evaluates each claim independently against evidence and policy, and produces a structured enforcement determination.

Input: action + identity + trust score + policies + jurisdiction
Output: claim analysis + trust score update + policy flags + enforcement recommendation
Failure: policy violation detected → recommendation = BLOCK

Stage 04

Decide

Binary. Authorise or block. The decision is deterministic, given the same inputs it produces the same output every time. There is no grey zone, no retry, no human-in-the-loop delay. The enforcement decision is made in under 50ms. The action either proceeds or it does not. There is no third option.

Input: evaluation result + trust threshold configuration
Output: AUTHORISE or BLOCK decision object
Failure: trust score below threshold OR any claim fails → BLOCK

Stage 05

Record

Every decision Xybern makes, authorised or blocked, is written immediately to the provenance vault. The entry contains the full action, the agent identity, the evaluation result, the enforcement decision, and a precise timestamp. It is anchored in a SHA-256 cryptographic hash chain with HMAC-SHA256 signatures. The entry cannot be deleted. The entry cannot be altered. The chain itself is evidence.

Input: full decision object + verification metadata
Output: immutable ledger entry + verification ID (vr_...) + hash anchor
Both authorised and blocked actions create a permanent record

Section 03 · Stage 03 in depth

A reasoning model built for enforcement.

Most enforcement systems use rules. Rules are static. Rules do not understand context. xybern-reasoning-v1 is a proprietary 7B reasoning model trained specifically to evaluate AI actions against policies, not to generate outputs. It receives the proposed action, the agent's verified identity, the trust score, the active policy set and the jurisdictional context. It returns a structured enforcement determination.

Verification response object

Every enforcement decision returns a fully structured object. Not a score, a complete record of what was checked, what was found, and what was decided.

verification_response.json
{ "verification_id": "vr_8f3a2c...", "agent_id": "crm-agent-v2", "trust_score": 87, "claims_verified": "4/5", "claims_failed": 1, "policy_flags": 0, "bias_status": "fair", "jurisdiction": "EU", "decision": "AUTHORISE", "latency_ms": 43, "immutable": true, "vault_entry": "vr_8f3a2c..." }

Claim decomposition

Actions are broken into atomic claims. Each claim is evaluated independently against evidence and policy. A single failed claim is sufficient to block the entire action, there is no partial authorisation.

Adaptive trust scoring

Trust scores update dynamically based on agent behaviour history across all sessions. An agent that has previously exceeded its authority boundary carries a lower baseline trust score on all future actions until rehabilitated.

Policy enforcement

Governance policies, regulatory frameworks and internal rules are all evaluated in a single pass by the same reasoning model. SM&CR accountability rules, FCA SYSC obligations and custom internal policies handled uniformly.

Xybern verification engine

Section 04 · Stage 02 in depth

Every agent has a cryptographic identity.

Not just a token.

API tokens tell you which application is calling. They do not tell you which agent within that application proposed this specific action, what reasoning chain it used to arrive at it, or whether its behaviour is consistent with its history. Xybern assigns every agent a persistent cryptographic identity, verified at every stage of every execution.

API token

  • Identifies the application only
  • Static, shareable credential
  • No behaviour history tracked
  • Cannot detect agent drift
  • No policy linkage possible

Session token

  • Identifies the session only
  • Expires and rotates per session
  • No agent-level context
  • Cannot link to enforcement policy
  • No cross-session history

Xybern agent identity

  • Identifies the specific agent
  • Cryptographically bound and verified
  • Full behaviour history tracked
  • Detects drift from established baseline
  • Policy-linked enforcement at every action
Xybern agent identity panel

Section 05 · Runtime enforcement

Every action. Decided. Recorded.

This is Xybern running in production. Every row is a real enforcement decision, an AI agent proposed an action, Xybern evaluated it, and a decision was made. The decisions on the right are final. They cannot be reversed. They are already in the vault.

Diagram 02 — Live enforcement feed Live

Total today

0

Authorised

0

Blocked

0

Verification ID Action Agent Trust Time Decision
vr_a7f3d2... Database query crm-agent-v2 94 12:04:28 Authorised
vr_b2e1c9... Bulk data export crm-agent-v2 41 12:04:31 Blocked
vr_c9d4f1... Outbound email comms-agent-v1 72 12:04:33 Evaluating
vr_d1e8a4... Workflow update ops-agent-v3 88 12:04:37 Authorised
Vault chain: a7f3d2... b2e1c9... c9d4f1... d1e8a4... SHA-256

Section 06 · Stage 05 in depth

Nothing disappears.

Nothing mutates silently.

Every enforcement decision Xybern makes is written to the provenance vault. The vault is an append-only ledger — entries can never be deleted. Each entry is anchored in a SHA-256 cryptographic hash chain with HMAC-SHA256 signatures and Merkle proof verification. The chain itself is the evidence.

Diagram 03 — Provenance ledger
Verification ID Action Agent Trust Timestamp Decision Hash anchor
vr_8f3a... email.send crm-agent-v2 87 2026-03-18 14:02 Authorised a7f3d2...
vr_7b2c... db.update ops-agent-v1 62 2026-03-18 14:01 Blocked b2e1c9...
vr_5d9e... workflow.trigger finance-agent-v3 91 2026-03-18 14:01 Authorised c9d4f1...
vr_3a1f... payment.initiate billing-agent-v2 44 2026-03-18 14:00 Blocked d3a8e7...
vr_2e8d... report.generate analytics-v1 83 2026-03-18 13:59 Authorised e5b2c4...
a7f3d2... b2e1c9... c9d4f1... d3a8e7... e5b2c4... SHA-256 hash chain · HMAC-SHA256 · Merkle proof export

Append-only ledger

Entries cannot be deleted

Once written, permanent. The vault has no delete operation.

SHA-256 hash chain

Entries cannot be altered

Any change to any entry breaks the hash chain, immediately detectable.

Merkle proof export

Chain integrity verifiable

Full Merkle proof export for any compliance audit, on demand.

Xybern provenance vault

Section 07 · The platform

Every decision. Visible. Permanent.

The Xybern enforcement dashboard gives your security and compliance teams a live view of every AI enforcement decision across your entire organisation. Authorised actions, blocked attempts, trust scores, agent identities, policy flags, all visible, all permanent, all auditable. Nothing is hidden. Nothing expires.

Live enforcement feed Agent identity panel Policy configuration Vault export
Xybern enforcement dashboard

Section 08 · Deployment patterns

Two ways to deploy.

One enforcement standard.

Xybern supports two deployment patterns depending on whether you are a platform provider embedding enforcement into your AI product, or an enterprise deploying enforcement across your internal AI estate.

Embedded deployment

Xybern inside your AI product

Xybern integrates directly into your AI platform stack. It sits between your model outputs and your end users. Every output your platform delivers has been intercepted, verified, scored and recorded before it reaches the user. Your platform gains enforcement and provenance as a native capability.

Your model [Xybern enforcement] Your user
  • Single API integration, no infrastructure rebuild
  • Every model output verified before delivery
  • Deterministic trust scores on every output
  • Full audit trail anchored in provenance vault
  • Xybern becomes the enforcement layer inside your product
Most common

Centralised deployment

Xybern above all your AI systems

Xybern deploys as an infrastructure layer that sits above every AI system in your organisation. Internal LLMs, employee copilots, autonomous agents, customer-facing AI, all route through a single enforcement point before any action reaches production.

All AI systems [Xybern enforcement layer] Production
  • All agents enforce through one control point
  • Single policy set across entire AI estate
  • No AI system operates without enforcement
  • Complete cross-system audit trail
  • Jurisdiction-aware enforcement built in

Section 09 · Integration

One endpoint.

Any provider. Any framework.

Integrating Xybern into your existing AI stack requires one change, you call Xybern instead of calling your LLM or tool directly. Nothing else changes. Your existing infrastructure, your existing models, your existing agent frameworks all remain in place.

integration.py
# Before Xybern # Your agent calls the LLM directly response = openai.chat.completions.create( model="gpt-4", messages=messages ) # After Xybern # One line change — Xybern enforces inline response = xybern.enforce( agent_id="crm-agent-v2", action=proposed_action, policy_set="financial-services-uk", jurisdiction="GB" ) # Returns the same response object # Plus the full verification result print(response.verification_id) # vr_8f3a... print(response.trust_score) # 87 print(response.decision) # AUTHORISE

Compatible with your stack

OpenAI Anthropic Google Gemini Meta Llama Mistral Cohere AWS Bedrock Azure OpenAI LangChain CrewAI AutoGPT LlamaIndex Custom agents

Deployment time

Day 1

API integration

Point your first agent at the Xybern endpoint. First enforced action in under an hour.

Week 1

Policy configuration

Define authority boundaries, trust thresholds and policy constraints for your AI systems.

Week 2

Full deployment

All AI systems routing through Xybern. Full enforcement, full audit trail, full visibility.

Section 10 · Regulated environments

Built for environments where AI mistakes have consequences.

Xybern was designed from the ground up for regulated industries. The enforcement pipeline, the identity layer and the provenance vault were all built with financial services and legal services compliance obligations in mind.

Financial services

SM&CR and FCA compliance

Xybern maps directly to SM&CR Senior Manager accountability requirements. Every AI decision is attributed to a specific agent with a specific authority scope and a specific enforcement record. FCA SYSC 8 outsourcing obligations satisfied by design. Full audit trail available for regulatory inspection at any time.

SM&CR SYSC 8 FCA MiFID II

Legal services

SRA obligations and legal AI governance

Every AI action taken on behalf of a client passes through Xybern before it executes. Supervision obligations are met structurally, not by policy documentation but by architectural enforcement. Client data boundary rules enforced at the action level, not the application level.

SRA Legal AI Client data Supervision

Enterprise · UK & MENA

Cross-jurisdiction enforcement

Jurisdiction-aware enforcement means the same policy engine applies different rules depending on where an action originates and where it has effect. UK, EU AI Act and MENA regulatory contexts are all handled in a single Xybern deployment, no separate configurations required.

UK EU AI Act MENA Cross-border

Seen enough?

Let's deploy it.

Start with a design partnership. We work directly with your team to deploy Xybern into one workflow in under two weeks. No lengthy procurement. No infrastructure rebuild. One endpoint.

Request a pilot Talk to the team