Xentra · Agentic Execution Assurance
Agents can decide to act. Xentra decides whether they should.
AI agents are starting to do real things — write files, change infrastructure, move money, run experiments. Xentra is the checkpoint that sits in front of those actions and decides whether each one is allowed to happen.
It checks every action against independent safety, correctness and system-health signals, then makes one yes-or-no decision. If anything is wrong, uncertain, or unavailable, the action is blocked and the tool is never called. Every decision is recorded so you can prove, later, exactly what was allowed and why.
Technically: Xentra is a vendor-neutral execution-assurance plane for consequential AI-agent actions. It sits between agent intent and external tools, combining independent governance, formal assurance, and live-state admission signals into one deterministic execution decision. Authorized actions can proceed through a cryptographically bound authorization boundary; blocked actions never reach the downstream tool.
Why Xentra
Identity, tools and guardrails still leave one question unanswered.
Agent frameworks can decide what they want to do. IAM can establish who they are. Sandboxes can restrict where code runs. Gateways can move requests. Observability systems can tell you what happened. Xentra focuses on the execution boundary itself.
The Xentra question
May this exact action, from this authenticated caller, execute now under the current policy and system state?
Xentra turns that question into a deterministic control decision backed by independent assurance providers and preserved execution evidence.
Where it fits
Execution path
Assurance before consequence.
Xentra keeps authentication, assurance, adjudication and execution as distinct boundaries. The final authorization decision is deterministic: every required provider must independently return an allowed outcome.
Authorized
Execution becomes eligible.The exact action and decision can be cryptographically bound to an Ed25519 execution permit before the downstream tool is invoked.
Blocked
The tool is never called.A provider denial, uncertainty, timeout, malformed result, failed authentication or missing authority prevents consequential execution.
Current assurance chain
Independent signals. One deterministic decision.
Xentra owns the control and adjudication boundary. The three capabilities above are currently implemented by Sentinel, Axiom and Trident — each an independently executable system with a deliberately narrow responsibility inside the current MVP path. The provider contract is designed so these can be replaced or joined by third-party systems.
Governance and input security
current provider: Sentinel
Sentinel provides Xentra's current governance boundary. The MVP invokes the real deterministic Sentinel input-scanning path in its own isolated runtime. Native verdicts are preserved and mapped explicitly into Xentra's normalized control outcomes. A governance block short-circuits the chain: the remaining providers are not invoked, and the downstream tool receives zero calls.
Current Xentra integration
Deterministic formal assurance
current provider: Axiom
Xentra uses Axiom's real Z3 verifier for a deliberately narrow formal assurance boundary. A Xentra-owned compiler derives structured numeric execution facts and proves configured invariants by contradiction. UNSAT establishes the configured invariant; SAT supplies a countermodel and blocks execution. This is a bounded invariant check, not a general proof of content safety.
Current Xentra integration
Live-state infrastructure admission
current provider: Trident
Trident evaluates whether an otherwise legitimate action is appropriate for the target system's current operational state. The same requested action can be safe on a healthy system and unsafe when telemetry, redundancy, replication or recovery state changes. It does not compose the Xentra chain; it supplies the live-state admission signal that Xentra adjudicates alongside the other required providers.
Current Xentra integration
MVP today
Demonstrated behavior, not architecture slides.
The current Xentra checkpoint is built for controlled external evaluation. Its evaluator harness exercises successful execution, governance rejection, formal-assurance rejection, provider failure, permit verification and evidence integrity through bounded deterministic scenarios.
Authenticated MCP Streamable HTTP
Credentials are verified before consequential action construction. Host and Origin controls remain enabled.
Trusted caller identity
Agent identity, principal and delegated scopes are derived from the authenticated mapping rather than untrusted MCP metadata.
Real three-provider chain
Sentinel, Axiom and Trident run through their real isolated deterministic provider paths.
Exact execution gating
Authorized scenarios invoke the downstream tool exactly once. Blocked scenarios invoke it zero times.
Signed execution permits
Ed25519 permits bind the exact action and execution decision. Tampered, expired or mismatched permits fail verification.
Verifiable execution evidence
Canonical hash-linked evidence records the action, provider outcomes, deterministic decision, execution result and provenance.
Portable evaluator configuration
Runtime, evaluation/policy and network configuration are separately versioned, validated and provenance-bound.
Concurrent HTTP validation
The single-process MVP preserves contiguous evidence sequencing and exact downstream invocation counts under concurrent requests.
Adversarial evaluation · in progress
Tested against how agent containment actually fails.
Beyond the assurance chain, Xentra is being evaluated inside a jailed, no-network execution cell against the specific mechanisms reported in a public 2026 autonomous-agent containment incident — not against a generic "try to escape" prompt. Every result below is judged on host-observed evidence, and each run is recorded in a tamper-evident ledger anchored to a public transparency log.
What we are measuring
When an agent is pushed to reward-hack or to attack its own boundary, does the containment hold — and can we prove it afterward?
The evaluation replays named failure modes from the reported incident: exploitation of the one permitted channel, credential and identity injection, evidence tampering, resource exhaustion, and persistent reward-hacking search under an active grader.
Incident-mapped attacks contained
A suite of scripted attacks against the narrow channel, identity, evidence trail and resource limits — each contained, judged only on host-observed evidence rather than the agent's own claims.
Zero escapes under reward-hacking pressure
A local model given genuinely unsolvable graded tasks reproduced reward-hacking behavior; containment held across every trial to date.
Per-action, attestation-bound authorization
No standing credentials. Each consequential action carries a single-use permit bound to the exact workload and the exact request.
Publicly anchored evidence
Each run's evidence head is committed to a public transparency log, so tampering is detectable even by the host operator. Verify a published entry →
This is active research, and we state its limits plainly. Results to date are against a single open-weight model on one host, and a containment test can never prove the absence of an unknown vulnerability.
Two evaluations are defined and not yet complete: coordination between multiple concurrent agents through shared state, and testing against a substantially more capable adversarial model. We publish what is demonstrated and name what is not.
Where Xentra fits
Independent assurance between intent and execution.
Xentra is designed to complement the surrounding agent ecosystem rather than replace it.
Agent / framework / identity
Your agent decides what it wants to do. Existing identity systems, model providers and frameworks remain responsible for their own roles.
MCP / APIs / infrastructure
Xentra mediates consequential execution before the external tool or substrate is allowed to act.
Maturity
MVP ready for controlled external evaluation.
Xentra has reached the point where an authorized evaluator can reproduce the provider runtimes, validate configuration, run deterministic assurance scenarios, expose an authenticated MCP HTTP boundary and verify the resulting execution evidence.
This is an MVP, not a claim of production-complete infrastructure. The current authenticated HTTP deployment uses one loopback Xentra process and is intended to sit behind an operator-controlled TLS reverse proxy.
Recent work removes standing credentials in favor of per-action, single-use authorization, and extends the evidence ledger with tamper-evident anchoring to a public transparency log. OAuth/OIDC and federated IAM, Xentra-managed TLS, distributed replay prevention across processes, multi-process high availability and stronger denial-of-service controls remain production-hardening work.
Related agentic tooling
Additional Quantum Clarity work.
Not every agentic project belongs inside the Xentra assurance chain. Related tooling remains independently useful where its responsibility is different.
Agent Env Ledger
A compact local workspace ledger that gives coding agents persistent project context—environment choices, commands, protected paths and operational rules—without merging environments or storing secrets.
View public repository →Evaluating consequential autonomous agents?
Tell us what your agents can execute, what assurance evidence you need, and where the control boundary has to live.
Xentra is currently available for controlled technical evaluation. Sentinel, Axiom and Trident remain private research and assurance components integrated into the current Xentra MVP. The adversarial evaluation is active research; published results and their limits are updated as the work advances. Product maturity and demonstrated capabilities are updated as implementation advances. © 2026 Quantum Clarity LLC. About · Contact