The wallet assistant and its governance

From the white paper: sections 4.3 and 5.5 describe an assistant that guides people in plain language, acts only within a scope the person grants and can revoke, and leaves a log the person can audit; this page gives the mechanism and its governance.

Start with what exists: nothing. No assistant, agent or model code exists in any layer of the Civitas stack today. The wallet assistant Research: no shipped code; pilot-ready target late 2027 is a funded research and development track, and this page records the design it will be built against, not running software. The governance model is being settled before any agent code is written, not retrofitted afterwards. One narrow piece already runs, with no AI involved: when a verifier asks for a credential the holder lacks, the wallet finds the interaction that issues it and routes the holder there Live. The assistant is designed as an optional layer over that deterministic wallet, which works fully without it.

What the assistant is designed to do. A chat-style interface will guide people through goal paths in plain language, adapted to local language and literacy level. The assistant will watch credential expiry dates and changes in service requirements, and warn people before either becomes a blocker. For steps the person has authorized, it will act: request a credential from an issuer, present a proof to a verifier, complete an eligibility check. Its answers will be grounded by retrieval over a curated base of service requirements and local rules, maintained per country; keeping that base accurate is a cost a pilot must establish.

Delegation, not a mandate. Before the assistant may present any credential without asking each time, the holder will grant a bounded authorization naming which credential types, to which classes of verifier, for which goal paths, and for how long; anything outside that scope will fall back to a per-interaction prompt. The authorization is designed to be bound to a verifiable credential naming the human principal, the delegated scope, and its time or transaction limits, so every assistant action carries an auditable chain back to the person who authorized it. This is the authenticated-delegation pattern now converging in standards work: short-lived, narrowly scoped delegation credentials, and no agent extending its own privileges without renewed authorization. Every assistant-initiated presentation will be logged on the device, where the holder can read it, and the holder can withdraw the authorization at any time without losing any credential; the flow then returns to per-interaction consent.

The privacy trade-offs, stated plainly. To reason usefully the assistant must read more of the wallet than any single verifier ever sees: which credentials the holder has, when they expire, what the holder is trying to achieve, and where they are. The design rule is that reasoning over wallet context happens on-device wherever possible. But conversational language modeling, and anything that depends on a provider's current requirements, has to reach a server: cloud-hosted language models behind a cloud-portable specification, so a partner can run the layer on its own infrastructure, including open-source model stacks. Where that line falls on a low-cost handset is itself a research question. Only the minimum necessary, non-identifying information is meant to leave the device. The assistant will also consume outside content (service requirements, verifier requests, guidance pages), which makes it a standing target for prompt injection aimed at inducing over-disclosure; the defense, treating every retrieved input as data rather than instruction, has to be demonstrated against real attempts, not asserted.

Constraints that hold regardless of reasoning. Disclosure stays bounded by what the wallet already enforces today: the verifier defines the parameters of each interaction, the wallet presents only the attributes that interaction asks for, and nothing leaves the wallet without the holder's consent, given per interaction Live or, once built, through the bounded authorization above Research. Whatever the assistant concludes, it will not be able to present an attribute the interaction does not ask for, nor one the holder has not approved. A registry-level check of the attributes each verifier may request belongs to the trust registry's design and is not built Research; it would add a second bound, not replace this one. And consequential decisions will stay with the person: the assistant will execute specific, pre-authorized steps and hand anything else back to the holder rather than improvising.

What a pilot must show. Before this layer is presented as infrastructure, a pilot has to demonstrate:

• a delegation scope granted, enforced and revoked end to end;
• an evaluation pipeline, including prompt-injection cases, that a new model version must pass before it reaches users;
• a real goal path completed by a real user within the ninety-day target;
• the measured running cost of a completed goal path, since an assistant reasoning for many users can cost more to operate than it cost to build.

The assistant will ship as part of the open-source stack. The delegation model is targeted for 2027, the pilot-ready assistant for late 2027, and the standalone open-source component for early 2028.

Status, 2026-09-21: nothing is built; no assistant, agent or model code exists in any layer of the platform, and the delegation model, the pilot-ready assistant and the standalone open-source component are targets for 2027 to early 2028.