Overview

Authorisation¶

Pre-execution AI governance layer that intercepts every AI action before it reaches any real system. Enforces rules, manages agent trust, and records immutable audit trails.

How you author enforcement¶

You do not hand-write rules. You declare outcomes and Xybern compiles them:

Mandates & Charter is where you work. Declare an outcome in plain English ("no personal data may leave the organisation") or build one from a guided picker, and Xybern compiles it into the right mix of enforcement. The signed collection of your mandates is your Charter.
Rules is the audit view of every enforcement rule actually in force, from your Charter, agent boundaries, and bundles. This is what the engine evaluates on each action.
Rules as Code is the versioned, deploy-and-rollback layer for managing enforcement in code (CI and GitOps).

Info

ℹ️ How it works: Your AI agents call /v1/enforce/intercept before executing any action. The control plane evaluates rules, checks agent trust, and returns allow , block , or escalate . Every decision is recorded in the Authorisation Layer Vault hash chain.

Architecture¶

Agent wants to execute_trade
    ↓
POST /v1/enforce/intercept  (+ optional signed_assertion for identity)
    ↓
┌──────────────────────────────────────┐
│  Identity Verification  (< 1ms)       │  ← Ed25519 sig + Redis nonce dedup
└──────────────────────────────────────┘
    ↓
┌──────────────────────────────────────┐
│  Rule Engine                          │  ← All active rules evaluated
│  • action_type  - name matching       │
│  • threshold    - trust level         │
│  • content      - regex patterns      │
│  • temporal     - hours / days        │
│  • chain        - delegation depth    │
│  • identity     - DID / scope rules   │
│  • metadata     - field comparisons   │  ← notional_usd > 100k, ticker == X, …
│  • semantic     - LLM-judged intent   │  ← catches paraphrase / obfuscation
│  • composite    - AND / OR combiner   │
└──────────────────────────────────────┘
    ↓
┌──────────────────────────────────────┐
│  Decision                             │
│  allow    → fast path (~5ms)          │
│  block    → fast path (~5ms)          │
│  escalate → human review queue        │
└──────────────────────────────────────┘
    ↓
Vault entry + decision returned to SDK / caller

Decision Paths¶

Path	Latency	Description
`fast`	~5ms	Rule directly blocks or allows, no LLM call
`standard`	3-5s	Full LLM verification runs against the action content
`escalation`	,	Action held for human review in the escalation queue

Rules are not static rule-matching¶

Xybern rules adapt at runtime — adaptive agent trust, full LLM verification on the standard path, behavioural baselining, and shadow-mode measurement — and the semantic rule type judges an action's intent against a plain-English rule, catching paraphrase and obfuscation that regex cannot. You can author rules in plain English and backtest them against real history before they go live. See Semantic Rules & Natural-Language Authoring.