The Accountable Web of Agents
A vision for an automated, data-driven future built on Solid
Draft — 2 July 2026. Prepared with AI assistance (Claude Fable 5); pending maintainer review. Status: vision statement of the @jeswr Solid suite; intended for publication as a standalone web essay, with a W3C Solid Community Group contribution and an arXiv preprint as follow-on venues (see the adoption roadmap, ROADMAP.md).
Software agents are about to conduct a large share of the world’s routine digital activity — scheduling, purchasing, negotiating, filing, coordinating. Today they are being built on the weakest possible substrate: scraped web pages, proprietary APIs, and unsigned, unattributed text passed between black boxes. Nothing in that substrate says what a piece of data means, where it came from, whether it has been tampered with, or who answers for it when an agent acts on it and something goes wrong.
This paper argues for a different substrate, assembled almost entirely from existing W3C standards. Solid gives people and organisations data stores they control, with standard authentication and access control. Integrity proofs that travel with the data make it portable and tamper-evident — verification moves with the graph, not the connection. The requirement is integrity itself; the mechanisms are several, and today’s workhorse is W3C Verifiable Credential Data Integrity: signatures over the canonicalised graph, with content-addressed hashes and selective-disclosure proofs as sibling mechanisms behind the same requirement. PROV records where every artifact came from — which agent, which activity, acting for whom. ODRL expresses the policies and agreements under which data may be used — and, critically, makes the owner of an agent legally accountable for what that agent does, because the agreement the agent operates under is an explicit, signed, machine-readable artifact. Data federations — sector-scoped agreements on vocabularies, shapes, and membership — make independent applications and agents actually interoperable rather than merely co-located.
On this substrate, agents speak machine-readable data first: they exchange typed, SHACL-validated RDF whose meaning is pinned by shared vocabularies, and fall back to natural-language agent-to-agent protocols only at the edges, to negotiate what has not yet been formalised. The result is an agentic web where interoperability is the default, verification replaces trust-by-reputation, and accountability is complete: every assertion an agent makes can be traced through a provenance chain to a signed authorization from a legally identifiable owner, under an explicit usage agreement.
We describe the vision, the stack, and a worked accountability scenario; we inventory the working software that already demonstrates each layer — a from-scratch Solid server and application suite, signed-credential / policy / agent-protocol libraries, a federation vocabulary and registry, and a draft specification for access-controlled SPARQL query — and we set out an adoption roadmap through the standards bodies and data-infrastructure institutions that could make this the normal way software works.
Two futures for the agentic web
The current wave of AI agents is colliding with an old problem. The web that humans read was never designed for machines to act on. An agent that books travel, renegotiates a utility contract, or assembles a medical history today does so by scraping pages, driving browsers, and calling proprietary APIs — each integration bespoke, each output unsigned, each action deniable.
Two futures follow from this, and the difference between them is infrastructural, not algorithmic.
The friction of acting on an unstructured web is resolved by intermediation. A handful of platform operators wrap the world’s services in their own agent frameworks; your agent works because it is their agent, running in their cloud, under their terms, on data they hold. Interoperability exists only inside each walled garden.
Accountability is whatever the platform’s terms of service say it is. This future is already being built, by default, at speed.
The friction is resolved by structure: data that describes itself, carries its own proofs, names its own provenance, and states its own terms of use — held in stores that the people and organisations it concerns actually control. Agents in this future do not need a platform to mediate, because the data itself is the interface.
This future has to be built deliberately. Almost all of its components already exist as W3C Recommendations; what has been missing is their integration — and working software that demonstrates the integrated stack end to end.
This paper is a statement of intent to build the second future, a description of the stack that makes it possible, and an honest inventory of how much of it already runs today.
1.1 Design principles
Five principles organise everything that follows:
- 1
Data-centric, not app-centric. Applications and agents are views and actors over data that outlives them, stored where its subject controls it. No application owns the data it touches; losing an app must never mean losing the data ([SOLID]).
- 2
Machine-readable first. Agents exchange typed RDF validated against shared shapes, so the meaning of a message is fixed by public vocabulary, not inferred per-message by a language model. Natural language is the fallback for what has not yet been formalised — the negotiation channel through which new machine-readable protocols crystallise, not the default transport ([AGORA], [A2A]).
- 3
Verification over trust. A claim is believed because a proof verifies — a signature over a canonicalised graph, checked against a key bound to an identity — not because of who operates the server it came from ([VC-DI], [RDFC]).
- 4
Accountability is legal, not just technical. Every autonomous action must be traceable to a legally identifiable party who answers for it. The technical chain — provenance records, signed authorizations, explicit usage agreements — exists to make that legal accountability operational ([PROV-O], [ODRL-IM]).
- 5
Decentralised by construction. No single codebase, vendor, or standards owner. Sector-level interoperability is achieved by federations — published vocabularies, shapes, and membership registries that any party can implement independently — not by everyone adopting one platform.
The stack
The stack has five layers. Each is an existing standard or a thin, published extension of one; the contribution is the integration.
2.1 Solid: storage you control
[SOLID] provides the base: every person, organisation, and agent has a WebID — an HTTP URI that dereferences to a profile document — and one or more pods, personal data stores addressed and manipulated over plain HTTP (the Linked Data Platform reading of REST). Authentication is [SOLID-OIDC] with [DPOP] proof-of-possession tokens; authorization is declarative access control ([WAC] / [ACP]) evaluated by the storage server, not by each application. Data is RDF (with non-RDF resources alongside), so everything above this layer speaks in graphs.
Two properties matter for the agentic web. First, the pod is the integration point: two applications — or two agents — interoperate by reading and writing the same data under the same access-control regime, rather than by pairwise API integration. Second, identity is uniform: a human’s WebID, an organisation’s WebID, and an agent’s WebID are the same kind of thing, which is what lets authorization and accountability span all three.
2.2 Integrity: proofs that travel with the data
Transport security is not data security. TLS tells you which server you spoke to; it says nothing once the data is copied, cached, syndicated, or handed from one agent to another — which is precisely what agents do all day.
What the agentic web needs is therefore a statement of required integrity — tamper-evidence, authorship, offline verifiability, freshness — and mechanisms that demonstrably meet it. Integrity is the requirement; no single proof format is. The mechanism family is broad: content-addressed hashes pinned by a trusted reference (how this stack’s protocol documents are already secured), detached signatures over canonicalised RDF, selective-disclosure and zero-knowledge proofs, and — the workhorse realization in this stack — the [VC-DM] with [VC-DI] proofs (W3C Recommendations, 2025): the graph is canonicalised ([RDFC]) and signed ([DI-EDDSA]), so any holder can verify integrity and authorship offline, however many hops the data has travelled. Because the signature is over the canonical graph rather than a byte stream, signed data is still data.
In this stack, the integrity layer does double duty:
- Claims become verifiable credentials: “this WebID holds this qualification”, “this app is a member of this federation”, “this agent is authorized by this owner”.
- Selective disclosure and zero-knowledge proofs are not an upgrade path bolted onto VC, but sibling mechanisms behind the same integrity requirement: a verifier states the level — and properties, such as unlinkability — it requires, and VC-DI, BBS-style proofs, or ZK-over-SPARQL (an active research line in the adjacent SPARQ project) satisfy it interchangeably.
These mechanisms are mapped against a security-property ontology developed alongside the SPARQ ZK work — covering properties such as unlinkability, post-quantum resistance, and disclosure leakage — giving the requirement/mechanism split a formal grounding, not just a rhetorical one.
2.3 PROV: where everything came from
When agents produce most of the data, “who wrote this?” stops being a curiosity and becomes the load-bearing question. [PROV-O] (W3C Recommendation) gives the standard answer: every artifact is an entity, generated by an activity, associated with an agent, who may be acting on behalf of another agent. That last relation — prov:actedOnBehalfOf — is the hinge of the whole accountability story: it is how a document written by a software agent is bound, in the data itself, to the human or organisation the agent represents.
Concretely, in this stack every agent-generated resource carries (or links to) a PROV record naming the software agent (by WebID), the activity, the time, and the responsible owner. AI attribution is not a watermark or a policy promise; it is a queryable graph.
2.4 ODRL: policy, agreement, and legal accountability
[ODRL-IM] (W3C Recommendation) expresses policies — permissions, prohibitions, and duties over assets, with constraints (purpose, time, recipient…) — and, crucially, agreements: policies with an identified assigner and assignee. An ODRL agreement is a machine-readable contract.
This supplies the layer the agentic web is most conspicuously missing. Today, when an agent acts, the terms it acted under are implicit (a platform ToS, a prompt, nothing at all) and the responsible party is deniable. In this stack:
- Data in a pod carries ODRL policies stating the terms under which it may be read, used, and shared onward.
- An agent operates under an explicit ODRL agreement between its owner (assigner of the mandate) and the agent (assignee), stating what the agent may do, must do, and must not do.
- The agreement is integrity-attested — in the running stack, signed with a VC-DI proof — and referenced from the provenance chain (PROV), so any downstream party can mechanically answer: under what terms, granted by whom, was this action performed?
The legal position this operationalises is deliberately simple: the agent’s owner is accountable. An agent is not a liability shield; it is a mandated actor, and the mandate is a public, verifiable artifact. Section 4 walks the full chain.
2.5 Data federations: interoperability with governance
Standards make interoperability possible; they do not make it actual. Two task-management apps can both “use RDF” and still not share a task. What closes the gap is sector-level agreement on vocabulary and shape — and somewhere to record who participates and what they conform to.
A data federation, in this stack, is exactly that agreement, published as Linked Data:
- a vocabulary and shapes hub — the sector’s terms and SHACL shapes, minted minimally and reusing established vocabularies (Dublin Core, schema.org, ActivityStreams 2.0 [AS2], the SolidOS workflow ontology, PROV);
- self-description — an application publishes, in its Client Identifier Document, which sectors it operates in, which shapes it reads and writes, and which access modes it requests;
- a registry — memberships as registry-asserted records with lifecycle status, because a self-asserted “I am a member” must never be treated as a membership claim;
- a trust layer — membership assertions backed by Verifiable Credentials, with delegation chains to a trust anchor, so “the registry says so” itself becomes verifiable;
- spec-version negotiation — storage advertises which specification versions it accepts, so schema migration happens on independent clocks (apps, pods, and servers upgrade separately, with dual-read windows), which is what lets a federation evolve without a flag day.
This is the same problem the European dataspace movement (IDSA [IDS-RAM], [Gaia-X], the Data Spaces Support Centre) is solving for industrial data sharing — participant registries, usage policies (notably ODRL-based in IDS usage control), federated catalogues — approached from the personal-data end, on web-native standards. Section 6 returns to the relationship.
Agents that speak data
With the stack in place, agent communication inverts today’s default. Rather than natural language everywhere with structure as an optimisation, the default is structured data with natural language as the negotiation channel.
3.1 Discovery: the pod points to the agent
A WebID profile advertises the agent that represents its owner. The descriptor is dual-published for reach: an [A2A] Agent Card (plain JSON, for the industry toolchain) and an RDF agent description (JSON-LD/Turtle, aligned with the [ANP]’s description layer, for the Linked Data toolchain). An agent is findable and self-describing before any conversation starts.
Working library: @jeswr/solid-agent-card
3.2 The NL→RDF upgrade
When two agents first meet over a task, they may need natural language — that is what makes open-ended agent networks reachable at all. But natural language between production agents is a cost and a risk: every message re-incurs LLM inference, and every message is an injection surface with no fixed semantics.
The [AGORA] protocol showed the resolution: agents negotiate in natural language once, then crystallise the negotiated routine as a hash-pinned protocol document both sides reference thereafter. This stack makes that crystallisation RDF-native: the protocol document’s body is a SHACL shape, content-addressed and pod-hosted, so post-negotiation exchange is SHACL-validated RDF with no further LLM inference on the hot path — and a no-silent-downgrade rule for security-bearing steps, so an agent cannot be talked back down into ambiguous prose where it matters.
Working library: @jeswr/solid-a2a — translator, SHACL protocol documents, and the upgrade-handshake codec.
3.3 A2A and MCP: the pragmatic edges
Two pragmatic protocols complete the picture, both used at the edges rather than as the core:
- [A2A] (Google, 2025; now a Linux Foundation project) is the industry’s agent-to-agent envelope. Here it is the fallback and first-contact channel — maximum reach, used when no shared shape yet exists, and the channel over which the NL→RDF upgrade handshake itself runs.
- [MCP] (Anthropic, 2024) is the tool seam between an LLM host and resources. A pod is exposed to any MCP client as resources and scope-guarded tools, which is how today’s assistants get user-controlled memory and data instead of platform-siloed copies.
Working libraries: @jeswr/solid-mcp, @jeswr/solid-memory
3.4 Querying under authorization
Agents ask questions, and the questions must respect access control. A draft specification — Access-Controlled SPARQL Query over a Solid Pod — defines a read-only SPARQL endpoint that answers over exactly the subset of a pod the authenticated agent is authorized to read: a new read interface over Solid’s existing authorization model, not a new authorization model. (Editor’s Draft written, Solid Community Group track: jeswr/solid-sparql-query; server-side contract tracked for the experimental Rust server.)
The accountability chain, end to end
The claim “complete legal accountability” reduces to a mechanical procedure. Consider a concrete scenario:
Alice’s agent negotiates a data-sharing arrangement with a research institute’s agent: selected records from Alice’s pod, for a stated purpose, for one year.
Alice holds a WebID; her agent holds its own WebID; Alice’s profile links the two. Alice issues her agent an authorization credential — an integrity-attested statement (in the running implementation, a W3C Verifiable Credential with a Data Integrity proof; the verifier requires the integrity level, not the format) stating “WebID A authorizes agent Y to act in scope Z under ODRL policy P”. Policy P is the mandate: what the agent may negotiate, up to what limits, with what duties.
Working artifacts: @jeswr/solid-vc — including exactly this AgentAuthorizationCredential pattern — and @jeswr/solid-odrl.
The agents discover each other (§3.1), establish or reuse a SHACL protocol document (§3.2), and exchange typed offers. The institute’s agent carries its own authorization credential and its federation membership credential (§2.5). Each side verifies — signature, validity window, issuer binding, delegation chain — rather than assuming.
The outcome is an ODRL Agreement: assigner = Alice (through her agent, within mandate P), assignee = the institute; permissions constrained by purpose and period; duties (e.g. deletion at expiry) explicit. The agreement is signed by both sides’ keys and stored in both pods.
The institute’s access is granted by access-control rules that reference the agreement. Every resource the institute’s systems derive from Alice’s data carries PROV: derived from which entities, by which activity, by which software agent, prov:actedOnBehalfOf the institute, under (a link to) the agreement.
A year later, Alice finds her data used outside the stated purpose. Accountability is now a walk, not an investigation: the offending artifact’s PROV names the activity and the acting agent; the agent’s authorization credential names its owner; the agreement — signed, timestamped, tamper-evident — names the terms breached. Every link in that chain is a standard, independently verifiable artifact. The owner answers, because the mandate structure makes “the AI did it” a non-sequitur: the AI did it on the owner’s signed authority.
Enforcement is legal, not cryptographic — the chain proves what was agreed and who did what; courts and regulators do the rest (this is a feature: the alternative, purely technical enforcement, is DRM, which fails and centralises).
Policy semantics must be unambiguous — which is why the formal-semantics work in the ODRL community, and an agent-delegation ODRL profile, sit on the roadmap (§8) rather than being assumed.
Server-side policy enforcement is staged — today’s libraries evaluate ODRL client-side; enforcing it in the storage server’s authorizer, beside WAC, is deliberately a later, separately-reviewed step.
What exists today
A vision paper earns its claims with running code. The rule for this section: every “works today” names its artifact, and maturity is stated plainly.
5.1 The platform underneath
The agentic layers described in this paper run on a from-scratch Solid platform — servers, applications, specifications, and a Rust query engine — built alongside it and documented separately, with live URLs and maturity stated plainly per item, in Solid — what we’ve built; everything below is the agentic layer proper.
5.2 Libraries (experimental, open source, installable today)
All are public on GitHub under github.com/jeswr/…, TypeScript, AI-agent-authored under review discipline, and explicitly experimental — not production-hardened:
| Layer | Package | What it does |
|---|---|---|
| Integrity | solid-vc | the first registered integrity mechanism: VC 2.0 build/sign/verify with Data Integrity (eddsa-rdfc-2022, ecdsa-rdfc-2019 over RDFC-1.0), fail-closed verification gates, pluggable proof-suite seam; the AgentAuthorizationCredential pattern |
| Accountability | solid-odrl | ODRL 2.2 policy expression + deterministic client-side evaluation (permit / deny / duty) |
| Agents | solid-agent-card | WebID/pod → A2A Agent Card + ANP-aligned RDF agent description |
| Agents | solid-a2a | The NL→RDF upgrade: SHACL-bodied, hash-pinned protocol documents + handshake codec |
| Agents | solid-mcp, solid-memory | Pod ↔ MCP clients; portable, user-owned agent memory (mem:MemoryItem) |
| Federation | solid-federation-vocab | The fedapp: / fedreg: vocabularies (w3id.org-homed) |
| Federation | federation-client, federation-registry, federation-trust | App self-description; registry-asserted membership + storage spec-versions; VC-signed membership with delegation chains |
Reference runtime: accountable-agent-runtime — the §4 scenario as executable code: the composed four-phase chain verifier and the auditor walk, exercised with real cryptography against a golden-master decision matrix (Phase-0; I/O is doubled, no live transport yet — see §5.5).
5.3 Specifications and experiments
The specification work these layers rest on — the access-controlled SPARQL query draft, the clean-slate storage experiment, the authentication profiles, and the experimental Rust servers — is catalogued in the Solid assets overview, and its machine-readable normative-statement companions are inventoried at Solid Spec Companions.
5.4 The flagship demonstration: unite
The vision’s fullest demonstration is unite: participatory democracy on this substrate, in which people describe the futures they want and psychology-informed convergence processes surface the futures they share — built directly on the federation model of §2.5, and designed to have no single codebase and no single standards owner. It is its own workstream, with its own design record and its own honesty rules. Read the unite page (tracked as jeswr/full-solid-ecosystem#15).
5.5 What does not exist yet
Server-side ODRL enforcement beside WAC (designed, deliberately staged); ZK selective disclosure through the proof-suite seam (active research, adjacent SPARQ project); live multi-party federation registries with independent operators (the software exists; the institutions do not yet); the agent runtime carried over live transports (a Phase-0 reference runtime now executes the full §4 scenario as a deterministic, golden-master-tested script — real cryptography, doubled I/O — but no long-running agent service listens anywhere yet); and the live wiring of discovery itself — as of this draft the author’s own WebID does not yet carry the agent pointer, and no agent descriptor is publicly hosted on the pod: the mechanism and the exact triples exist (@jeswr/solid-agent-card), the deployment is a small tracked step. And standardisation of everything minted here (the point of the roadmap, ROADMAP.md).
Related work
The path from today: bridging legacy channels
The stack in §2–§4 describes the destination — agents that speak signed, attributed, policy-bound data. But no one begins there. Today the world coordinates over email, Slack, WhatsApp, Telegram, SMS, and service/platform web pages — unstructured natural language between parties who have never heard of a WebID. A vision that requires everyone to onboard before they can be reached is a vision that is never reached. The path from today is a ratchet, not a flag day — meet legacy where it is, then pull it up, one opt-in rung at a time, always with a working channel underneath.
The mechanism has four rungs, each reusing packages that already exist (§5). The full design record is LEGACY-INTEROP.md; in brief:
- Represent legacy sources as agentic entities. An inbound email’s sender becomes a
schema:Person/agent — with a WebID if one can be discovered and verified, never assumed from an unauthenticated address — and the message becomes a provenance-carrying event whose raw bytes are stored owner-private as the audit anchor. Slack, WhatsApp, Telegram and the rest map to the same Person/event shape (and already reach a pod today as Matrix events through the working@jeswr/matrix-chat-to-podbridge). - Interpret with reliability, not laundering. The message body becomes structured RDF via the existing
@jeswr/solid-a2aNL→RDF translator and its injectable-LLM seam — but an LLM reading is an opinion, not a fact. Every interpreted datum is emitted as a qualified PROV derivation carryingprov:wasDerivedFromthe raw message,prov:wasAssociatedWiththe interpreting agent (under a signed ODRL mandate), and an explicit reliability score whose own calibration provenance is recorded (self-reported vs. calibrated vs. verified). Downstream consumers gate on it: threshold for reversible convenience, human-confirm for the ambiguous middle, and always-human-confirm for the irreversible or security-bearing tail, at any confidence — the reliability-model expression of the stack’s no-silent-downgrade rule. A model that is confidently wrong about a payee must not be able to pay them. - Reply with structured, signed metadata. When the system answers over the legacy channel, it embeds a machine-readable version alongside the human prose — e.g. offered meeting times as
schema:Event. The carrier is inline JSON-LD in the email body (Gmail’s own supported markup path, so it survives forwarding), and it is signed as a@jeswr/solid-vcVerifiable Credential over the canonicalised graph (§2.2) — so the proof holds even if a mail client re-flows the HTML, because RDFC-1.0 signs the graph, not the bytes. Amultipart/alternativeRDF part and a header pointer to the authoritative pod-hosted copy give agent-aware clients full fidelity; a human just reads the text. A recipient agent can verify that this identifiable agent made this offer. - Onboard, then negotiate the channel up. The reply links the recipient to a passkey-first onboarding that stands up their own agent (an agent card at their WebID) and pod — which already understands the structured data they were sent, and closes the deferred identity-verification loop. The two agents then negotiate: they discover each other’s capabilities (
@jeswr/solid-agent-card, over the A2A agent-cardcapabilities.extensionsarray), rank a shared preference order (RDF-native exchange ≻ the dpop-sk fast path ≻ A2A-JSON ≻ email), and run the@jeswr/solid-a2aupgrade handshake — which fails closed on a security-bearing step and falls back cleanly to the highest agreed rung, worst case the email channel that already worked. Every rung is capability-discovered, never assumed.
What this earns: a legacy contact is reachable immediately (rung 1–3 need nothing from them), gains verifiable structured replies the moment they want them, and is pulled onto the full accountable stack at their own pace — without a flag day, and without ever losing the channel underneath. The precedent is real: @jeswr/matrix-chat-to-pod, solid-granary, and solid-dav-bridge are working inbound legacy→pod bridges today, and the proposed package has since shipped: @jeswr/agentic-legacy-bridge now implements the reliability model, the signed-reply carrier assembly, the negotiation codec, and an inbound webhook service, composing the existing hardened libraries rather than rebuilding them (status as of 2026-07-05). What remains designed-not-built is the running deployment: live channel pulls and an always-on agent service (the same “no long-running agent service listens anywhere yet” caveat as §5.5) — the concrete design for that deployment, as the maintainer’s own personal agent, is NOW-PERSONAL-AGENT.md.
The adoption path
Standardisation is the linchpin: this vision works only if the stack is boringly standard — implementable by anyone, owned by no one. The full sequenced roadmap, with named bodies and concrete first asks, is ROADMAP.md; in brief:
Publish this vision and its live demonstrations; contribute the Access-Controlled SPARQL draft to the W3C Solid Community Group; open the RDF-native protocol-document conversation in the Linux Foundation A2A project; present the agent-authorization credential pattern to the W3C Credentials Community Group.
An ODRL Profile for Agent Delegation and Accountability in the ODRL Community Group; provenance/integrity requirements into the W3C Linked Web Storage Working Group; a mapping document aligning Solid federations with dataspace building blocks (IDSA/DSSC); engagement with data institutions (ODI) and existing public-sector Solid operators (Athumi).
TR-track specifications for the pieces that prove out; independent federation operators; public-sector pilots where accountable agents act on citizen data under explicit mandates.
Conclusion
The agentic web will be built either on platforms or on data. The platform path is the default — frictionless, fast, and centralising; it will leave agency, interoperability, and accountability as properties of the platforms, on loan to everyone else. The data path requires assembling standards that already exist — Solid for control, integrity proofs for truth-carrying data, PROV for origin, ODRL for terms and accountability, federations for actual interoperability — into a substrate agents can act on directly.
This paper has argued that the second path is not merely preferable but available: the stack is running, in miniature but end to end, today — a live server and application suite, the credential and policy and protocol libraries, the federation machinery, a draft specification. What remains is the deliberately unglamorous work of standardisation and institution-building that turns a demonstration into an ecosystem.
The future in which your agent acts for you — under your terms, on your data, answerable to you, verifiable by everyone — is a future someone has to build on purpose. This is the blueprint we are building to.