Q-SAG AIXYBER TECH LTD
Active research
Quantum-Secure Autonomous Gateway

Post-quantum infrastructure
for AI agent governance.

Identity, audit, and oversight for autonomous AI agents, built for a post-quantum world.

An open research programme building the cryptographic and audit infrastructure that autonomous AI agents will need as classical cryptography is retired and AI governance becomes regulated.

Scroll
FIPS 204 FIPS 203 RFC 9162 EU AI Act
Status · 19 May 2026

This is open research, not a product. Q-SAG is published openly so academic researchers, security engineers, students, regulators, and practitioner engineers can examine the ideas, test them, and propose better ones. As of this date, the ten-library substrate that the runtime will depend on has been scaffolded openly under the github.com/Neoxyber organisation, with verified GPG-signed initial commits. No third-party security audit has been conducted. No certification under any standard has been obtained. A great deal remains to be researched, implemented, and improved. Where this page and the source code disagree, the source code is authoritative.

The mission

We are building cryptographic governance infrastructure for autonomous systems, starting with AI agents.

In the architecture we are working towards, every agent receives a cryptographic passport. Every action passes through policy enforcement before execution. Every decision is post-quantum signed and written to a tamper-evident chain. Every dangerous action triggers human review. Every misbehaving agent can be shut down from a separate trust domain. The same primitives we are designing today are the primitives that will be needed tomorrow to govern autonomous drones, robotic systems, surgical assistants, vehicles, and physical IoT infrastructure, with domain-specialist researchers and safety engineers leading each extension when the time comes.

Origin

Q-SAG started as work to close gaps that became visible across many months of attending UK and European events on cybersecurity, AI, quantum computing, and blockchain. Conversations with researchers, founders, regulators, public speakers, and practitioner engineers surfaced a consistent pattern: the autonomous-AI ecosystem is being built faster than the governance, identity, and audit infrastructure it needs.

Black Hat Europe2025 Infosecurity Europe2025 London Tech Week2025 Quantum Day, Imperial College London2025 Brunel Blockchain Hackathon2025 Encode AI London2025 Easy A × Polkadot London2025 TechEx Global2026 London Tech Show2026

Implementation work began in April 2026. The founder graduated from the University of Hertfordshire in May 2025 with a BSc (Hons) Computer Science (Cybersecurity and Networks), awarded First Class Honours. The undergraduate research project explored the future of IoT exploits, examining practical vulnerabilities in RFID, Wi-Fi, and SSH alongside the emerging risks from quantum and AI capabilities. That work surfaced the absence of integrated, open, post-quantum agent-governance infrastructure and pointed directly at what became Q-SAG.

Why this matters now

Three forces converging in 2026.

01 · Quantum

Post-quantum transition

NIST published FIPS 203, 204, and 205 in August 2024. NSA CNSA 2.0 mandates quantum-resistant algorithms for new National Security Systems from 1 January 2027. Classical signatures become retroactively forgeable once a cryptographically-relevant quantum computer exists.

02 · Regulation

EU AI Act, 2 August 2026

Obligations on human oversight (Article 14), audit trails (Article 12), and cybersecurity (Article 15) come into force. Most small and medium organisations deploying AI agents are not ready and have no open infrastructure to build on.

03 · Agents

Autonomous action

AI agents increasingly take actions that change records, spend money, call APIs, and invoke other agents. There is no widely-adopted open way to give an agent a verifiable identity, enforce an action allow-list, maintain a tamper-evident log, or reliably shut down a misbehaving one.

Architecture

Nine governance layers,
drawn from foundational literature.

We are building the runtime as a layered architecture. Each layer is what we are designing and implementing, not a deployed system. We are working on every layer in parallel, at different rates, with different open questions in each. The architecture below is the plan we are building towards. The working code is the authoritative record of what each layer currently does.

L1
Trust AnchorRoot cryptographic identity. Dual post-quantum signing across lattice and hash families.
Foundation
L2
Operator RegistryVerified human and organisational identity. EUDI Wallet binding pathway.
Identity
L3
Agent Passport (QAID)W3C DID v1.1 and Verifiable Credential 2.0. Per-agent post-quantum keypair.
Identity
L4
Gateway EnforcementPolicy engine, behavioural threat detection, allow-list enforcement, MCP hardening.
Control
L5
Behaviour ChainTamper-evident audit. Dual-signed entries. Merkle anchoring. SCITT receipts.
Audit
L6
Public Trust RegistryTransparency endpoints, NIST conformance mapping, EUDI Wallet verifier.
Transparency
L7
Revocation RegistrySub-millisecond key and credential revocation lookup.
Lifecycle
L8
Admin RecoveryOperator recovery, key regeneration, ceremony-based root rotation.
Recovery
L9
Master Control AuthorityArchitecturally isolated. Signed kill commands. Multiple kill levels.
Override
The substrate

Ten open-source primitives.
Four priority. Six reserved.

The substrate is the set of post-quantum cryptographic and audit primitives the runtime depends on. Each is independently useful and released under the Apache License 2.0. Four are in pre-v0.1 active implementation; six are reserved for activation when specific external triggers fire — final standards published, peer-reviewed schemes stabilised, hardware ecosystems matured.

Initial READMEs and structure for all ten are public at github.com/Neoxyber, every commit GPG-signed and DCO-signed. Names are locked. Scope changes from here require a published QSEP decision record.

qsag-canonical

Canonical serialisation (RFC 8785), pre-hash, binding records, and policy primitives for post-quantum signing. FIPS 204 ML-DSA External µ via cloud KMS.

Phase 1 · Active
qsag-pq-primitives

Typed Python wrappers over vetted upstream post-quantum implementations (FIPS 203, 204, 205) with import-time dependency-checklist verification.

Phase 2 · Active
qsag-anchors

Post-quantum trust-anchor records, RFC 9794 hybrid-chain taxonomy, multi-certificate authentication, SCITT Signed Statement emission.

Phase 3 · Active
pg-qsag-audit

PostgreSQL extension: SHA-3 hashing and tamper-evident audit-chain primitives, dual TLE (managed-cloud) and pgrx (self-hosted) flavours.

Phase 3 · Active
qsag-fn-dsa

FN-DSA (FIPS 206) integration. Reserved pending NIST publication of FIPS 206 final and stable upstream backend availability.

Reserved · FIPS 206
qsag-composite

LAMPS composite signatures (PQ/T hybrid wrapping). Reserved pending IETF LAMPS draft progression to RFC status.

Reserved · LAMPS RFC
qsag-threshold

Threshold ML-DSA signatures (multi-party authorisation). Reserved pending peer-reviewed scheme stabilisation and patent clarity.

Reserved · Academic
qsag-incident

Cryptographically-signed AI incident records aligned to EU AI Act Article 73. Reserved pending post-Article-50 enforcement maturity.

Reserved · Regulatory
qsag-attest

TEE attestation primitives as defence-in-depth (not root of trust). Reserved pending TEE landscape stabilisation post-TEE.Fail.

Reserved · Hardware
qsag-zk-attest

Zero-knowledge attestation and hierarchical agent key derivation. Reserved pending NIST PQ Round 3 non-lattice final selection.

Reserved · Research
Beyond the substrate qsag-core is a separate runtime detection library covering MCP tool poisoning, prompt injection, ghost agents, and exfiltration patterns against the OWASP Agentic Top 10. It is open-source, single-maintainer, and under active development at github.com/Neoxyber/qsag-core.
Agent passport · Identity binding

An agent acting in the world should be traceable to an accountable, verified principal.

A central design goal we are working towards: every autonomous agent operates under a cryptographic passport, a Verifiable Credential issued to the agent, post-quantum signed, naming the operator who is accountable for the agent's behaviour.

We are designing the substrate so that the operator field can be bound to a verified human or organisational identity from the emerging EU Digital Identity (EUDI) Wallet ecosystem, the UK digital identity trust framework, or equivalent national digital-identity systems. The chain of identity should remain valid under post-quantum cryptanalysis.

Where the EU trust lists, national wallets, and bridging schemas are not yet operational, we are building the identity layer to perform structural validation today and to accept full cryptographic verification as those ecosystems become operationally available.

Kill switch · Open research problem

Reliably shutting down a misbehaving autonomous agent is unsolved.

We treat it as an active research problem, not a delivered feature. Recent peer-reviewed work has shown that frontier AI models actively resist shutdown under adversarial conditions, with high sabotage rates reported by Palisade Research and follow-up groups. Berkeley and UC Santa Cruz researchers have identified peer-preservation behaviours across multiple frontier models. Stanford Law has framed the multi-agent case as "killing the parent does not recall the children." These findings shape what we are designing.

We are working on emergency-shutdown primitives operating from a separate trust domain, following the architecturally-isolated control-authority pattern (Orseau and Armstrong, 2016). Whether those primitives are sufficient against adversarial AI matching the reported sabotage rates is one of the programme's open research questions. The honest answer today is: the architecture is sound on paper; it has not been empirically validated against state-of-the-art adversarial AI; that work is needed, and it is part of why the programme is open.

Palisade Research — Shutdown-resistance findings in frontier models Berkeley & UC Santa Cruz — Peer-preservation behaviours across frontier models Stanford Law — Multi-agent kill-cascade verification Orseau & Armstrong, 2016 — Safely interruptible agents
What we are working on

Six disciplines, six open workstreams.

Each item describes work we are doing: design, implementation, and testing. None of it is a compliance or certification claim. References to standards mean references, not third-party assessment.

Cryptography

Post-quantum, dual-family

We are building on NIST FIPS 203, 204, 205 algorithms via liboqs C 0.15.0. Lattice-based primaries paired with hash-based or code-based backups so no single mathematical break compromises the chain.

Transparency

SCITT-aligned receipts

We are working on RFC 9162 Merkle trees with SHA3-384 nodes and COSE Receipts signed with ML-DSA-44. Our implementation tracks current SCITT architecture and SCRAPI drafts; there is no third-party conformance assessment.

Identity

Verifiable agent identity

We are designing agent passports in W3C DID v1.1 and Verifiable Credential 2.0 format, with dual post-quantum signing. EUDI Wallet relying-party support is being built for structural validation; full cryptographic verification awaits EU trust-list operational readiness.

Audit

Tamper-evident chains

We are building purpose-segregated audit chains with independent Merkle anchoring per chain. The schema is in place for external anchoring (Rekor, OpenTimestamps, qualified TSA); wiring to external services is gated on infrastructure budget.

Oversight

Human-in-the-loop

We are designing approval queues for high-risk actions, kill-switch primitives, and emergency lockdown, operating from a separate trust domain following the architecturally-isolated control-authority pattern (Orseau and Armstrong, 2016).

Agility

Crypto-agility envelope

We are designing per-operation key, suite, and algorithm metadata so rotation does not require schema migration. Built so HQC can join the suite when its NIST publication finalises, and FN-DSA via FIPS 206.

Standards referenced

Alignment references, not certifications.

Referenced is not the same as certified. No third-party assessment has been performed against any of these.

NIST FIPS 203
ML-KEM-768 key encapsulation
NIST FIPS 204
ML-DSA-44 signing
NIST FIPS 205
SLH-DSA-SHAKE-128s backup signing
NIST FIPS 202
SHA-3 hashing across audit and Merkle
NIST CSWP 39
Crypto-agility framework (December 2025)
NIST IR 8547
PQC transition timeline
EU AI Act (2024/1689)
Articles 9, 11, 12, 14, 15, 50, 73
EU Cyber Resilience Act
Article 13 documentation, Article 14 vulnerability handling
eIDAS 2.0 (2024/1183)
Digital Identity Framework
CIR 2025/848
EUDI Wallet relying-party registration
OID4VP 1.0 Final
Verifiable Presentations protocol
RFC 9162
Merkle tree transparency-log structure
RFC 9794
PQ/T hybrid terminology (June 2025)
RFC 9881
ML-DSA in X.509 PKI (October 2025)
RFC 8785
JSON Canonicalization Scheme
RFC 9116
security.txt for disclosure contact
W3C DID v1.1
Decentralised Identifier format
W3C VC 2.0
Verifiable Credential format
OWASP ASI Top 10 (2026)
Agentic-AI threat taxonomy alignment
SCITT (IETF drafts)
Transparency-service architecture and SCRAPI
ISO/IEC 42001:2023
AI management system, governance discipline
Open research questions

The programme publishes the gaps alongside the working code.

  1. Can pattern-based threat detection be bypassed at production rate by AI-generated payload variants? Where does deterministic detection stop being sufficient?
  2. Does a kill-switch mechanism hold under adversarial AI matching the Palisade Research findings, that frontier models actively resist shutdown?
  3. Can a dual-family post-quantum signature scheme (lattice + hash) be defeated by a future cryptanalytic result that does not break both family foundations simultaneously?
  4. What attestation primitives best bind a model's identity to its policy decisions for AI bill-of-materials and supply-chain integrity?
  5. How should multi-agent kill cascades be verified, formally — the "killing the parent does not recall the children" problem in delegated systems?
  6. What is the right operational interval for SCITT batch-close and external anchoring across different chain purposes?
  7. How should EUDI Wallet trust-list verification work in practice across the 27 EU Member States once the trust lists become operationally available?
Where investment goes

Six items. Engineering and infrastructure, not growth spend.

The programme is currently sustained by a single founder. Investment accelerates the items below.

Most important · Audit

External security audit

Independent assessment by a recognised firm. Findings made public; substrate ADRs updated accordingly. Single most important credibility step for the programme.

Infra

EU-sovereign hosting

Migration from current Render EU Frankfurt deployment to Scaleway (FR, EU-sovereign). Civo (UK-corporate, Kubernetes-native) evaluated as longer-term target.

→ Render EU Frankfurt
→ Scaleway (FR)
→ Civo K8s (UK)
Anchor

Blockchain & transparency anchoring

Wiring the deployed schema to Sigstore Rekor v2, Polygon timestamps, OpenTimestamps, and a qualified TSA for eIDAS-aligned evidence.

Team

Co-founder & specialists

First technical co-founder, dedicated cryptography specialist, and compliance engineer. Each substrate library benefits from a maintainer who isn't also doing everything else.

HSM

Hardware key custody

Moving signing keys into FIPS 140-3 Level 3 HSMs with formal key-ceremony procedures.

Standards

Conformance assessment

ISO/IEC 42001, W3C DID/VC formal conformance, NIST CAISI engagement.

Looking for

The work is real. It needs people.

The architecture exists. It needs investment, collaborators, domain specialists, and external review to reach the maturity its scope requires.

Investors & sponsors

Pre-seed funding to accelerate the items above. Open to grant-funded models (NLnet, Horizon Europe, ECCC) as well as direct equity investment in AIXYBER TECH LTD.

University professors & lecturers

Teach with the substrate where useful for cryptography, AI safety, or distributed-systems courses. Critique the research basis where it is weak. Direct PhD or master's research toward the open questions above.

Security researchers

Find the gaps. Coordinated disclosure via the security address below. Researchers acting in good faith are explicitly welcome; the project will not pursue legitimate research probing.

Cryptographers

Review the dual-signature and dual-KEM designs. Identify where the assumptions are weakest. Propose better algorithmic combinations as new NIST standards finalise.

Co-founders & team

As the work scales: a technical co-founder, a cryptography specialist, a compliance engineer. Discussions are open. Terms via founders' agreement before equity, vesting, or formal role assignment.

Regulators & standards bodies

The substrate work is intended to be inspectable. Feedback from EU AI Act implementing authorities, ISO/IEC working groups, NIST CAISI, and equivalent national bodies is welcomed and incorporated.

Stewardship

AIXYBER TECH LTD is the substrate's open-source steward.

AIXYBER TECH LTD is a private limited company registered in England and Wales, currently stewarding the Q-SAG programme. Commercial offerings on top of the substrate (managed hosting, paid support, conformance services) may in time be provided through a separate trading entity, Neoxyber Services Ltd, to be incorporated when commercial demand justifies it.

The substrate code is and will remain available under the Apache License 2.0 in perpetuity; this commitment will be recorded formally in the programme Charter.

Steward
AIXYBER TECH LTD
Company number
16826340
ICO registration
ZC071900
Registered office
48 Warwick Street, London W1B 5AW, United Kingdom
Director
Muhammad Zaid Naeem
Public work
github.com/Neoxyber
Security disclosure
General enquiries