Technology does not create public value.

Technology itself does not create new value. Public value appears only when we are willing to improve our processes and build a supportive legal framework to carry the change. If there is a real need, and a real readiness to meet it, then we can enter an AI era in which agents help citizens with everyday actions and with communicating with their government.

This is the starting point for agentic government. Everything below is downstream of it.

A capable model does not fix a fragmented service. An API does not create legal authority. A digital identity does not prove that a particular action is permitted. Automation applied to an unclear process usually makes the confusion faster, less visible, and harder to challenge.

The correct sequence is therefore not model → chatbot → integration → policy. It is:

need → process redesign → legal authority and safeguards → operational readiness → bounded agent → measurable outcomes

This is a design position, not a quotation from any regulation. It is consistent with the evidence. The OECD names institutional arrangements, coordination, data governance, common building blocks, user-centred design, and outcome measurement as the conditions for sustainable digital-government transformation. Estonia’s own Digital Agenda is unusually direct: wider use of AI in government “requires changes in work processes and information systems,” while competence, legal, and algorithmic-trustworthiness gaps remain open.

The question is not whether an AI agent can call a government API. It is whether the institution can justify, control, explain, and correct the resulting action.

In August I argued that we have the tool layer but lack the authorization layer. This post is the blueprint for that layer: mandates separated from access tokens, the citizen approval path enforced, key use isolated from the model, and revocation strictly propagated to derived grants.

Start with the service failure, not the model

Before selecting an agent framework, a public institution should name the failure it is trying to correct. Citizens do not need “AI” as a product. They may need to understand which benefit they qualify for, avoid entering the same information repeatedly, prepare an application, coordinate a life event across agencies, or get a clear answer without first learning the organisational structure of the state.

That distinction changes procurement and architecture alike. Measure the project against service outcomes: completion rate, processing time, avoidable contacts, accessibility, error and appeal rates, staff workload, unequal outcomes. Model accuracy and automation percentage are engineering measures. They are not, by themselves, measures of public value.

Three lanes of agent assistance need different rules.

Estonia’s published description of Bürokratt fits the first lane: it helps citizens find public-service information and routes them to a person when it gets stuck. That is a disciplined foundation. It should not be misread as proof that autonomous software already exercises administrative authority.

Agentic government is a delegation problem

Once an agent can do more than explain, the central technical problem is not conversation. It is delegation. Six questions have to be answerable for every action:

1. Who is the legal principal? A person, organisation, or authorized representative.
2. What may be delegated? Exact actions, resources, services, limits, purposes, time periods.
3. Which logical agent may act? The registered software actor and its responsible operator.
4. Which running workload is making this request? The deployed process, device, or protected client using a particular key.
5. Which service makes the final decision? The authority that owns the resource, workflow, and current policy.
6. What evidence remains afterwards? The actor chain, decision basis, confirmation, committed result, receipt.

These are different objects with different owners and lifecycles. Collapsing them into one bearer token creates a standing master key. A safer architecture keeps them separate.

Figure 1. The personal-state authorization flow. A control plane (the authorization registry: agent registry, delegations and limits, token status list) sits 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. This is an architectural proposal, not a description of a current national deployment. Note: The “exp - minutes, not months” label in the credential box refers to derived execution tokens, while the underlying mandate itself remains durable. Additionally, while the diagram simplifies the agent environment into a single box, the private key is held securely in a protected client outside the untrusted orchestrator.

Three properties of the diagram carry most of the weight.

The strictest bound wins. The effective authority for any action is scope ∩ service limit ∩ citizen limit. The agent cannot request what it was never granted; the service cannot be talked into more than its own policy allows; the citizen’s per-transaction and TTL limits cap both.

Injection redirects intent, not authority. The orchestrator is an untrusted execution environment. It ingests email, web pages, documents, tool output. A successful injection can change which in-scope action the agent picks; it cannot widen the scope, because scope lives in a signed credential the agent cannot mint and the service verifies independently. The agent also cannot prove why it chose an action, which is exactly why Figure 1’s step 6 (step-up confirmation) exists.

Signing is never delegated. The agent cannot proxy a signature. Figure 1’s step 6 happens outside the agent boundary: the relying party renders the transaction, the citizen signs on a device holding a non-exportable QES key, and the agent supplies no text to that screen.

The centre holds trust, not traffic

In an Estonian context this resembles a property of X-Road: the central server distributes membership and security-policy configuration, while security servers mediate the actual requests and responses. The analogy is architectural, not literal. A future national trust plane could publish trusted issuers, mandate status, and operator information without ever seeing the contents of an ordinary citizen-service transaction. The registry never brokers a transaction.

“Outside the data path” does not mean “never contacted.” Credential issuance, periodic status distribution, and exceptional identity resolution still touch the control plane. What the baseline forbids is synchronous consultation of a national service on every ordinary action.

Two independent trust chains then meet at the receiving public service:

• the mandate chain, which represents what the person has authorized; and
• the workload-identity chain, which identifies the software instance or managed workload presenting the request.

Neither is sufficient alone. A valid mandate presented by the wrong workload must fail. A correctly attested workload without authority from the citizen must also fail.

Separate mandates, presentations, and access tokens

A durable mandate, a portable credential, a fresh presentation, an access token, and a downstream action grant are five different things.

The separation matters for revocation, privacy, and audit. Revoking a mandate should invalidate dependent grants within a defined bound. Expiring one service token should not erase the durable mandate. A fresh presentation should not silently become an unlimited execution credential. And “minutes, not months” applies to execution tokens, not universally to the mandate; a tax-declaration mandate that legitimately spans a month is not a bug.

Semantically, a mandate looks like this:

{
  "delegation_id": "urn:example:delegation:7d2…",
  "principal_ref": "pairwise-subject-for-this-service",
  "agent_id": "urn:example:agent:personal-assistant-42",
  "operator_id": "urn:example:operator:acme",
  "allowed_services": ["urn:service:tax-filing"],
  "authorization_details": [
    {
      "type": "urn:gov:action:submit-declaration",
      "resource": "urn:tax-year:2026",
      "actions": ["prepare", "submit"]
    }
  ],
  "constraints": {
    "purpose": "annual-tax-declaration",
    "max_submissions": 1,
    "delegation_depth": 0
  },
  "valid_from": "2026-09-05T06:00:00Z",
  "valid_until": "2026-10-05T06:00:00Z",
  "status": "https://issuer.example/status/…",
  "holder_binding": "public-key-reference"
}

This is a semantic example, not a wire schema. The real profile must fix claim names, mandatory disclosures, versioning, status behaviour, audience rules, and the relationship between a citizen-held credential and an agent workload. Two binding rules are non-negotiable: the presentation audience and nonce bind the proof to a verifier, but setting an audience cannot create service authority; and if the access-token DPoP key differs from the credential holder key, the issuer must see proofs linking both keys in the same authenticated transaction. A matching string supplied by the agent is not a binding.

What the standards can prove, and what they cannot

A credible implementation reuses standards. But standards must not be assigned powers they do not have. As of 5 September 2026, a plausible baseline:

RFC 9901’s key-binding proof binds a presentation to an intended verifier and transaction via aud, nonce, iat, and sd_hash. The verifier must decide in advance that key binding is required and reject presentations without it. OpenID4VP puts the same burden on the verifier: integrity, query satisfaction, holder binding, replay controls, and its own trust policy.

Those checks prove limited propositions. They show that an issuer signed particular claims, that selected claims were disclosed without modification, and that the presenter controlled the relevant key for this transaction. They do not prove that the citizen understood every consequence, that the agent has general legal capacity, or that a requested action is lawful.

SPIFFE proves something different again. A SPIFFE ID identifies a workload within a trust domain and may be shared by replicas, so it is not inherently a globally unique process identifier. Never put personal identifiers or business mandates in an SVID. The operator is responsible for the workload; the mandate issuer is responsible for the citizen’s delegated authority; the service verifies both.

The end-to-end flow, in ten steps

1. Authenticate the principal with an accepted eID. If the person represents an organisation, verify that representation from an authoritative source and record when it was checked.
2. Register the agent relationship: bind the logical agent, responsible operator, and allowed holder key. Show the citizen which services and actions are being requested, in a trusted interface.
3. Create the mandate: exact audiences, actions, resources, limits, purpose code, validity, maximum delegation depth. Verify the principal can legally grant it.
4. Issue the mandate credential with only the necessary claims and an authenticated status reference. Workload attestation stays a separate operator responsibility.
5. Present evidence to the service: the holder reveals required claims and produces a fresh, verifier-bound proof. The protected agent client also presents workload or device evidence.
6. Verify and bind: issuer trust, schema version, signatures, disclosures, time bounds, status freshness, audience, nonce, replay protection, and the agent–operator–workload–key binding.
7. Issue narrow service authority: if repeated calls are needed, a service authorization server issues a short-lived, audience-restricted, sender-constrained access token, as the OAuth Security BCP recommends. This token does not freeze local business permission.
8. Decide the concrete action: the service combines verified mandate constraints with current local facts: ownership, eligibility, workflow state, tenant, cumulative limits, policy.
9. Confirm when required: freeze the exact transaction, display authoritative details through a trusted channel, receive bound approval, recheck policy and state before committing.
10. Execute and return evidence: a deterministic command boundary commits the action idempotently, records the actor and authority chain, and returns a citizen-visible receipt.

The model is not trusted to perform steps 6, 8, 9, or 10 by itself. It may plan, explain, retrieve, and prepare. Trusted code verifies evidence. The service makes the authorization decision. A deterministic command boundary performs the side effect. Issuance and presentation need not recur on every API call, but enforcement, status freshness, and resource-state checks apply at every protected operation, and again when a queued operation is dispatched.

The public service stays the enforcement boundary

A government service cannot outsource its final authorization decision to the citizen’s agent, to a model gateway, or to a national registry.

A policy enforcement point sits at the resource API or command broker. A policy decision point evaluates verified context and authoritative service state. Its result is one of three explicit outcomes:

• permit — the action is within current authority;
• confirmation_required — the action is eligible but needs a specified human approval;
• deny — the evidence, authority, policy, or state does not permit it.

Stronger authentication cannot repair missing authority. If the citizen never granted the action, asking for another PIN does not make it valid. A new or expanded mandate is a separate process.

For every protected operation the service checks:

RAR carries structured authorization data, but the authorization server owns the meaning of each type and the API designer owns the allowed fields. RFC 8693 explicitly says exchange is a one-time event with no tight linkage between input and output tokens. Monotonic attenuation, every child grant strictly no broader than its parent, is therefore an architectural rule the implementation must enforce, not a property the standards give you. A shared cross-service spending ceiling likewise needs coordinated accounting or preallocated quotas; independently cached tokens cannot enforce a shared consumable budget.

Design for prompt injection as an authorization problem

An agent consumes untrusted content: websites, email, documents, messages, tool output. Prompt injection must be assumed, not treated as an exceptional model failure.

The model or planner runs outside the protected credential boundary. A hardened agent client controls credential storage, token acquisition, proof generation, request construction, and access to side-effecting tools. The model proposes a structured action; trusted code validates it against a fixed schema and the active mandate.

A non-exportable key is still a signing oracle if an attacker can invoke it without constraint. The protected client reduces exposure; the public service remains the final enforcement boundary. Host or signing-component compromise is a different threat from prompt injection and needs operator containment, not a better prompt.

Even perfect cryptography cannot stop an agent from choosing a harmful action that still sits inside an overly broad mandate. The strongest defence remains narrow scope, current business validation, and transaction confirmation for consequences the citizen should review.

Confirmation must bind the exact transaction

“What you see is what you sign” is an end-to-end property. It is not guaranteed by naming eID, Mobile-ID, Smart-ID, or a wallet. A PIN screen alone does not prove the full transaction was displayed.

For consequential actions, confirmation includes the action, service, principal, mandate version, resource and its version, material values, payload digest, nonce, and expiry. The service, not the agent, renders the authoritative transaction details. Agent-generated explanatory text cannot substitute for them. A changed payload invalidates the approval. Approval is consumed once and rechecked atomically at commit; delayed callbacks and duplicate approvals must not repeat the effect. JCS (RFC 8785) is a usable canonicalization building block, not a transaction-signing protocol.

A receipt is not a signature. It is evidence produced by the service that a request was evaluated and a result committed. Whether an act required ordinary authentication, explicit approval, multiple approvers, or a qualified electronic signature is a legal and service-policy question. eIDAS gives a qualified electronic signature the legal effect of a handwritten signature; a DPoP proof, workload SVID, or mandate token is not one. This architecture does not impose QES on every consequential write; it makes the service owner say which class each action belongs to.

Revocation needs a measurable contract

Revocation does not undo a completed transaction. It prevents future use once the relevant verifier has accepted fresh status. Checking the mandate only at token issuance is insufficient; dependent service tokens and internal grants must be invalidated.

A credible profile defines a maximum end-to-end revocation window:

publication delay + delivery or refresh delay + verifier application delay + clock allowance

A verified push event (OpenID SSF / CAEP) can shorten it, but does not prove every relying party applied the update. Proposed pilot defaults, subject to service approval:

Failure behaviour must be explicit. While a 120-second fail-closed bound is an aggressive target for a pilot, rolling it out nationally without resilient CRL fallbacks would create a single point of failure (a short CDN hiccup would halt all protected writes). However, the principle remains: if a status snapshot is older than the permitted signed age for a given service tier, a protected write fails closed. Fetching the same stale snapshot again does not make it fresh. If a command times out after dispatch and its result is uncertain, the system returns an indeterminate result with the original operation identifier and reconciles it, rather than issuing a second command blindly.

Law supplies authority; standards carry evidence

Technical delegation must sit inside the governing legal process.

Under the GDPR, a government agent processing personal data still needs a lawful basis, purpose limitation, data minimisation, security, and data protection by design. A DPIA is required where processing is likely to create high risk. Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects. The GDPR does not ban automation, and a DPIA does not create substantive public authority.

The EU AI Act is use-case and risk based. A citizen-facing agent is not automatically high-risk because government uses it; classification depends on intended purpose and actual influence. Separate Article 50 transparency obligations may apply independently of high-risk classification. Regulation (EU) 2026/1744 moved the Chapter III high-risk obligations for Article 6(2) / Annex III systems to 2 December 2027, and the Article 6(1) / Annex I obligations to 2 August 2028. Existing GDPR, administrative-law, accessibility, cybersecurity, and sector duties apply throughout the transition.

For Estonia, the Administrative Procedure Act draws the boundary. It is crucial to distinguish between a citizen’s representative and an administrative authority. When a citizen’s agent prepares and submits a form, it is expressing the citizen’s intent (tahteavaldus) as a representative. However, when a government service uses an algorithm to grant or deny a benefit, that is an automated administrative act (automaatne haldusakt) which must come from a competent authority, comply with applicable law, state its factual and legal reasoning, and say how it may be challenged. A model output is not, merely because it is digitally signed or logged, a lawful administrative act.

The division of labour:

Privacy sits in the same table. Use service-scoped principal references by default; do not expose an isikukood, a reusable agent identifier, or a common holder key to every service. Selective disclosure is not unlinkability: reusing the same credential, key, status reference, or distinctive claims enables correlation even with pairwise subjects. The citizen’s data tracker should retrieve protected receipts from services, not become a second central log of payloads.

A realistic adoption path

Agentic government should not begin by automating the most consequential decision available. It should earn authority through staged evidence.

• Stage 1 — navigation and preparation. High-volume, low-consequence services. Measure whether citizens reach the right service, complete tasks, and can still reach a person.
• Stage 2 — narrow reversible actions. Retrieve a protected document, update a low-risk preference, save a draft. Introduce mandate profiles, holder binding, workload identity, service-local enforcement, receipts, revocation testing.
• Stage 3 — bounded submissions. Clearly defined filings with exact-transaction confirmation, deterministic validation, idempotent execution, and a documented correction process.
• Stage 4 — consequential workflows. Benefits, payments, licences, and other rights-affecting processes, only after task-specific legal analysis, DPIA, AI Act classification, security validation, accessibility testing, independent oversight, and operational appeal handling.

A pilot must test denial and failure, not only the happy path. Minimum acceptance scenarios:

Keep the domain model independent of any particular national registry. A local mandate adapter can provide the same verified context as a future national issuer; delegation_id is an opaque reference, not a foreign key whose reassignment completes federation. Swap the trust adapters against a second issuer before adding a live national integration. Only reproducible runtime evidence justifies moving to the next stage.

The agent is not the authority

The promise of agentic government is not a state run by autonomous models. It is a state in which people receive practical, personalised help without surrendering control or learning the internal structure of public administration.

That future is technically plausible. We have building blocks for selective disclosure, verifiable presentations, workload identity, sender-constrained tokens, structured authorization, status distribution, and distributed service exchange. But a catalogue of standards is not an interoperability profile, and cryptographic proof is not permission.

The durable architecture is institutional as much as technical:

• the person delegates a precisely bounded mandate;
• the agent acts through an authenticated workload and protected client;
• the service enforces current law, policy, limits, and resource state;
• the person confirms the transactions that require personal judgment;
• the system records what was requested, allowed, committed, and why;
• the institution remains accountable for correction, review, and appeal.

So the first question stays the most important one: is there a real public need, and are we willing to change the process and legal framework needed to meet it?

If the answer is no, an AI agent will add another interface to the same problem. If the answer is yes, and the institution is ready, then agents can become a meaningful new layer between citizens and government: not a blank cheque, not a shadow official, but a constrained and accountable instrument for making public services easier to use.

References

• OECD — Governing with Artificial Intelligence: how AI is accelerating the digital government journey
• Estonia’s Digital Agenda 2030 (Digiühiskonna arengukava)
• RIA — Bürokratt
• X-Road Architecture
• Regulation (EU) 2016/679 (GDPR), Articles 5, 22, 35
• Regulation (EU) 2024/1689 (AI Act), consolidated
• Regulation (EU) 2026/1744 — AI Act high-risk timetable
• Estonian Administrative Procedure Act (Haldusmenetluse seadus), consolidated text in force from 01.01.2024
• Regulation (EU) 910/2014 (eIDAS), consolidated, Article 25
• RFC 9901 — Selective Disclosure for JWTs (SD-JWT)
• draft-ietf-oauth-sd-jwt-vc-19 — SD-JWT Verifiable Credentials
• OpenID for Verifiable Presentations 1.0
• OpenID Federation 1.0
• SPIFFE Concepts · SPIRE Concepts
• RFC 7800 — Proof-of-Possession Key Semantics for JWTs
• RFC 9449 — OAuth 2.0 Demonstrating Proof-of-Possession (DPoP)
• RFC 9700 — OAuth 2.0 Security Best Current Practice
• RFC 9396 — OAuth 2.0 Rich Authorization Requests
• RFC 8693 — OAuth 2.0 Token Exchange
• RFC 8785 — JSON Canonicalization Scheme
• draft-ietf-oauth-status-list-21 — Token Status List
• OpenID Shared Signals Framework 1.0 · OpenID CAEP 1.0
• OpenFGA — token claims as contextual tuples