---
title: "Agentic Government Reference Architecture"
description: "An agentic government reference architecture: bounded delegation, service-side enforcement and citizen-visible evidence."
keywords: "agentic government architecture, reference architecture, bounded mandate, mandate, agent identity, workload identity, authorization, confirmation, receipt, X-Road, Estonia, agentic government, agentic state, agentic gov, govtech, gov tech, AI agents in government, public services"
canonical: https://agenticgov.eu/architecture
url: https://agenticgov.eu/architecture
---

v0.2.1 · draft · updated 18 September 2026

# Agentic Government Reference Architecture

A proposed authorization architecture for AI agents acting on behalf of citizens: bounded mandates, workload identity, service-side enforcement, transaction confirmation and auditable receipts. An architectural proposal derived from the essay, not a deployed national system.

![Overview of the citizen, mandate registry, protected agent client and public service. A structured description follows.](https://agenticgov.eu/figures/personal-state-authorization-flow.jpg)

Figure 1. The personal-state authorization flow: a control plane above a peer-to-peer data plane in the X-Road pattern. The citizen binds and revokes; the registry issues a scope-bound credential; the agent presents it with proof of possession; the public service verifies and decides; consequential writes step up to the citizen’s eID device; the signed record flows back to the citizen’s data tracker. [Open the original diagram at full size](https://agenticgov.eu/figures/personal-state-authorization-flow.jpg)

Read the diagram as structured text

1. **Control plane.** The registry publishes agent identifiers and public keys, citizen-defined delegations and limits, and mandate status. The citizen binds and revokes a mandate; the issuer returns a scope-bound credential.
2. **Status distribution.** Public services pull and cache signed status. Push signals can shorten revocation delay. These checks distribute trust; ordinary requests do not travel through the registry.
3. **Citizen to agent.** The citizen instructs the software. Untrusted email, documents, web pages and tool output can influence a proposal, but cannot expand the signed mandate. The citizen’s signing key stays outside the agent.
4. **Agent to service.** The protected client presents the credential and proof of key possession to the public service. The workload presents its own identity evidence. The service checks issuer, audience, key binding, expiry, status and the strictest applicable limits.
5. **Service outcomes.** An in-scope request may be permitted. Insufficient authority is denied. A consequential request may require confirmation, with rate limits on repeated prompts.
6. **Confirmation.** The service supplies the exact transaction details through a trusted surface outside the agent. The citizen approves there; a signature is required only for the applicable action class. The service rechecks the bound transaction at commit.
7. **Receipt and objects.** The service returns an attributable record to the citizen’s data tracker. Evidence identifies the principal and actor, key binding, audience, authorised actions, status and expiry. Mandate records, credentials, presentations, service tokens and downstream grants have distinct lifetimes.

The original illustration uses shorthand. The current specification separates the protected client from the untrusted agent, sets lifetimes per object, and requires a qualified signature only where law or service policy requires one.

**Citizen mandate** Who authorised this action?

**Workload identity** Which running workload is asking?

**Public service** Current policy · resource state · strictest limit

**permit** Within current authority

**confirmation_required** Wait for exact human approval

**deny** No action; return the reason

The trust plane distributes issuer and status information. Requests travel directly to the service. Identity proves who is asking; the mandate bounds what they may do.

### Follow an action, end to end.

From a person’s intent to a service’s receipt. Expand each step to see who is responsible.

01 Authenticate the principalCitizen · trusted identity channel

The person authenticates with an accepted eID. If acting for an organisation, the service checks the right of representation against an authoritative source.

02 Register the agent relationshipCitizen · agent operator

Bind the logical agent, responsible operator and allowed holder key. A trusted interface shows the citizen exactly which services and actions are requested.

03 Create the mandateCitizen · mandate issuer

Fix the audiences, actions, resources, limits, purpose, validity and delegation depth. Verify that the principal is legally able to grant this authority.

04 Issue the credentialMandate issuer

Issue only necessary claims and a verifiable status reference. Attestation of the running workload remains a separate responsibility of its operator.

05 Present both chainsProtected agent client

Present the required mandate claims, a fresh verifier-bound proof and evidence of the running workload. Keep key use outside the untrusted model.

06 Verify and bindPublic service · trusted code

Verify issuer trust, schema, signatures, disclosures, validity, status freshness, audience, nonce, replay protection and the relationship between agent, operator, workload and key.

07 Issue narrow service authorityService authorisation server

When repeated calls are needed, issue a short-lived token bound to one audience and a key. The token does not freeze the service’s business permissions.

08 Decide the concrete actionPublic service · enforcement boundary

Combine mandate constraints with current ownership, eligibility, workflow, tenant, cumulative limits and policy. The strictest bound wins. Return permit, confirmation_required or deny.

09 Confirm when requiredCitizen · trusted confirmation channel

Freeze the exact transaction. Display authoritative details outside the agent. Bind approval to the action, resource version, material values, payload digest, nonce and expiry. Recheck policy before commit.

10 Execute and return evidenceDeterministic command boundary

Commit the action idempotently. Record the actor and authority chain and return a citizen-visible receipt. If execution is uncertain, reconcile the original operation rather than issuing a second one.

## Scope and responsibility

This draft translates the accompanying essay into a compact architecture. It covers the authority to act, the evidence a service must check and the record returned to the person. It does not specify a national registry implementation, choose a model, or establish legal powers. It is a proposal derived from Alvar Laigna’s writing, not a separately published standard.

The order of work is **need → process redesign → legal authority and safeguards → operational readiness → bounded agent → measurable outcomes**. Start with a service failure worth fixing. Measure completion, time, avoidable contacts, accessibility, errors, appeals and staff workload.

## Three lanes of assistance

**Information and navigation.** An agent explains a service, finds authoritative information and directs the person to the right channel. It does not change rights, obligations or authoritative records.

**Assisted casework.** An agent collects information, prepares a draft and checks completeness. A responsible person or deterministic service rule remains the decision-maker.

**Consequential action.** An agent expresses a citizen’s intent by submitting, modifying, paying or preparing a signing flow. Explicit authority, current policy, stronger evidence, confirmation where required and a remedy path are necessary. A citizen’s representative and a competent administrative authority are different roles.

## Five objects with different lifetimes

| Object | What it carries | Owner |
| --- | --- | --- |
| Mandate record | Revocable definition of exact delegated authority | Mandate issuer or registry |
| Mandate credential | Signed, portable representation of selected mandate facts | Trusted issuer |
| Presentation | Fresh verifier-bound evidence and required holder-key proof | Citizen-controlled holder |
| Service access token | Narrow, short-lived permission for one audience and key | Service authorisation server |
| Downstream action grant | Further attenuated authority for one internal actor or command | Delegating service |

A durable mandate may legitimately last longer than an execution token. Revoking the mandate must invalidate dependent authority within a declared bound. Expiring one token does not erase the mandate. A fresh presentation must not silently become an unlimited credential.

## Trust distribution and direct service traffic

The control plane distributes trusted issuers, operator information, credentials and mandate status. It does not broker ordinary citizen-service transactions. Issuance and status distribution may contact the registry; ordinary protected operations should not require a synchronous national lookup on every call.

The data plane carries requests from the protected agent client to the public service. Two independent chains meet there: what the person authorised, and which workload presents the request. Neither chain suffices alone. Workload identity does not prove citizen intent, and a valid mandate presented by the wrong workload must fail.

The model’s context is an untrusted execution environment. Keys and trusted confirmation interfaces sit outside it.

## The service decides every protected operation

Effective authority is the intersection of **mandate scope, current service policy and citizen limits**. The service verifies evidence before considering the requested action, then applies current ownership, eligibility, workflow and resource state.

The result is explicit:

- **permit:** current authority and state allow the action;
- **confirmation_required:** the action is eligible, but the specified human approval is still needed;
- **deny:** evidence, authority, policy or state does not permit the action.

Unknown authority-bearing fields are rejected. Derived grants may only narrow audiences, actions, resources, limits, validity and delegation depth. Stronger authentication cannot supply missing authority. A new or expanded mandate is a separate process.

Cumulative limits must be enforced atomically. Repeated commands with the same idempotency key and unchanged payload return the original result; a changed payload is rejected. An uncertain result is reconciled using the original operation identifier.

## Confirmation binds what will actually happen

Where confirmation is required, the service freezes the transaction and displays authoritative details through a trusted channel. Approval binds the action, service, principal, mandate version, resource and version, material values, payload digest, nonce and expiry. The agent does not supply the confirmation screen’s text.

Signing is not delegated to the model. Current policy, status and resource state are checked again at commit and when queued work is dispatched. A receipt records the result; it does not substitute for a required signature.

Prompt injection can redirect the agent towards another action already inside its scope. It cannot expand verified authority. The service does not need to identify the injection: the proposed action remains bounded by the mandate, current policy and confirmation requirements. That is still a meaningful risk: narrow mandates limit exposure, and trusted confirmation helps the person detect a consequential change of intent.

## Revocation is a measurable contract

The maximum revocation window includes publication delay, delivery or refresh delay, verifier application delay and clock allowance. It is an end-to-end property, not just a token expiry field.

The essay proposes pilot values of five minutes for API access tokens, sixty seconds for internal grants and 120 seconds for maximum signed status age. These are design targets, not statements of national capability. Production services need resilience and service-specific freshness contracts. Re-fetching the same stale snapshot does not make it fresh.

The evaluator on this site applies the 120-second example to protected writes and fails closed. Its replay and cumulative-limit presets use supplied synthetic state; it is not a transaction store, signature verifier or real authorisation service.

## Invariants an implementation must enforce

1. The strictest bound wins: effective authority is mandate scope ∩ service policy ∩ citizen limit.
2. Every derived grant narrows audience, action, resource, limits, lifetime and delegation depth; none widens.
3. No bearer downgrade: a token presented without its bound key is rejected.
4. Audience and nonce bind a presentation to one verifier and one transaction; they never create authority.
5. Status is checked at every protected operation; a protected write fails closed beyond the signed freshness bound.
6. Approval binds the exact transaction: action, resource and version, material values, payload digest, nonce, expiry. It is consumed once.
7. An idempotency key is bound to principal, mandate, action and payload digest; reuse with a changed payload fails.
8. Cumulative limits are enforced atomically across concurrent requests.
9. Unknown authority-bearing fields are rejected, never ignored.
10. The model never holds a key, never renders a confirmation screen and never decides.

## Building blocks and their limits

| Building block | What it proves | What it does not prove |
| --- | --- | --- |
| SD-JWT (RFC 9901) | An issuer signed claims; selected claims were disclosed intact; the holder key was used | Anonymity, authorisation, revocation |
| SD-JWT VC (draft) | A credential profile for the above | A stable format until a version is pinned |
| OpenID4VP 1.0 | A verifier-requested presentation was validated | That the action is authorised |
| SPIFFE/SPIRE | Which attested workload in an operator’s trust domain is asking | Citizen intent, legal authority, model behaviour |
| DPoP (RFC 9449) | The token holder controls its key for this request | Authorisation; anything once token and key are both stolen |
| RAR (RFC 9396) | Structured `authorization_details` travelled with the request | Government action semantics or approval rules |
| Token Exchange (RFC 8693) | Evidence was exchanged for a new token | Attenuation or parent-child revocation |
| Token Status List (draft) | A signed status the verifier can fetch | Freshness or fail-closed behaviour |

## EUDI Wallet ARF 3.0 compatibility and deviations

Mapping version 0.1 · 9 September 2026 · baseline: [ARF v3.0.0](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases/tag/v3.0.0).

This is a proposed mapping, not a conformance claim. The demo implements no EUDI wallet, credential issuance or presentation. No row below is certified or interoperability-tested.

| AgenticGov element | Proposed ARF correspondence | Deviation or implementation gap |
| --- | --- | --- |
| Citizen / principal | The citizen may be a User of a Wallet Unit. | A principal can also be an organisation; ARF 3.0 leaves legal-person wallets to a separate business-wallet effort. Representation still requires national legal authority. |
| Mandate issuer | An appropriate EAA, PuB-EAA or QEAA provider could attest a mandate. | No provider category, authentic source or mandate attestation scheme is selected. A registry is not automatically a qualified provider. |
| Public service / verifier | A Relying Party, with a Relying Party Instance receiving wallet presentations. | A resource-owning service still applies its own authorisation policy after verification. No RP is registered for this demo. |

Role references: [ARF 3.0, chapter 3](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v3.0.0/docs/main/03-roles-within-the-eudi-wallet-ecosystem.md).

| AgenticGov element | Proposed ARF correspondence | Deviation or implementation gap |
| --- | --- | --- |
| Wallet or protected client | A certified Wallet Unit can protect the citizen’s credentials and keys. | Our protected agent client is a separate architectural role, not a Wallet Unit merely because it holds a key. Wallet Instance, secure cryptographic application/device, provider and attestation requirements remain to be designed. |
| Logical agent and workload | No direct Wallet Unit equivalence is claimed. | Software identity and workload identity are additional controls. An agent cannot impersonate the wallet user or inherit wallet control. |
| Confirmation surface | User approval through a trusted wallet or service surface. | Our transaction confirmation must bind the exact service action. A wallet attribute-disclosure approval alone does not establish that binding. QES requires the applicable signing flow. |

Architecture reference: [ARF 3.0, chapter 4](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v3.0.0/docs/main/04-high-level-architecture.md).

| Integration concern | Proposed alignment | Deviation or implementation gap |
| --- | --- | --- |
| Issuance and presentation | Select the applicable OpenID4VCI issuance and OpenID4VP remote presentation profiles. | Pin formats, algorithms, request/response bindings, nonce, audience and disclosure requirements. A generic SD-JWT credential or OAuth access token is not sufficient evidence of ARF compatibility. Proximity presentation is outside this pilot. |
| Mandate attestation | Define an attestation rulebook and machine-readable scheme. | Scope, resources, limits, principal/representative relationships, status and legal meaning are not yet a registered or tested wallet profile. |
| Trust metadata and registration | Use the applicable trusted lists / Lists of Trusted Entities and RP/provider registration and access-certificate mechanisms. | Our national trust plane cannot substitute its own registry for required ecosystem trust anchors. Registration scope, certificate validation and refresh behaviour remain unimplemented. |
| Status service | Verify the relevant credential and wallet status under the chosen profile. | Mandate revocation, wallet/key revocation and access-certificate status are distinct. Our proposed 120-second status-age bound and downstream invalidation are additional service-policy requirements, not an ARF guarantee. |

Protocol and scheme reference: [ARF 3.0, chapter 5](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v3.0.0/docs/main/05-data-model-and-data-exchange-protocols.md). Trust reference: [ARF 3.0, chapter 6](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v3.0.0/docs/main/06-trust-model.md).

Before claiming interoperability, name the implementing organisations and versions, establish the national legal basis for each delegated action, publish the selected profiles and threat assumptions, and run issuance, presentation, registration, revocation, replay and confirmation tests against an independent implementation. This mapping is owned by Alvar Laigna and must be revised when the baseline or pilot scope changes.

## Threats and required responses

| Threat | Required response |
| --- | --- |
| Prompt injection or malicious tool output | Content is data; structured actions validated; egress restricted; limits enforced outside the model |
| Stolen token or replayed proof | Key proof, narrow audience, freshness, replay controls |
| Wrong agent with valid evidence | Logical agent, operator, workload and holder key verified together |
| Payload substitution after approval | Approval bound to digest and resource version; recheck at commit |
| Split or concurrent transactions | Atomic counters, reservations, idempotency, cumulative bounds |
| Stale policy or revoked parent | Descendants invalidated; current policy and bounded status at each effect |
| Issuer or operator compromise | Quarantine, key rotation, isolated trust domains |
| Malicious metadata or key URL | Pinned trust roots; approved resolution paths; no token-directed fetches |

## Evidence, standards and adoption

Reuse established protocols for their actual properties: [SD-JWT](https://www.rfc-editor.org/rfc/rfc9901.html) for signed selective disclosure, [OpenID4VP](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) for presentations, [SPIFFE](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/) for workload identity, [DPoP](https://www.rfc-editor.org/rfc/rfc9449.html) for sender-constrained tokens, and [Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html) for structured action details. The essay records the proposed profile and the limits of each building block; the [sources](https://agenticgov.eu/sources) page lists every reference.

Law supplies competence, delegability, legal effect, reasons and remedies. Standards carry evidence; cryptographic validity alone does not make an action lawful. Estonia’s [HMS § 7¹ amendment](https://www.riigiteataja.ee/et/akt/109072026012) is a relevant foundation for automated administrative procedure, with its own conditions and effective dates.

Adopt incrementally: navigation and preparation, then narrow reversible actions, bounded submissions and finally consequential workflows where the legal and operational prerequisites exist. Test the denial paths before widening the mandate. The person must retain practical access to human contact, correction and review.

Operational readiness is organisational as much as technical, and each stage needs the people in place, not only the protocols. Procure problem-solving and iteration rather than a specification: a multidisciplinary team of service owner, domain expert, lawyer, ethicist and engineer; small, low-risk pilots in a sandbox; scaling only after the value is shown. Keep the junior workforce: when an agent absorbs routine work, pair junior officials with senior ones on the difficult exceptions the agent filters out, so judgement is still learned inside the institution. Set the rules before the tools: policy as code, platform guardrails, security oversight and a domain expert’s approval of changes. These criteria are summarised from the author’s [article on AI readiness in the public sector](https://alvarlaigna.com/posts/kuidas-ehitada-ai-valmisolekut-avalikus-sektoris).

**The agent is never the authority.**

[Read the essay this derives from](https://agenticgov.eu/essay) [Test the boundary](https://agenticgov.eu/principles#boundary) [The tooling map](https://agenticgov.eu/components) [All references](https://agenticgov.eu/sources)