Skip to content

Changelog

All notable changes to Xybern are listed here. Xybern follows Semantic Versioning.

2026-09

  • Authority Bundle. The whole workspace as one signed document of the eight primitives (xybern-authority-bundle-v1): every agent with its passport, every authority held and by whom, the action types, resource classes, missions, sessions, rules, communication rules and budgets, a summary of the decisions, the evidence counts, the findings, the invariants and the public keys, signed with the Vault signing key and verifiable offline. Downloaded from the Authority model page by workspace admins; a bundle file can be checked there too.
  • The Authority model in time, and before you sign. The model page shows the eight as they stood at any moment, counted against now, and what changed since in dated sentences (agents, trust, lending, warrants, Charter versions, missions, passports, decisions by outcome, findings opened or closed). A proposal (a mandate, a lending, taking one back, a trust state, an agent acting only with what it is lent) shows the findings it would close or open and the principals it touches, with nothing written and a link to where it is signed. Findings can be read as of any moment.
  • Walk the ontology on real data. Every record opened on the Authority model page shows the relations it takes part in, in the words of the ontology (holds, can, over, lends, may instruct, declares, bounded by, produced, proved by, held by, issued by, grants, compiled into, performed by, under, an instance of, serves, in the same chain), each listing the real things at the other end; clicking one walks to it, a trail in the colours of the eight shows the walk and takes you back, and the diagram selects the primitive you are on. A decision opened this way offers its own record and its reading through the ontology.
  • The Authority model says what is missing. Findings derived from the relations between the eight primitives, on the workspace's own data over 30 days: an agent lent nothing that acts only with what it is lent, standing authority nothing narrows, a restricted or quarantined agent, no passport, no mission, an action performed that no rule speaks about, a resource class no rule bounds, decisions not sealed, a mandate that never matched, lent authority used up or ending. Each is a plain sentence with the place that fixes it, warnings first, and the ones that concern a primitive show beside its instances. A decision record, a held action and every agent in Passports now open the model on the fitting question (Through the ontology, What can this agent do?).
  • The Authority model is now the map of the workspace. The page opens with three questions, answered as the eight rows from the workspace's own data: what can this agent do, who can do this action or reach this resource, and why was this decision made. Every answer names real things and each one opens in place. Clicking a primitive lists what the workspace holds of it (agents, mandates, lent authority, warrants, action types, resource classes, missions, sessions, rules, decisions, receipts, stamps, attestations, passports), grouped and newest first, each opening as plain facts. An agent that acts only with what it is lent reads as such throughout. The formats, retention and raw slice resolver moved under For engineers. The diagram is unchanged.
  • A refusal by a binding check no longer shows a Risk Verdict of 0. When an action is refused before the verdict weighs in (no lent authority, a communication rule, a warrant, a revoked agent, a paused workspace) the Authorisations table shows "rule" in the verdict column and the decision record shows the verdict's own blend, marked advisory, with a line saying the decision was made by a binding check. The engine records the same as before; only the reading changed.
  • Authority model · Ontology, and the Builder canvas. The Authority model page now opens with the ontology in one sentence, each word the colour of its card and a click away from it; each primitive shows what it is, the invariants that govern it and real examples from the workspace; Read a decision through the ontology shows what each of the eight was for any recent decision, from the Authority Slice sealed with it; relations explain themselves on hover; every invariant is stated in plain words next to its formal statement. The diagram is unchanged. On the Authority Builder canvas, relations between agents (who may instruct whom, what is lent) are drawn as separate, labelled, coloured loops with a legend, a click on one shows its detail, empty columns say so, and a plan names agents rather than ids.
  • Models. The Authorisation Layer now asks Claude Sonnet 5.5 first for compiling (mandates, A2A Delegations, access profiles, intent contracts, policy import) and for the semantic judge, and falls back to DeepSeek V4.1 Flash (deepseek-flash), replacing Claude Sonnet 4.6, Claude Haiku 4.5 and the deprecated deepseek-chat. Both models think before they answer, so every request now carries room for the answer after the thinking. XYBERN_LLM_MODEL, XYBERN_LLM_COMPILE_MODEL, XYBERN_DEEPSEEK_MODEL and XYBERN_DEEPSEEK_COMPILE_MODEL still pin a deployment to a model of its own.
  • A2A Delegations, written in plain language. The Delegations view is now A2A Delegations. You write who may hand work to whom and what is lent, in your own words and any language, and the view compiles it the way the Charter compiles a mandate: the model reads the text against the agents, departments and actions of the workspace, rules check every statement it returns, and nothing is created until a person signs. It understands who may instruct, delegate to or query whom (an agent, a department, any agent), the default, lending with a limit on actions, an amount, rows or recipients, counted for each task or in all, for how long, whether it may be lent on, an agent that acts only with what it is lent, and taking any of these back. An agent that is not clearly named is reported, never guessed. "In force now" lists what holds in words, with who wrote it. When no model answers, a built-in reader reads plain sentences and says so.
  • Lend authority from the dashboard. The Authority graph has a Lend authority form: from one agent to another, the actions lent, a limit, counted for each task or in all. Selecting an agent on the map offers "Make it act only with what it is lent". Lending is refused while the communication rules do not let the first agent instruct the second. A communication rule nobody named now reads in words, for example "Triage may not instruct responder". A plan no longer reports a change to the communication default for a document that does not set one.
  • Agents that hand work to other agents (SDK 2.24.0, dashboard). When one agent runs another, the SDK authorises the hand-off as an instruction before the second agent reads it, so the communication rules decide who may instruct whom with no change to the program. What the second agent does is done for the first, under the authority the first lent it: an action outside the grant or beyond its budget is refused. A budget on a grant can be counted for each task (per: chain) as well as over the life of the grant. Every action and hand-off of one request carries the same chain, and the decision record shows the chain in order, who acted for whom and what was lent, with one click to see the chain in the Authorisations table. A Charter file now names agents, not ids: applied in any workspace it finds the agent of that name, or creates it. A new grant raises the trust signal once, not on every use. The budget of a grant is counted under a lock, so actions asked for at the same moment cannot both take the last unit.
  • Choose which agents are authorised, and see every decision as it happens (SDK 2.23.0). xybern run prints one line per decision (allowed, held, approved, refused) with the agent and the mandate that decided. An agent the framework names, such as a LangChain agent created with a name, gets its own identity, so a program with several agents shows each one in the Registry. --agents authorises only the agents whose name matches and --skip leaves chosen action types alone (XYBERN_AGENTS, XYBERN_SKIP).
  • The agent's reason on every LangChain action (SDK 2.22.1). What the model said when it chose a tool now travels with the action as the agent's reason, so the decision record shows why the agent wanted to act next to why the layer decided as it did. Observe records that were being sent when a program exited are no longer lost.
  • Held actions through the self-hosted relay (relay 1.3). When the relay decides that an action needs a person, it records the decision with the control plane before answering and returns the escalation, so the agent waits and continues once a person approves in the dashboard. Only the metadata record is sent, the content stays on the host.
  • Run an agent under authorisation with no code change (SDK 2.22.0). xybern run --agent soc-agent python agent.py runs a program with every agent action authorised, the file itself untouched. --agent (or auto.connect(agent=...), XYBERN_AGENT) gives the process one identity: it is registered once with its tools as capabilities and every tool call is attributed to it. LangChain tool arguments now reach the Charter as metadata, so rules on argument values decide. In enforce mode an escalated action can be held for a person (escalation_wait, --wait) and continues on approval, and a refusal carries its reasoning to the agent. Queued observe records are sent when the program exits. The LangChain callback handler now stops a refused tool call (it sets raise_error, without which LangChain logged the refusal and ran the tool).
  • Open standard and closure (Authorisation Layer, Phase 10, the programme's last phase). The open formats bundle v1 is published: receipt, warrant, stamp, execution attestation, lineage, pre-flight answer and issuer record with canonicalisation rules, a test key, 21 test vectors and a conformance suite any implementer can run; the warrant and stamp specs are final. XAAB gained an authority_attacks category (forged warrant, confused deputy, fabricated grant, forged and missing stamps, undeclared commitment, self-approval, shared-limit burst) and the adapter passes intercept-level inputs like a real client. The cross-install counterparty handshake seals a receiver's decision in a remote issuer's Vault. The compliance pack is refreshed with a feature coverage map, a rewritten policy 11 section 3, re-rated SAMA CSF 3.3.4 and 3.3.5, and a receiver guide for banks. The Authorisation Layer's Authority group now holds Charter, Warrants, Stamps, Requests and the Authority graph together, and onboarding gained "issue the first warrant" and "attach the first stamp".
  • Execution attestation and profile derivation from facts (Authorisation Layer, Phase 9). Receipts are now two-sided: the party that executed an authorised action (the MCP gateway on its own, a first-party tool through the SDK, a relay-forwarded call) attests it with the hash of the result, and the layer signs a body that binds the decision, the warrant, the stamp and the declared commitment. The stamp resolver shows a receiver whether the stamped action was executed exactly as declared; xea1. tokens verify offline. Access Profiles can be derived from facts without a model: the tools an agent can reach (registered MCP servers and tool schemas) or an Authorisation Check export, classified into allowed, held and refused with guardrails from the schemas and the findings. Python SDK 2.12.0 (attest_execution, derive_profile_from_tools, derive_profile_from_scan; AgentSide.guarded attests automatically). See Execution attestation.
  • Information-flow authorisation (Authorisation Layer, Phase 8). Labels on sources (tools, MCP servers, connectors, data classes) using the NDMO classes with RESTRICTED and INTERNAL accepted as CONFIDENTIAL, plus PII and origin; propagation by union, declassification only by a mandate and sealed. Session taint tracking keyed by value hashes, never values: the SDK's xybern.flow.Taint hashes labelled tool outputs and declares what an action carries, the MCP gateway labels every result of a labelled server, and the control plane recognises tainted values in later actions. A flow rule refuses or holds by what the data is and where it goes (class, PII, origin, source; destination class, region, tool), compiled from outcomes such as "customer PII read from core banking may never reach an external model". Receipts show the labels and the provenance, stamps carry a data summary. The Saudi Enterprise pack gained residency-by-origin and personal-data flow mandates; XAAB gained an information_flow category. Python SDK 2.11.0. See Information-flow authorisation.
  • Dual control and obligations (Authorisation Layer, Phase 7). Rules can now say "allowed, provided that": obligations attached to an allowed action (approved recipient, inside a budgeted session, declared intent, a stamp, notification, redaction) with preconditions checked before authorisation and postconditions attested afterwards, all sealed. A dual_control rule holds the action for a second, independent person: never an agent, never the requester (nor the accountable Charter signer when configured), with an MFA step-up and an expiry, enforced when the escalation is resolved. The response, lineage and receipt list every obligation with who satisfied it and when; the Escalations view marks dual-control holds. Python SDK 2.10.0 (get_obligations, attest_obligation, consent). See Dual control and obligations.
  • Agent to agent, completed (Authorisation Layer, Phase 6). The root intent contract now travels with the warrant down the delegation chain: a delegate is conformance-checked against the root plan and its in-plan actions draw on the root contract's budgets, with via: warrant_chain on the receipt. Quantitative budgets on warrants and grants (actions, amount per currency, rows, distinct recipients) consumed atomically, split on sub-delegation and returned on revoke; exhausted budgets refuse and the receipt shows the state that decided. Communication policies say who may send which instruction to whom (agent, department or any; allow, block or escalate), checked before any rule and inside delegation. A new Authority graph view draws agents, grants, warrant chains, communication policies, principals and trusted issuers, with live revoke. Python SDK 2.9.0 (delegate with budgets and contract, create_comm_policy, check_communication, authority_graph). See Agent to agent.
  • Typed rules and collective limits (Authorisation Layer, Phase 5). A tool schema registry learns every tool's argument shape at the MCP gateway or from register_tool in the SDK, versioned per workspace. Mandates compile to typed argument rules validated against the schema before signing (unknown fields, wrong operators and values outside an enum are rejected); a missing or mistyped argument, or an amount in a currency the cap cannot compare, counts as a violation. The Charter wizard shows an editable constraint form per typed rule and a Typed rule on a tool card in the builder. The backtest reports impact across agents: how many recorded decisions per agent would have changed. Velocity rules gain a scope (agent, department, workspace) so a department or a whole swarm shares one counter, mirrored in Redis when present with the decision log as the source of truth; the counter state is recorded on the decision and shown on the receipt, and pre-flight quotes the remaining shared budget. Python SDK 2.8.0 (register_tool, list_tools, get_tool), JavaScript SDK 1.21.0. See Typed rules and collective limits.

Added

  • Charter as code, every mandate now carries generated must-refuse and must-allow tests (threshold, boundary, family, content pattern; semantic, verdict and sequence primitives honestly reported as skipped), run on every recompile and before signing, editable in the Charter view; a mandate with failing tests cannot be activated without a sealed override reason. Probe runs deterministic adversarial variants (past and at the threshold, string forms, missing and decoy fields, negative amounts, case and whitespace variants, spaced identifiers) and model-generated evasions when a provider is configured, reporting leaks and hazards, with one-click save of leaks as tests. Charter lint finds contradictions, unreachable rules, duplicates, untested mandates, semantic load and level widening. Levels: mandates are organisation-wide, department-scoped or agent-scoped; all levels evaluate together and a lower level may only add restrictions (checked at compile). Ask the Charter lives inside Ask Xybern: a permission question asked from any view is answered by a dry run through the real rules with the mandates cited, no model call, nothing recorded. Every Charter version now carries a signed semantic diff of what authority changed. See Charter as code.
  • The agent's side, the Authorisation Layer now serves the agent as a client that wants to be safe, not only as the party to be contained. Pre-flight (POST /v1/enforce/preflight, SDK preflight): hand over a plan and get, per step, allowed, needs approval or refused, with the reason, the mandates and what it would take (the bound that would make it allowed, the approver and the typical wait, or a ready authority request), signed and sealed, nothing executed. Declared intent (POST /v1/enforce/declare, AgentSide.guarded): the exact parameters are hashed at authorisation and the execution must match them, so a recipient or amount changed after authorisation is refused and an incident is opened. Trusted instruction channel: an instruction between agents is a stamped action, the receiver classifies what it reads as instruction or data (AgentSide.receive), and a receiver that requires signed instructions is refused unsigned ones at the control plane. Authority Requests: a refused agent files a structured request automatically, a human grants a scoped, time-boxed exception that lifts exactly the rules that refused (backed by a temporal window and a child warrant), high blast-radius grants need MFA, agents never grant, and a Charter mandate can pre-authorise small requests. New Requests view with pre-flight records. Framework integrations for the Claude Agent SDK, MCP servers, the OpenAI Agents SDK, LangChain and CrewAI. SDK 2.7.0 (xybern.agentside, xybern.integrations). See The agent's side.
  • Authorisation Stamps, proof of authorisation that travels with the action itself. Every authorised outbound action can carry a compact signed stamp (an HTTP or MCP header, an email header, document metadata, or a 140-character payment reference) bound to the decision and to the artefact's hash. Anyone who receives it checks it with no account: in the browser at /check, with one call to the public resolver /proof/stamp/<id>, or fully offline against the issuer's published keys from /.well-known/xybern-issuer/<id>, and sees the outcome, the Charter version, a pseudonymous accountable human (resolvable by the issuer on lawful request, never a name), the agent, the bounds it was under, and whether the artefact was substituted. Receivers on Xybern can require stamps on what they receive with the new inbound_stamp rule (trusted issuers, * for any), and when both sides are on the same install the receiver's decision is sealed in the sender's vault too. Stamps view with issuer settings and a public issuer mirror; Revoke everywhere revokes outstanding stamps. SDK 2.6.0 intercept(stamp=True, artefact_sha256=), stamp_decision, xybern.stamps (offline checker, email, HTTP, ISO 20022 and document adapters, python -m xybern.stamps); JavaScript 1.20.0; verify.py --stamp. See Authorisation Stamps and Stamp v1.
  • Authorisation Warrants, authority becomes a short-lived signed capability the agent carries: what it may do, within which argument bounds and budgets, on which Charter version, bound to which session and credential, until when, and through which delegation chain. Issued from the objects in force (POST /v1/enforce/warrants, SDK issue_warrant, dashboard Warrants view), checked at every choke point (intercept, MCP gateway, self-hosted relay) before any rule runs, recorded on the decision, in the lineage and receipt, and sealed in the Vault. A presented warrant that does not hold refuses the action; an agent that requires warrants (per agent, or by workspace default) is refused without one; an MCP server can require one for every tool call. Delegation now mints the delegate an attenuated child warrant (a child can never widen its parent; the issuer refuses to sign one that would). Revoking a grant, session, credential or agent revokes the warrants it covers, and a signed incremental revocation list feeds relays. Anyone can check a warrant offline with the published keys: xybern.warrants.verify_offline, tools/xybern-verify/verify.py --warrant, and the relay's warrant_check. Format published as a draft spec. See Authorisation Warrants and Warrant v1.
  • Charter version pinning, every enforcement decision now records the Charter version it was taken under: a public sha256 over the canonical mandate list, who signed that version, when, and the mandate snapshot. Receipts carry it under authorisation.charter, the Vault entry seals it, and anyone can recompute the hash from the version record without a secret. A later Charter change creates a new version and never rewrites what earlier decisions were taken under. Endpoints GET /v1/enforce/charter/versions and GET /v1/enforce/charter/versions/<hash>; SDK 2.4.0 list_charter_versions, get_charter_version. See Mandates & Charter.
  • Authority lineage, every decision and receipt now answers "on whose authority did this action rest": the accountable human who signed the Charter version, the mandates that spoke, the agent's access profile, intent contract, temporal window or break-glass event, the full delegation chain from root grant to leaf with the principal acted for, the agent's credential, the session, and the action. Computed at decision time from the objects in force, never reconstructed later, sealed in the Vault entry, rendered as one plain sentence (lineage_text) and shown in the decision dialog under On whose authority. See Proof of Authorisation.
  • Strict confused-deputy protection, a delegate acting under a grant can never do what its principal could not. Every delegated action is also evaluated against the principal's own access profile and principal-scoped rules, a deactivated or revoked principal lends no authority, and the stricter outcome stands. Recorded on the decision, in the lineage and in the explanation. See A2A Delegation.
  • One revoke, everywhere, POST /v1/enforce/agents/<id>/revoke (SDK revoke_agent, dashboard Revoke everywhere) deactivates an agent and revokes every authority it holds or lends in one operation: sessions killed, credentials revoked, delegation grants given and received revoked with cascade, temporal windows, intent contracts and federation tokens revoked, MCP tool policies disabled. Returns a signed Revocation Certificate (ECDSA P-256, offline-verifiable) listing every object revoked, sealed to the Vault, with an incident and an agent.revoked webhook. A deactivated or revoked agent is now refused at the choke point before any policy work (decision_path: "revoked"). See Agent Registry.

2026-07

Added

  • Proof of Authorisation, the Authorisation Layer can now prove, to anyone, that every agent action was authorised before it executed. Every decision can be exported as an Authorisation Receipt (the action, the agent, the rules and Risk Verdict that decided it, the human resolution if it was escalated, and the Vault certificate that lets a third party verify it offline with the published public keys), and a period can be exported as a signed Proof of Authorisation pack: summary of every outcome, per-agent breakdown, the receipts, the covered Vault entries with their signatures, and an ECDSA signature over the whole pack. Packs get a revocable, read-only public share link that re-verifies the signature on every view and offers the signed JSON and a PDF whose appendix details every action chronologically: outcome, timestamp, agent, tool and connector parameters, the agent's own stated reason, the authorisation reasoning, verdict scores, and the Vault reference. Receipts distinguish the agent's stated reason (pass reasoning= at intercept, or a reasoning argument on an MCP tool call, captured automatically) from the authorisation reasoning, and decisions now seal the action's content hash, metadata, and reasoning into the Vault entry at decision time. A new Proof of Authorisation dashboard tab shows Authorisation Coverage (which agents operate under a declared authority, Agent Boundary, Intent Contract, or agent-scoped Mandate, and which still hold standing authority), generates packs, and manages share links; every decision panel has a receipt download. SDK 1.21.0: get_receipt, create_proof_pack, list_proof_packs, get_proof_pack(verify=True), get_authorisation_coverage, intercept(reasoning=...). See the Proof of Authorisation documentation.
  • MCP Quick Connect and rule templates, the MCP Gateway tab's new Quick Connect goes from nothing to an authorised MCP server in about five minutes: register the upstream, mint a scoped API key on the spot, enable ready-made rules, and copy a finished client config for Claude Code, Claude Desktop, Cursor, or Windsurf. Ships with one-click rule templates for GitHub (read but never push, merge, or delete), Postgres (query but never DROP, TRUNCATE, ALTER, or DELETE FROM), filesystem (read freely, write with review), Slack (read freely, post with review), and Stripe (money movement reviewed, deletions refused), each applied as a real mandate in your Charter, in enforce or shadow mode. The gateway now also enforces per-key rate limits, and a key-authentication defect that broke gateway requests was found and fixed in the process. Every proxied tool call produces a signed Authorisation Receipt. See the MCP Gateway documentation.
  • Relay MCP mode, the self-hosted relay can now front your on-prem MCP servers directly at http://<relay>:8787/mcp/<server>. Every tools/call is authorised against the locally cached rules on your own infrastructure, so tool arguments never leave your network; semantic rules forward just that intercept, refusals and escalations are registered with the control plane when reachable (so they appear in the dashboard and carry signed receipts), tools/list is filtered per server, and every decision is audited to the Provenance Vault. Configure upstreams with XYBERN_MCP_SERVERS and optionally require a shared client token. See the Self-Hosted Relay documentation.
  • OAuth-fronted MCP servers, the cloud gateway can now sit in front of remote MCP servers that require OAuth: set auth_type: "oauth" with the identity provider's token URL and client credentials, and the gateway obtains, caches, and refreshes the access token per server. Available in the Add Server modal and Quick Connect. See the MCP Gateway documentation.
  • Redesigned enforcement authoring, creating enforcement no longer means picking a cryptic policy type and hand-writing regex. Everything you create is now a Mandate, with two entry styles in the Charter: Describe an outcome (plain English, Xybern compiles it) and Build it yourself (a guided picker with five plain-language choices, no regex: block or hold specific actions, catch it by meaning, react to the risk level, catch patterns across actions, restrict by time). Ask Xybern now creates Mandates too, compiling the outcome and previewing the primitives before you save. The raw enforcement layer is renamed Rules (advanced), a read-mostly audit view that shows which mandate each rule was compiled from, and hand-authored regex is retired (the compiler writes it). Nothing about the enforcement path changed; mandates still compile to ordinary rules underneath. See the Mandates & Charter documentation.
  • Mandates & Charter, outcome-based authorisation that replaces writing rules with declaring outcomes. You state a Mandate in plain English ("no personal data may ever leave the organisation", "no payment above 10,000 without a named human approver") and Xybern compiles it into the smallest mix of enforcement that upholds it: deterministic action and content matchers for the enumerable cases (the compiler writes the patterns, you never do), one semantic guard for the paraphrase and euphemism the deterministic layer cannot enumerate, verdict conditions for the risk shaped cases, and sequence detectors for multi step patterns. You see exactly what your outcome compiled into, backtest it against your real decision history before it goes live (trigger rate, what it would have caught that was previously allowed, and the coverage split), and save it as shadow or enforce. The compiled primitives are ordinary enforcement rules underneath, so nothing about the enforcement path changes and the advanced Policies view still lets power users author raw primitives directly. The signed, versioned collection of a workspace's mandates is its Charter, HMAC signed over the collection with the policy set hash proving the rules in force, re-signed and sealed to the Provenance Vault on every change. Mandates are the top layer of the four layer stack: Charter (standing law), Agent Boundaries (per agent job), Intent Contracts (per mission plan), Risk Verdict (per action record). See the Mandates & Charter documentation.
  • Intent Contracts, plan level authorisation for AI agents. An agent submits its mission plan in natural language, Xybern compiles it into a bounded permission set (the specific actions the plan requires with per action caps on amount and uses, actions held for human approval, whole mission budgets, an expiry, and plain English guardrails), a human approves it once in the new Intent Contracts dashboard tab, and the contract is HMAC signed and sealed to the Provenance Vault. From then on every action carrying the contract is checked against the approved plan deterministically: in plan actions take a fast path (no LLM verification, policies still run and always win), out of plan actions block or escalate per the contract, and every violation is sealed and notified by webhook. One approval per mission instead of one escalation per action, and stricter at the same time. The Risk Verdict's intent alignment dimension is now judged against the approved plan when a contract is present. Ships with SDK support (submit_contract, wait_until_approved, intercept(contract_id=...), complete_contract) and contract.* webhook events. See the Intent Contracts documentation.
  • Risk Verdict, every enforcement decision now carries a signed, multi dimensional decision record in place of a single blended trust score: intent alignment (does this action serve the agent's declared job, judged against its Agent Boundary with no extra LLM call), behavioral conformance (a conformal p value against the agent's own rolling action history, for example "anomalous at 97% confidence given a 240 action history", a statistical guarantee that tightens as history accumulates), blast radius (deterministic damage potential: reversibility, external boundary, monetary value, bulk counts, data sensitivity), and provenance confidence (identity proof, credential freshness, delegation depth, session containment, federation caps). Each dimension carries its own evidence trail, the verdict is HMAC signed over canonical JSON, and it is additionally sealed inside the hash chained Provenance Vault entry. A new verdict policy type conditions directly on dimensions (blast_radius < 40, AND combinations, aggregate), and an unavailable dimension never triggers. The dashboard shows a verdict card in the escalation review modal and Vault detail, dimension chips in history rows, and a builder form for verdict policies. The legacy trust_score remains in every API response and is now derived from the verdict, so existing integrations and threshold policies work unchanged. See the Risk Verdict documentation.
  • Enforcement decision webhooks fixed, decision.allow, decision.block and decision.escalate webhook events were silently failing to dispatch due to an internal error, they now fire. If you have webhook subscriptions for decision events, expect to start receiving them.
  • Runtime Containment (Agent EDR), continuous control over an agent that is already running, not just a verdict on each action. Open a session for a run and set live budgets (maximum actions, time-to-live) that are enforced at the choke-point; kill a running agent from the new Live Sessions dashboard tab or the API, and its next action returns a terminate verdict; the Python SDK runs a background heartbeat that raises SessionTerminated, so an integrated agent aborts within seconds rather than only on its next action; and revoking a credential now cascade-kills every active session using it, so a compromised key halts in-flight runs immediately. Containment events (budget breaches, revocations) are opened automatically as incidents with the remediation taken, surfaced in a new Incidents dashboard tab and notified by webhook, and you can request compensating actions (rollback) that your own handler executes. Every session and incident event is sealed to the signed Provenance Vault. See the Runtime Containment documentation.
  • Efficacy Benchmark (XAAB), an open, reproducible benchmark that measures how well an AI-agent authorisation layer stops unsafe actions while allowing legitimate ones, across 137 scenarios drawn from OWASP LLM Top 10, MITRE ATLAS and CWE. The Xybern Authorisation Layer caught 100% of unsafe actions with 0% false positives, held at 100% under paraphrase where a strong keyword guardrail collapsed from 84% to 44%, and stayed stable across repeated runs. Every benchmark decision is sealed to the signed Provenance Vault, and the whole suite (dataset, harness, reference policy pack, and an open-source offline verifier) is public under Apache-2.0. See the Efficacy Benchmark documentation.
  • Self-Hosted Relay, run the enforcement plane inside your own network. The relay evaluates deterministic and stateful policies locally, so action content never leaves your infrastructure, forwards only intent-based (semantic) checks to the cloud, caches your policies for low latency and availability, and forwards a metadata-only audit record of every decision to the tamper-evident Provenance Vault. Point the SDK at it and everything else is transparently proxied. Ships as a Docker image. See the Self-Hosted Relay documentation.

2026-06

Added

  • Stateful / sequence policies, a new policy type that judges a pattern across an agent's recent actions rather than a single action, catching what one-shot rules can't: velocity ("more than N wire transfers in 5 minutes") and ordered sequences ("read many records → then send externally", a classic exfiltration pattern). Evaluated over the agent's recent decision history within a configurable time window. Create them from the policy form, via Ask Xybern, or the API. See the Policies documentation.
  • pip install xybern, auto-discovery SDK, a one-line way to bring an existing agent stack under governance. from xybern import auto; auto.connect() discovers the AI agents, tools, and MCP servers running in your process (LangChain, CrewAI, OpenAI Agents SDK, MCP, LangGraph, AutoGen, Semantic Kernel, LlamaIndex), registers each to your workspace with a cryptographic identity, and instruments them, in observe mode by default, so nothing is ever blocked until you turn enforcement on. Sign in with a browser device-code flow (xybern login) or an API key; content is sent as a hash by default and the SDK fails open if Xybern is unreachable. See the Python SDK documentation.
  • External anchoring & per-decision certificates, the Provenance Vault now periodically emits a checkpoint: a single Merkle root ("tree head") committing every entry, signed with the KMS key and timestamped by an independent RFC-3161 Time-Stamp Authority, proving the log's contents and order existed before a point in time, which not even Xybern can backdate. Any single record can prove membership in that signed, timestamped root via a Merkle inclusion proof, and you can export a per-decision certificate, a self-contained, shareable proof for one action that a third party can verify offline (inclusion proof + checkpoint signature checked automatically by the open-source verifier; the RFC-3161 token verifiable with openssl ts). See Verifiable Provenance.
  • Policy-version binding, every enforcement decision is now bound to the exact ruleset that produced it. The signed Vault entry records a policy_set_hash (identifying the precise set of active policies in force at decision time) plus a self-contained snapshot of the rules that actually fired, and the full ruleset is snapshotted the first time each hash is seen, so a decision's proof reads as "at time T, policy-set H (these exact rules) produced this verdict", and resolves to the precise rules even after they're later edited or deleted. Surfaced in the Vault entry view and resolvable via API. Builds on Verifiable Provenance.
  • Verifiable Provenance, every decision and audit event in the Provenance Vault is now hash-chained and asymmetrically signed (ECDSA P-256), with the signing private key held only in AWS KMS. Anyone, an auditor, regulator, insurer, or your own customer, can independently verify that a record is authentic, untampered, and correctly ordered using only Xybern's published public key, while nobody (not even Xybern) can forge or backdate one. Public keys are published at a no-auth endpoint, a self-contained proof bundle can be exported per workspace, and an open-source verifier checks everything offline with zero dependency on Xybern. Foundation for EU AI Act Article 12, ISO 42001, and SOC 2 record-keeping. See the Verifiable Provenance documentation.
  • Authorisation Layer Semantic Policies, a new policy type that judges an AI action's intent against a rule written in plain English, catching paraphrase, euphemism, and obfuscation that regex-based rules can't (e.g. a "never promise a refund" rule that also stops "expect the funds back in your account"). The judge runs on the enforcement path with a fast model, caching, and a short timeout, and is fail-open by default so an LLM outage never wrongly blocks legitimate traffic (set on_unavailable: "escalate" to fail closed instead); a per-policy confidence floor controls how certain a match must be, and semantic conditions compose inside AND/OR policies and run in shadow mode like any other type. See the Semantic Policies documentation.
  • Ask Xybern now creates semantic policies, the in-dashboard assistant that already turns a plain-English description into a one-click policy now understands the semantic type, so describing a rule whose wording could vary (e.g. "never promise a refund") produces a ready-to-create semantic policy automatically. A live test box on the policy form lets you check a single action against the rule and see the verdict and confidence while you tune it.
  • Policy Backtesting, replay any draft policy against your workspace's real decision history before you deploy it, and see exactly what it would have done: the trigger rate, how many previously-allowed actions would now be blocked or escalated, the new-decision breakdown, and sample hits with the judge's reasoning. Deterministic policies sweep a wide window instantly; semantic policies sample recent actions and judge them in parallel.
  • Model resilience for the Authorisation Layer, wherever the layer uses an LLM, the semantic policy judge and the Ask Xybern assistant, it now falls back automatically to a secondary provider if the primary is unreachable or out of credits, so intent enforcement and the assistant keep working through an upstream billing or rate-limit event.
  • Scroll AML, Sanctions & PEP Screening, screen every client and their named owners against global sanctions and PEP lists (via OpenSanctions), with scored matches showing the list and reason, a clear / needs-review / flagged status and a low / medium / high risk rating. Review matches and record a determination (cleared, true match, false positive); every screening is kept as a dated, hashed audit record. New clients are screened automatically, a daily job re-screens stale records, and a jurisdiction-scoped Compliance inbox lists clients by status with flagged and overdue first. Data residency is supported by self-hosting the matching engine. See the AML Screening documentation.
  • Scroll Document Intelligence, upload a client document (or have the client send it through the portal or a message) and Scroll reads it, classifies the type (passport, trade licence, Ejari, CR, GOSI, visa, and more), extracts the holder, number, issue and expiry dates, and authority, matches it to a client, and offers to create the deadline and the renewal in one click. Text documents are read directly; photos and scans are read with AI vision. Client-submitted documents are ingested and analyzed automatically into a jurisdiction-scoped Documents inbox; extracted detail is stored encrypted and nothing is created without your confirmation. See the Document Intelligence documentation.
  • Scroll Public Verification & QR, every sealed matter now gets a permanent, scannable verification link and QR code. Anyone, a client, an auditor, or a government officer, can scan it or open the link to confirm the document is held in your Provenance Vault, with its hash and (if signed) its signature, on a firm-branded page that shows no document content or PII. The QR is embedded on the signed PDF certificate page and available from each matter via a Verification QR action. Pure hash and signature verification, so it works independently of any AI service. See the Public Verification documentation.
  • Ask Scroll, the ask bar on the Workflows screen now answers questions about your own firm, not just regulations. Alongside its regulatory expertise (with live web search), it is given a jurisdiction-scoped snapshot of your clients, renewals, deadlines, matters, signatures, and open requests, so you can ask "which clients have renewals due next month?", "what's the status of this client?", or "who still has a signature pending?". It uses non-sensitive fields only (names, references, dates, statuses), never the encrypted PII profile fields, and answers stream back formatted. See the Ask Scroll documentation.
  • Scroll Client E-Signature, clients can electronically sign completed, sealed matters from the portal by typing or drawing their signature and confirming consent. Each signature is stamped with the time and IP, bound to the matter's Provenance Vault hash (so any later change breaks verification), and a signature certificate page is appended to the PDF. The firm requests a signature with one click, both sides are notified, and signed matters carry a Signed badge in the Vault.
  • Scroll Client Portal Messaging, a two-way conversation per client. The firm posts notes asking for documents or details, with a per-message Request a document toggle, and the client replies in plain text or attaches multiple documents (which land in Client documents, ready to download or run a workflow on). Both sides are notified by email and Telegram. A Client activity feed shows signatures, uploads, requests, and sign-ins at a glance.
  • Scroll Client Portal, a white-label, passwordless portal where your clients track their matters, see upcoming renewals and deadlines, message you, upload documents, download completed packages, and request new services. Each client signs in with a one-time code or magic link (no passwords); every session is scoped to one client, and documents are only downloadable once a matter is completed and approved. Firms control it end to end: enable or revoke access per client, brand the portal (firm name, colour, logo), and work from a Client documents inbox where every client upload can be downloaded, fed straight into a workflow with one click (the run is created for that client with the document attached, then flows through the normal approval gate), or deleted. Service requests land in a Client requests inbox where you can mark them done or dismiss them, with an unseen-count badge. Fully Arabic and right-to-left, with a per-client language switch. See the Client Portal documentation.
  • Scroll Regulatory Change Radar, a daily monitor that checks official UAE and Saudi sources for changes to the fees, rates, thresholds, and rules behind your workflows. It keeps a Current Rates & Rules reference of the latest figure on record for every topic (with official sources and a last-verified date, available from day one), and a Recent changes feed showing what moved, with summaries, effective dates, and source links. Changes relevant to the workflows your firm uses are highlighted and surfaced first. When something changes, Scroll feeds the new figure into future workflow runs automatically, flags any already-prepared renewal in Renewal Autopilot with a one-click Re-prepare action (still gated for approval), and alerts you by email and Telegram. Monitoring runs globally on behalf of all firms, and the first check of each topic records a silent baseline so there are no false alerts. Source-cited and alert-and-surface only, nothing is auto-submitted. See the Regulatory Change Radar documentation.
  • Scroll Insights & ROI dashboard, a single screen showing the value Scroll delivers: renewals prepared automatically, documents read, documents anonymised before any AI saw them, and audit-ready records, plus staff time and money saved based on the firm's own per-workflow time/cost figures (entered once, never a hardcoded guess). Adds forward-looking upcoming renewal workload (30/60/90 days), deadlines at risk, period-over-period change on every metric, and a turnaround trend. Fully measured from real activity, jurisdiction-filterable, and Arabic-localised. See the Insights & ROI documentation.
  • Authorised Agents, domain-specialised AI agents that plan, get your approval, then execute, with every action governed by the Authorisation Layer. Four presets: Banking, Legal, Project Management, and Fraud, each with tuned skills and example prompts. See the Authorised Agents documentation.
  • Agent Skills, toggleable domain skill packs per agent, auto-suggested per request, plus custom skills you define in plain language.
  • Agent Automations, schedule an agent to run a recurring task (e.g. a weekly status report or daily fraud monitoring); each run is logged.
  • Agent Connectors & Documents, a shared document library plus Gmail, Google Drive, Dropbox, OneDrive, Slack, Notion, Trello, and HTTP/webhook connectors, with Telegram access to talk to your agent on the go.
  • Xybern Scroll, an Arabic-native regulatory workflow platform for UAE and Saudi firms. Reads Arabic government documents, prepares submissions, gates them for human approval, and seals them in a tamper-proof Provenance Vault. See the Scroll documentation.
  • Scroll Workflow Library, 31 built-in workflows across real estate, banking, legal, government, energy, and tourism - DLD, DED, MOHRE, GDRFA, DIFC/ADGM, SAMA, CMA, ZATCA, GOSI, MOJ, DEWA, ADNOC, Aramco, DTCM, STA, and more.
  • Scroll Renewal Autopilot, watches every client's deadlines and auto-prepares renewals before they're due, requests missing details from the client via a targeted link, holds for human approval, and rolls the deadline forward perpetually.
  • Scroll AI Workflow Builder, describe a regulatory process in plain language and Scroll generates a custom, editable workflow.
  • Scroll Clients & CSV Import, encrypted client profiles that pre-fill workflows, with bulk import from any CRM/Salesforce CSV export via automatic header mapping.
  • Scroll CRM Connections, live contact search from Zoho CRM (multi-data-centre aware) and CSV import for Salesforce.
  • Scroll Client Intake Links, shareable links that collect client details - including targeted links that ask only for the fields you're missing.
  • Scroll Webhooks, let external systems trigger workflow runs by POSTing to a unique URL.
  • Scroll PII Redaction, client PII is tokenised before any LLM sees it and restored afterward, built on Xybern Redact.
  • Scroll Live Web Search, analysis steps check official UAE/Saudi sources for current fees, rates, and rule changes.
  • Scroll Approvals & Provenance Vault, every submission pauses for human approval at an Authorisation Layer gate; every completed workflow is sealed as a tamper-proof record.
  • Scroll Arabic & RTL, full Arabic (MSA) interface, workflow content, and AI output with a right-to-left layout, chosen per workspace.

Improved

  • Scroll jurisdiction scoping, each client now has a jurisdiction (UAE, Saudi, or Both), and the topbar UAE / KSA / Both selector now scopes the entire workspace consistently: the workflow library, Clients, Runs, the Vault, the Compliance Tracker, Renewal Autopilot, Insights, the Regulatory Radar, the Documents inbox, and the Client Portal documents, requests, and activity, plus the workflows a client can request in the portal. Every view follows the same rule, a specific jurisdiction shows its own plus cross-market items.
  • Ask Scroll answers stream in formatted, the Workflows ask bar now renders answers as Markdown with a live typing effect, matching the workflow step outputs.
  • Docs restructured under Products, the Authorisation Layer (now including MCP Server, LLM Gateway, and Framework Integrations), Redact, and Scroll are grouped under a single Products section.

2026-05

Added

  • Python SDK, pip install xybern-redact gives you a zero-configuration HTTP client for the Redact API. anonymize() strips PII and returns an entity map, deanonymize() restores real values client-side from that map, chat() handles the full proxy flow automatically, and anonymize_file() uploads documents for anonymization. Supports multi-turn conversations via thread_id, context manager usage, and typed exceptions for authentication and server errors.
  • Co-reference Resolution, Name variants within a document now resolve to the same pseudonym automatically. After detecting a full name, Xybern searches the remaining text for title and last name variants (Mr. Chen, Dr. Chen), initial and last name variants (M. Chen), and bare last name references (Chen, when unambiguous). Pseudonyms placed during the primary pass are protected before the variant pass runs to prevent accidental overwriting.
  • Data Erasure, Permanently delete an individual's real values from the entity map to fulfil GDPR Article 17 right-to-erasure requests (and equivalent rights under CCPA and other privacy regulations). Submit up to 500 values per request via the Erasure tab in the Redact dashboard or POST /api/redact/{workspace_id}/erasure. Every erasure operation creates an immutable audit record in the Provenance Vault showing how many entries were deleted and the breakdown by entity type. Future requests containing the erased values receive fresh pseudonyms.
  • Structured Data API Access, The structured data detect and anonymize endpoints now accept API key authentication in addition to session auth. ETL pipelines and data engineering workflows can call POST /api/redact/{workspace_id}/structured/detect and POST /api/redact/{workspace_id}/structured/anonymize directly using a Bearer API key without a browser session. IBAN added as a supported column entity type with automatic suggestion for columns named iban or bank_account.
  • Format-Preserving Anonymization, SSNs, credit card numbers, IBANs, and phone numbers are now replaced with structurally valid fakes instead of redaction tokens. Fake SSNs pass SSA format rules, fake card numbers pass Luhn checksum validation, fake IBANs pass ISO 13616 mod-97 check digit validation with the country code preserved, and fake phone numbers preserve the original separator style and digit count. No configuration required. Applies to all policies automatically.
  • Structured Data Anonymization, Upload a CSV or JSON file to the Structured Data tab, configure each column individually (Person, Email, Phone, Organisation, SSN, Credit Card, or skip), and download the anonymized file in the same format. Column names are used to auto-suggest entity types. Pseudonym assignment is consistent with your workspace entity map. Available in the dashboard and via POST /api/redact/{workspace_id}/structured/anonymize.
  • Multi-Turn Conversation Support, Pass a thread_id on each proxy request to maintain consistent pseudonym mappings across a full conversation thread. The same real value always resolves to the same pseudonym within the thread. Clear a thread via DELETE /api/redact/{workspace_id}/threads/{thread_id} when the conversation ends.
  • Selective Disclosure, Generate a signed, time-limited proof link for any vault record. External auditors open the link to verify document hashes, HMAC signature, and Merkle inclusion proof without accessing your workspace. Links expire after 30 days. Available via the Disclose button in the Vault tab or the API.
  • Vault Search by Entity Type, Filter the Provenance Vault by detected entity type - Person, Email, Phone, Organisation, SSN, Credit Card, or Signature. Returns only records where that entity type was stripped. Available in the dashboard filter bar and via the entity_type query parameter on the vault API.
  • Anonymization Preview, Paste any sample text into the Preview tab, select a policy, and see exactly what gets redacted before sending a real request. Detected PII is highlighted in the original, pseudonyms are highlighted in the anonymized output, and a full entity map is shown. No vault record is created.
  • Workspace Domain Scoping, Each Redact workspace is configured for a single domain (Legal, Healthcare, Finance, General) at creation time. API keys and policies are scoped to that domain automatically, enforcing least-privilege access at the infrastructure level.
  • Admin-Provisioned API Keys, Redact workspace API keys are now provisioned by the Xybern administrator and scoped automatically to the workspace domain. Customers copy their key from the API Keys tab without needing to generate one.
  • Ask Xybern, Natural language policy generation. Describe your data processing needs in plain English and Xybern configures the entity types, custom patterns, and redaction settings automatically. Uses Anthropic with DeepSeek as automatic fallback.
  • Redact Policy Templates, One-click compliance policies for HIPAA, GDPR, PCI-DSS, and SOC 2. Each template creates a fully configured policy with the correct entity types, date offset, and permanent redaction setting for the compliance framework.
  • Redact Vault Search and Filtering, Filter the provenance vault by status, model, and date range directly from the dashboard or via API query parameters. Designed for compliance audits, incident investigation, and data governance reviews.
  • Redact Batch API, POST /redact/v1/batch accepts up to 500 messages and returns a job ID immediately. Processing runs asynchronously. Poll GET /redact/v1/batch/{job_id} for progress or receive a batch.completed webhook on completion.
  • Redact Entity Map TTL, Set a workspace-level TTL so pseudonym mappings expire after N days. Expired entries are pruned automatically, supporting GDPR right-to-erasure and data minimisation requirements.
  • Redact Multilingual PII Detection, Person name detection now covers French, Spanish, German, Chinese (including surname-first patterns via _CHINESE_SURNAMES), and Arabic script names (including Saudi Gulf names) using Unicode-range regex.
  • Redact Auto Document Class Detection, Pass "doc_class": "auto" on any request and Redact infers the document type from content keywords. The correct policy is applied automatically.
  • Redact Webhooks, Subscribe to leakage.detected events. Receive an HMAC-signed HTTP callback the moment PII leakage is found in an LLM response.
  • Redact Permanent Redaction Mode, Policy toggle that skips de-anonymization entirely. Pseudonyms remain in the LLM response, suitable for training data generation and third-party review workflows.
  • Redact Custom Entity Types, Define regex-based patterns per policy for domain-specific identifiers (employee IDs, project codes, custom account numbers). Applied after built-in entity detection.
  • Redact Streaming, Pass "stream": true to receive proxy responses as Server-Sent Events, compatible with the OpenAI streaming format. Anonymization and leakage scanning complete before the stream begins.
  • MCP Proxy Gateway Mode, Run Xybern's MCP server as a transparent proxy in front of any existing MCP server. All tool calls are intercepted and enforced without changes to the downstream server.
  • Active Connections, Real-time view of all LLM provider connections in the Authorisation Layer dashboard, with per-connection enforcement statistics.
  • LLM Gateway, Proxy layer between your application and LLM providers (OpenAI, Anthropic, Google, Azure). Every prompt and completion is evaluated against active policies before reaching the model or your system. Supports dry-run mode for safe policy testing.
  • Vault Retention Policy, Per-workspace automatic deletion of vault records older than a configured window (30, 60, 90, 180 days, or 1 year). A background job runs every 24 hours. Manual immediate purge also available. Satisfies GDPR Article 5(1)(e) storage limitation requirements.
  • Redact Extension Document Upload, Drag and drop a PDF, DOCX, TXT, CSV, or MD file directly in the extension popup to anonymize it. The anonymized file is returned as a download. Supports files up to 10 MB.
  • Redact Extension Clipboard Scanner, Automatic PII detection on paste. When you paste text into any input field, the extension scans locally for emails, phone numbers, SSNs, credit card numbers, and API keys. A warning banner lets you anonymize before the text reaches the page, with no network request for detection alone.
  • Redact Chrome Extension, Browser extension for PII anonymization without leaving your workflow. Right-click any selected text on any webpage and receive the anonymized version in an overlay card. Available on the Chrome Web Store.

Improved

  • Provenance Vault summary strip, Four stat cards at the top of the Vault tab show total entities stripped, leakage events, erasure operations, and clean rate at a glance.
  • Temporal Permission Windows now support action-level constraints within a scope, not just scope-level grants.
  • Enforcement response now includes decision_path (fast or full) so you can distinguish cached from fully evaluated decisions.

2026-04

Added

  • Federation, Connect multiple Xybern workspaces or external identity providers for cross-organisation enforcement.
  • Agent RBAC, Assign roles to agents and attach policies to roles. Simplifies governance at scale without per-agent policy management.
  • Policy Shadow Mode, Evaluate new policies against live traffic without enforcing them. Identify false positives before activating a policy in production.
  • A2A Delegation, Agent-to-Agent delegation. An agent can grant a subset of its own permissions to another agent for a specific task, with full audit trail.
  • Policy-as-Code SDK, Define, version, and deploy policies as Python code. Xybern diffs your policy definitions against current state and applies changes atomically with full Provenance Vault tracking.

Improved

  • Breakglass events now trigger an automatic Slack or webhook notification if a webhook is configured for the breakglass event type.
  • POST /v1/enforce/intercept latency reduced on the fast path, average under 5 ms.

Fixed

  • Escalation status polling no longer returns stale state after a resolution is submitted in under 500 ms.

2026-03

Added

  • Webhooks, Subscribe to enforcement events and receive them at any HTTP endpoint. Supports decision.allow, decision.block, decision.escalate, escalation.resolved, breakglass.triggered, and policy.changed.
  • Metadata Field Policy, Evaluate arbitrary action metadata fields (amount, recipient, region) against policy rules without SDK changes.
  • Custom Policy Builder, UI-based policy authoring for non-engineering teams. Build metadata-driven rules without writing code.
  • Breakglass Protocol, Emergency override mechanism with mandatory justification, audit logging, and per-agent cooldown (max 3 per 30 minutes).
  • Temporal Permission Windows, Time-bounded permissions that auto-expire. Modelled after JIT access patterns in human IAM, purpose-built for AI agents.

Improved

  • Decision log pagination now supports cursor-based pagination in addition to offset-based.
  • Agent registry now supports tags and description fields for easier management at scale.

2026-02

Added

  • Provenance Vault, Immutable audit log for every enforcement decision, escalation, policy change, and credential event.
  • Human-in-the-Loop, Full escalation flow with Authorisation Layer dashboard review queue, resolution API, and SDK-level wait_for_escalation() polling.
  • Credential Lifecycle Management, Automatic issuance, rotation, and revocation of agent credentials. Agents never hold long-lived secrets.
  • SDK Auto-Capture, Automatically intercept agent tool calls without adding manual intercept calls at each action site. Zero code changes for CrewAI, LangGraph, AutoGen, and LlamaIndex integrations.

Improved

  • Framework integrations now include full examples for CrewAI, AutoGen, LangGraph, LlamaIndex, and custom pipelines.

2026-01

Added

  • Python SDK, Official SDK with enforcement client, policy management, escalation polling, and auto-capture layer.
  • Authorisation Layer Dashboard, Web interface for security teams to monitor decisions, review escalations, and manage agents and policies.
  • Decisions & Escalations API, Query the immutable decision log, list pending escalations, and resolve them programmatically.
  • Policies CRUD, Create, read, update, and delete policies via API. Policies are evaluated against every intercepted action.
  • Agent Registry, Register, update, suspend, and deregister agents. All enforcement decisions are tied to a registered agent_id.
  • Agent-to-Agent communication enforcement, POST /v1/enforce/agent-comm for governing messages between agents in multi-agent pipelines.
  • Core enforcement API, POST /v1/enforce/intercept for pre-execution action interception. Returns allow, block, or escalate with trust score, reasoning, and vault entry ID.