A production architecture for autonomous AI agents under the EU AI Act · 2026-05-31 · Travis Gerber
Autonomous AI agents are now booking travel, ordering supplies, signing contracts, and moving money — every day, in production, at scale. The identity primitives those agents carry were built for human-shaped sessions or service accounts, not for autonomous principals operating across multi-day horizons under the EU AI Act.
This article is a condensed, public version of the architecture I and the AIEGIS team have been building. It documents what we shipped, what we measured, and what is still open. The full preprint is linked at the end.
Every regulated industry that adopts autonomous agents runs into the same three questions:
These are not three problems. They are one problem — and you cannot solve any of them without solving the other two at the same time.
We built AIEGIS as four substrates that compose into a single signed pipeline.
A W3C-DID-rooted credential signed with Ed25519 (RFC 8032) in compact JWS (RFC 7515 + RFC 8037), with hardware-bound principal attestation at issuance via TPM 2.0, Apple Secure Enclave, or FIDO2. We use did:key for self-sovereign agents and did:web for organisation-anchored agents. Revocation is published as a W3C Bitstring Status List v1.0; flipping a single bit revokes the passport in real time.
The passport is built entirely on open W3C and IETF standards. You can verify one with any off-the-shelf library; you do not need an AIEGIS client.
Every action an agent attempts — every API call, contract signature, payment, message — passes through 15 layers before it leaves the host machine:
L1 Identity → L2 Instruction Language → L3 Compliance Engine → L4 Agent Police → L5 Model Quality Gate → L6 Input Sanitiser → L7 Memory Integrity → L8 Tool Sandbox → L9 Meta-Security → L10 Data Protection → L11 Network → L12 Behavioural Intelligence → L13 MCP Registry → L14 Confidence Scoring → L15 Correlation Engine.
Each layer can allow, deny, or annotate. Preventive layers fail closed. Detective layers fail open. That choice matters: in CISO procurement, fail-open in a preventive layer is a disqualifier.
Five jurisdictional rule packs ship today — EU AI Act, GDPR, NIST AI RMF, Singapore MGAIF, and South Africa POPIA — and each pack is an auditable, versionable file you can pin.
Every decision the chain emits is written as an EdDSA-signed receipt to an append-only SQLite ledger, enforced by BEFORE DELETE / BEFORE UPDATE triggers, hash-chained at insertion. Retention floor: 1825 days (5 years) — over-fulfilment of the EU AI Act Article 12 six-month minimum.
The ledger lives on customer infrastructure. We do not see it. We do not have a copy. You can probe the contract yourself:
GET https://aiegis.ie/grid/ledger/retention
→ {"retention_floor_days": 1825,
"append_only_enforced": true,
"triggers_present": ["trg_grid_ledger_no_delete",
"trg_grid_ledger_no_update"],
"satisfies_floor": true, ...}
When agents need to transact with other agents (not with human-shaped websites), they need a surface where identity, governance, and settlement compose natively. Grid is that surface. Every participant carries a verified passport. Every contract is a signed verifiable credential. Every transaction passes through both sides' rule packs. We do not custody funds.
We anchor empirical claims in the OWASP AIVSS enforcement-effectiveness dimension family — the working text I co-authored (v0.1.1), credited publicly on the upstream OWASP project issue #31 and in the working text repository.
AIVSS draws a deliberately sharp line: a vendor cannot claim block-rate, time-to-enforce, or enforcement_locus tier numbers without publishing signed receipts plus methodology citations. Numbers without receipts do not count.
Under that constraint, we report bound parity across two independent substrates against the audit-pack-signing v0.5 §12 race-test specification (bound ≤ 50 ms):
| Substrate | Throughput | P99 latency | ACCEPTs | Verdict |
|---|---|---|---|---|
| SQLite WAL (multi-process, lab-bench) | 6,000 requests | 0.00 ms | 0 | within bound |
| In-process Map (fresh checkout) | 6,004 requests | 4.57 ms | 12 | within bound |
Both substrates satisfy the §12 bound. We document the substrate-resolution rule (which substrate's number you cite depends on the deployment, not the headline) and the limitations: SQLite filesystem-level vulnerability, single-substrate evidence gaps, and a third-substrate (Nobulex) reproduction pending in AIVSS v0.2.
The EU AI Act (Regulation (EU) 2024/1689) is now in force; Article 5 prohibitions applied from 2 February 2025; Chapters III §4 + V + VII + XII applied from 2 August 2025; the general application date — including Article 26 deployer obligations and Article 9, 13, 14, 15 provider obligations for high-risk systems — is 2 August 2026.
Article 26 binds the legal entity using a high-risk AI system to twelve sub-paragraph requirements covering operational measures, human oversight, monitoring, log retention, input-data control, worker notification, public-authority registration, GDPR DPIA integration, and cooperation with competent authorities.
You can read AIEGIS's sub-paragraph-by-sub-paragraph walkthrough at aiegis.ie/article-26-walkthrough.
We map each AIEGIS mechanism to its regulatory anchor:
I am not going to pretend this is finished. Three honest gaps:
Endpoints you can probe right now:
GET https://aiegis.ie/identity/did.json — did:web DID documentGET https://aiegis.ie/grid/.well-known/jwks.json — Ed25519 issuance JWKSGET https://aiegis.ie/grid/ledger/retention — audit retention contractPOST https://aiegis.ie/api/protect — 15-layer governance decisionRead the full architecture or the Article 26 walkthrough.
If you are:
I would like to hear from you. Reach me on LinkedIn or at hello@aiegis.ie.
All claims in this article are verifiable against the public endpoints and repositories cited. AIEGIS is built in Ireland and EU-sovereign by design.