Spherity Policy Whitepaper
European Business Wallets as the Legal Control Plane for Zero Trust AI Agents
An action and policy whitepaper on trusted AI and business-wallet infrastructure for regulated agentic systems
Browse this paper
In brief
What does this research establish?
The whitepaper argues that technical agent identity and runtime security do not prove which legal person authorized an autonomous action. It proposes European Business Wallet identity, digital mandates, status verification, and signed action evidence as a cross-company legal authority layer for Zero Trust AI agents.
Key takeaways
- Workload identity identifies a technical actor; regulated actions also require proof of the accountable legal person and the agent's mandate.
- Authorization should be evaluated for each material action using identity, scope, purpose, status, audience, and policy context.
- European Business Wallet evidence can complement MCP, A2A, dataspace, and API interaction layers without replacing them.
- Revocation, provenance, action receipts, and cryptographic agility are necessary for accountable multi-agent workflows.
This page is an indexable summary. The PDF is the authoritative full text, including the formal model, evidence object, implementation path, and references.
About the whitepaper
Autonomous enterprise agents can select tools, call application programming interfaces, coordinate with other agents, and initiate business actions. Technical Zero Trust Architecture can authenticate a workload, constrain access, and record activity. The whitepaper examines the additional question that arises when an agent acts across a corporate or public-sector boundary: which legal person is accountable, what authority was delegated, and what evidence proves that the action was permitted?
The paper argues that the European Business Wallet (EBW), as described in the current European Commission proposal and connected to the eIDAS 2.0 trust framework, offers relevant primitives for that authority layer. These include legal-person identification, electronic attestations of attributes, digital mandates, wallet-unit attestations, trust and status services, revocation, automated machine-to-machine interaction, and signed transaction evidence.
The paper is an infrastructure-neutral architecture and policy analysis. It is not legal advice, certification advice, or assurance for a particular deployment. It treats legislative text still under negotiation as a draft policy signal rather than adopted law.
Reference architecture
The proposed design separates interaction protocols from authority evidence:
- An agent selects a tool or target action.
- A gateway describes the action, parameters, audience, purpose, and policy context.
- The acting party presents legal-person identity, agent identity, a bounded mandate, and current status evidence.
- The verifier resolves issuers, trust lists, registries, and revocation information.
- A policy engine permits, denies, or escalates the individual action.
- The gateway executes only a permitted action.
- The system records an action receipt binding the authority evidence, policy decision, status snapshot, parameters, timestamp, and trace identifiers.
Model Context Protocol (MCP), Agent2Agent (A2A), dataspace connectors, and conventional API gateways remain interaction or enforcement layers. The paper positions EBW evidence as the legal and cryptographic authority predicate evaluated before a material action crosses an organizational boundary.
Control-plane comparison
| Architectural question | Technical agent control alone | EBW-backed legal authority layer proposed in the paper |
|---|---|---|
| Who acted? | Identifies a workload, service account, certificate, or agent instance. | Links the technical actor to an identified legal person and wallet unit. |
| What was authorized? | Commonly applies session, role, service, or gateway policy. | Evaluates a bounded digital mandate for the specific action, audience, purpose, time, and delegation chain. |
| Is authority still current? | Revokes or rotates local credentials and service permissions. | Adds wallet, mandate, attribute, issuer, and governance-status checks to local security controls. |
| What crosses company boundaries? | Relies on bilateral federation or locally configured trust. | Presents verifiable identity and authority evidence that counterparties can validate against shared trust information. |
| What evidence remains? | Produces application, gateway, identity-provider, and security logs. | Adds a signed action receipt that binds legal principal, mandate, status snapshot, policy decision, and action details. |
| How are protocols composed? | Each protocol manages its own identity and authorization integration. | Applies the same external authority predicate across MCP, A2A, dataspace, and API events. |
| How is cryptographic migration handled? | Depends on each local identity and logging component. | Calls for algorithm identifiers, hybrid or post-quantum profiles, rollover policy, and long-term evidence preservation across the authority chain. |
The two columns are complementary rather than mutually exclusive. The proposed EBW layer does not replace workload identity, sandboxing, service meshes, data-loss prevention, runtime monitoring, or incident response.
Two complementary trust planes
The legal control plane addresses who may act: the accountable legal person, the agent identity, the delegated mandate, the action scope, the relying party, the current status, and the evidence retained after execution.
The complementary data-plane architecture in Evidence Graphs for Industrial AI addresses what evidence supports the action or conclusion: provenance, source attribution, validation, freshness, transformations, conflicts, uncertainty, and traversable evidence paths.
A valid mandate does not prove that an AI output is factually supported. Reliable evidence does not prove that an AI agent was legally authorized to act. Regulated AI systems require both layers.
Boundary conditions
An EBW-backed authority layer does not establish that a model output is true, eliminate prompt injection, guarantee safe autonomous behavior, or replace human oversight. Its narrower purpose is to make legal identity, delegation, revocation, cross-domain attribution, and audit evidence machine-verifiable. Model quality and runtime security remain separate control domains.
The proposal also depends on final European Business Wallet legislation, implementing rules, standards, trustworthy wallet and credential providers, interoperable status infrastructure, privacy-preserving data minimization, and operational conformance. The paper therefore presents a reference architecture and standardization agenda, not a claim that the complete infrastructure is already available.
The complete PDF contains the detailed architecture, stakeholder requirements, standardization agenda, formal model, proof sketches, and 28 referenced sources.
Open research
License and citation
European Business Wallets as the Legal Control Plane for Zero Trust AI Agents is licensed by its named author under the Creative Commons Attribution 4.0 International License (CC BY 4.0). Reuse must credit every named author, link to this canonical version and the license, and indicate whether changes were made.
How to cite this work
Dr. Carsten Stöcker (2026-06-01). “European Business Wallets as the Legal Control Plane for Zero Trust AI Agents: An action and policy whitepaper on trusted AI and business-wallet infrastructure for regulated agentic systems.” Spherity GmbH. https://spherity.github.io/spherity-research/ebw-zero-trust-ai-agents.html. Licensed CC BY 4.0.
Direct answers
Questions this research answers
What authority problem remains after an AI agent has a technical identity?
A certificate or workload identifier can show which software instance acted, but it does not by itself prove which legal person is accountable, whether that organization issued a valid mandate, or whether the mandate covered the exact action at the time it occurred.
What does a European Business Wallet add to Zero Trust AI?
The paper maps legal-person identification, electronic attestations, digital mandates, trust and status services, revocation, wallet attestations, and signed evidence to the authorization and audit requirements of regulated autonomous actions.
Does the proposed control plane replace MCP, A2A, dataspace connectors, or API gateways?
No. Those technologies remain interaction and enforcement surfaces. The proposed wallet layer supplies external evidence about legal identity, delegated authority, current status, and accountability before a material action is permitted.
Does legal authority prove that an AI agent used reliable data?
No. The control plane establishes identity, mandate, scope, status, and accountability for an action. A complementary data plane must establish the provenance, validation, freshness, uncertainty, and evidence path supporting the agent's conclusion.