How it works
This page explains exactly how Xybern works, the architecture, the 5-stage authorisation pipeline, the policy engine, the identity layer, and the provenance vault. If you are evaluating Xybern for your organisation, this is where to start.
SHA-256 · HMAC-SHA256 · Merkle proofs · Cryptographic agent identity
Not monitoring. Not orchestration. Authorisation. Monitoring tools observe AI after execution. Orchestration frameworks help you build AI pipelines. Xybern does neither. It is the authorisation layer, every agent action must be authorised against policy before it can execute. Keep reading to see exactly how.
Section 01 · The authorisation pipeline
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 authorisation pipeline.
An AI action that has not passed through all 5 stages has not been authorised. Xybern makes unauthorised execution structurally impossible.
Section 02 · Each stage in detail
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
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.
Stage 02
The agent proposing the action is verified against its cryptographic identity before any evaluation begins. Xybern establishes who is acting, what their defined permission boundaries are, and whether their current behaviour is consistent with their historical baseline. An agent whose identity cannot be verified does not proceed.
Stage 03
The xybern-reasoning-v1 model receives the proposed action, the verified identity, the permission boundaries, the active policy set and the jurisdictional context for this action. It evaluates the action against the agent's permissions and policy rules, and produces a structured authorisation determination.
Stage 04
Binary. Authorise or deny. 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 authorisation decision is made in under 50ms. The action either proceeds or it does not. There is no third option.
Stage 05
Every decision Xybern makes, authorised or denied, is written immediately to the provenance vault. The entry contains the full action, the agent identity, the evaluation result, the authorisation 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.
Section 03 · Stage 03 in depth
Most authorisation systems use static rules. 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 permission boundaries, the active policy set and the jurisdictional context. It returns a structured authorisation determination.
Unlike static rule-engines and pattern-matching guardrails, xybern-reasoning-v1 evaluates intent, context, jurisdiction, permissions, and agent history simultaneously, in a single deterministic pass, in under 50ms.
Authorisation response object
Every authorisation decision returns a fully structured object. Not a score, a complete record of what was checked, what permissions were evaluated, and what was decided.
Permission evaluation
Actions are evaluated against the agent's permission boundaries and active policy rules. A single policy violation or boundary breach is sufficient to deny the entire action, there is no partial authorisation.
Adaptive permission scoring
Permission scores update dynamically based on agent behaviour history across all sessions. An agent that has previously exceeded its permission boundary carries a lower baseline score on all future actions until rehabilitated.
Policy authorisation
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.
Section 04 · Stage 02 in depth
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.
Section 06 · Stage 05 in depth
Nothing mutates silently.
Every authorisation 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.
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.
Section 07 · The platform
The Xybern dashboard is your authorisation control plane, not an observability tool. Every entry represents a decision Xybern made before an AI action was allowed to execute: what was authorised, what was denied, which agent triggered it, the permission scope, the policy evaluation, and the cryptographic proof behind every decision. Permanent. Auditable. Court-ready.
Section 08 · Deployment patterns
One authorisation standard.
Xybern supports two deployment patterns depending on whether you are a platform provider embedding authorisation into your AI product, or an enterprise deploying authorisation across your internal AI estate.
Embedded deployment
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, authorised against policy, and recorded before it reaches the user. Your platform gains authorisation and provenance as a native capability.
Centralised deployment
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 authorisation point before any action reaches production.
Section 09 · Integration
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.
Compatible with your stack
Xybern does not replace your frameworks. It is the authorisation layer above them. Your framework builds the pipeline. Xybern decides what it's allowed to do.
Deployment time
API integration
Point your first agent at the Xybern endpoint. First authorised action in under an hour.
Policy configuration
Define permission boundaries, policy rules, and authorisation constraints for your AI systems.
Full deployment
All AI systems routing through Xybern. Full authorisation, full audit trail, full coverage. Every action authorised. Every decision recorded.
Section 10 · Regulated environments
Xybern was designed from the ground up for regulated industries. The authorisation pipeline, the identity layer and the provenance vault were all built with financial services and legal services compliance obligations in mind.
Financial services
Xybern maps directly to SM&CR Senior Manager accountability requirements. Every AI decision is attributed to a specific agent with a specific permission scope and a specific authorisation record. FCA SYSC 8 outsourcing obligations satisfied by design. Full audit trail available for regulatory inspection at any time.
Legal services
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 authorisation. Client data boundary rules authorised at the action level, not the application level.
Enterprise · UK & MENA
Jurisdiction-aware authorisation 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.
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.
