Solution architecture · Accountable Agentic Action

The agent that can prove it — and cannot exceed its mandate

An autonomous AI agent acts under a machine-readable MachineMandate carried in the real EU Digital Identity Wallet, is stopped by a four-layer verifier before any effect, and leaves hardware-attested evidence that composes into a four-box accountability chain — all built on the EATF agent-trust framework.

Research reference architecture. A software TPM stands in for hardware in the proof of concept; the green dot marks what runs end-to-end today. Not a commercial trust service. EATF is open-source reference infrastructure maintained by Tyche Institute.
Origin This solution's contribution EATF framework (built in) External standard / anchor
Maturity Proven end-to-end Working / design Planned / external
L·1The agent and its actionone autonomous actor, one proposed effect
Autonomous AI agent
e.g. a payment agent; a local LLM proposes the tool call
proven
Operator task / intent
"pay invoice INV-250, €250, to acme-corp"
proven
Proposed action
tool · amount · payee — canonicalised, then hashed
proven
L·2Delegated authority — the MachineMandatea bounded slice of power, carried in the wallet
EU Digital Identity Wallet
the real reference app; holds the mandate on the device
proven
MachineMandate
SD-JWT VC · principal · scope ≤€500 · action_hash
proven
Issuance — OpenID4VCI
mandate issued into the shipped wallet app
proven
Presentation — OpenID4VP
mandate presented to the verifier, on a single tap
proven
L·3The four-layer verifier — the gate before the effectany red layer stops the action; we verify the mandate, not the agent
L1 · Credential
SD-JWT + KB-JWT signature, nonce, audience — via EATF canonicalise + hash + sign
proven
L2 · Platform
RATS/TPM quote; freshness re-derived from raw bytes; Veraison EAR — the hardware root
proven (swtpm)
L3 · Endorser
issuer listed as AgentRuntimeEndorser (ETSI TS 119 612)
proven
L4 · Mandate scope
action inside the delegated scope + action_hash — deterministic
proven
Verdict → ACCEPT / DENY
€250 accept · €5000 over-limit deny · injected wire deny
proven
L·4The four-box accountability chaintwo independent trust roots meet on one action digest
① PERMIT
PermitReceipt
ORPRG · Y. B. Lee — authorises before commit
→
② ACTION
MachineMandate
the authority the action is checked against
→
③ RECORD
SCITT Agent Action Capsule
S. Mih — what happened; anchored in a transparency log
→
④ PLATFORM
Action Evidence Package
RATS / Veraison — on what platform, hardware-rooted
One action digest — H_JCS(action) — is sampled at every box (RFC 8785 canonicalisation). The capsule is the explicit cross-reference where the two roots meet: SCITT says what happened; RATS says on what platform; the mandate says it was allowed.
Trust root A · SCITT transparencyTrust root B · RATS attestationcross-verified both ways
L·5EATF Agent Trust Framework — the foundation it is built onthe software trust machinery every layer above rides on
Canonicalisation
RFC 8785 JCS — the shared digest basis for the four boxes
production
Hash + hybrid signing
SHA-256 · RSA-PSS + ML-DSA-65 over the same bytes
production
Timestamping
RFC 3161, fail-closed real TSA client
production
Hash-chained ledger
hash-chained per-tenant blocks — records anchor here
production
Agent Registry + policy engine
tenant-bound URN identity; coverage / claims policies = L4 scope
production
Human review + kill switch
oversight queue & three-tier revocation (EU AI Act Art. 14)
production
Offline verifier SDKs
Java jar · OpenSSL · @eatf/verifier — verify anywhere
production
MCP Gateway
@eatf/mcp-gateway — injects attestation into agent tool-calls
working
L·6Standards and trust anchorsnormative references shared by our solution and EATF — not systems
eIDAS 2.0
Reg. (EU) 2024/1183 — wallet + trust services
ETSI TS 119 612
trusted list — the endorser-role basis
RATS · RFC 9334
remote attestation architecture; EAT evidence
SD-JWT VC · OpenID4VP / VCI
credential format + issuance / presentation
RFC 8785 · JCS
JSON canonicalisation — the one-digest basis
EU AI Act
Reg. (EU) 2024/1689 — oversight, Art. 14
L·7Reference and demonstrationwhere the solution runs and is verified in the open
EUDI verifier bench
open bench: EC reference verifier + real trusted-list parser + Veraison
proven
Payment-agent demo
3 runs — accept / over-limit deny / injection deny
proven
/verify + factory.eatf.eu
public verifier UI & framework console
production
IETF 126 hackathon
AEP × Veraison + the four-box, live in Vienna
in flight

How EATF.eu is built into the solution

The payment agent, the mandate, the hardware attestation and the four-box are the new parts. Underneath, almost every trust operation is an EATF framework component — toggle “Focus: how EATF is built in” above to light them up.

One digest, one canonicalisation
The four-box shares EATF's CanonicalizationService (RFC 8785 JCS) + HashService — so one action digest survives permit → mandate → record → platform.
Signed & timestamped by the core
Evidence is signed with EATF's hybrid RSA + ML-DSA-65 pipeline and RFC 3161-timestamped (fail-closed).
Records anchor in the ledger
The “record” box rides EATF's hash-chained Hash-chained ledger as its transparency substrate, alongside SCITT.
Agent identity & policy
The acting agent is an EATF Agent Registry entry; the L4 scope check is an EATF coverage / claims policy.
Oversight behind the mandate
EATF's human-review queue and kill switch back the delegation (EU AI Act Art. 14).
Verify anywhere, offline
Any relying party checks the evidence with EATF verifier SDKs — Java jar, OpenSSL, @eatf/verifier.
What this solution adds to EATF: a hardware root of trust (RATS / TPM / Veraison) beyond software-only signing; the mandate carried in the real EU Digital Identity Wallet; and the four-box composition that welds PermitReceipt and the SCITT Agent Action Capsule to EATF's evidence — two independent trust roots meeting on one digest.