New Work Item Proposal
See W3C-CCG New Work Item Process
Include Link to Abstract or Draft
List Owners
- Lead (responsible for advancing the work item): Ramprasad Gaddam, Vouch Protocol —
@rampyg
- Co-owner: Manu Sporny, Digital Bazaar —
@msporny
This work item is an open-source community project. It is not part of the Silicon Valley Innovation program, nor of any specific government or private-sector procurement; it is sponsored by its editors and welcomes contributions from any organization.
Work Item Questions
1. Explain what you are trying to do using no jargon or acronyms.
Software agents powered by artificial intelligence are increasingly trusted to take real actions in the world on behalf of people and organizations: submitting forms, moving money, accessing medical records, sending messages, making purchases. When something goes wrong, there is no reliable way today to prove which specific agent took the action, whose instructions the agent was following, whether the agent stayed within the boundaries it was supposed to operate inside, or whether it was still the same agent at the end of the task as it was at the start.
This work item defines an open standard that gives every artificial-intelligence agent a tamper-evident identity, records in advance what the agent says it is about to do, and continuously checks while the agent runs that what it actually does still matches what it said it would do. The result is a verifiable trail that allows anyone affected by an agent's action - customers, patients, regulators, internal auditors - to trace that action back to a specific agent, a specific instruction, and a specific moment in time.
2. How is it done today, and what are the limits of the current practice?
Today, artificial-intelligence agents are authenticated using mechanisms that were originally designed either for human users (passwords, login cookies, two-factor codes) or for traditional servers (long-lived application keys, bearer tokens). These mechanisms can answer the question "is this caller authorized to make this request" but cannot answer the questions that audit, compliance, and incident-response teams actually need to answer:
- Which specific agent acted? Multiple agents commonly share one application key. The credential identifies the application, not the agent within it.
- Whose instructions was the agent following? Modern agents act through chains of delegation, a human asks one agent to do something, which asks a sub-agent, which asks another. Today, that chain is invisible to the system being acted on.
- Has the agent been substituted or had its instructions modified since the session started? Long-running agents present the same credentials for hours. There is no mechanism to detect that the agent operating now is not the agent that was authorized at the start.
- Will the proofs we accept today still hold up in the future? Most current credentials rely on cryptographic methods that quantum-capable computers, anticipated within the coming decade, will be able to break. Records being collected today for regulatory retention need cryptography that will still bind in 2030 and beyond.
The result is that organizations deploying artificial-intelligence agents in regulated environments - banking, healthcare, insurance, pharmaceutical manufacturing, capital markets - cannot produce the chain-of-custody evidence that recent and emerging regulations increasingly require (US SR 11-7 for banking model risk, HIPAA and FDA Software-as-a-Medical-Device for healthcare, NAIC AI Bulletin for insurance, the EU AI Act for any high-risk system, NIST CNSA 2.0 for post-quantum migration).
3. What is new in your approach and why do you think it will be successful?
What is new:
- Instead of authenticating only at session start, the agent's credential is renewed continuously throughout the session, with each renewal carrying an attestation of recent behaviour. A misbehaving or substituted agent loses trust within seconds, not at the next manual rotation.
- Every action carries an explicit, signed declaration of what the agent intends to do, bound to a specific target and resource. An auditor can replay any past action and verify that what actually happened matches what the agent said it would do.
- Multi-agent delegation chains are recorded cryptographically, with every link bound to a specific resource. An agent cannot quietly widen its scope by passing work to a sub-agent.
- Cryptographic keys are physically isolated from the artificial-intelligence model's working memory, so a prompt-injected or jailbroken agent cannot exfiltrate its signing key.
- A post-quantum migration path is built into the version-1.0 specification, with two independent cryptographic proofs that can sit on the same credential, so deployments can begin migrating now without breaking existing verifiers.
Why we think it will be successful:
- The specification is built entirely on existing W3C primitives (Verifiable Credentials, Data Integrity, Decentralized Identifiers, Multikey). No new cryptographic algorithms are introduced. Implementers already familiar with the W3C credential stack can adopt it with minimal new learning.
- Three independent reference implementations — Python, TypeScript, and Go — already exist in the same repository and produce byte-identical outputs given the same input. Cross-language interoperability is demonstrated, not theoretical.
- The work arrives at a moment when regulated industries are actively procuring artificial-intelligence-agent infrastructure and discovering that the audit story is missing. There is concrete commercial demand.
- The draft has been pre-reviewed by Manu Sporny (editor of multiple W3C Verifiable Credentials specifications), who is now serving as co-author and co-sponsor of this work item.
4. How are you involving participants from multiple skill sets and global locations in this work item?
Skill sets:
- Technical: protocol design, three reference implementations, cryptographic primitives reviewed by an established W3C Verifiable Credentials editor.
- Product / domain: target-vertical scoping informed by direct conversations with regulated-industry deployments in healthcare, banking, and insurance.
- Anthropological / regional context: the lead editor is based in India and brings the perspective of a practitioner from a developing-world artificial-intelligence-deployment context, where authentication infrastructure cannot assume the always-on, always-monitored conditions of US enterprise networks.
- Design / UX: the specification deliberately preserves human-readable credential structure (no opaque encoded payloads) so that incident-response engineers can read credentials directly during an investigation, without specialized tooling.
- Marketing / outreach: a 1-page executive summary accompanies the technical report; a public YouTube walkthrough is in preparation.
Global locations:
- Asia-Pacific: lead editor Ramprasad Gaddam is based in India.
- Americas: co-author Manu Sporny is based in Blacksburg, Virginia, United States.
- Europe: participation actively welcomed.
- Middle East: participation actively welcomed; outreach planned through the public-credentials@w3.org announcement.
5. What actions are you taking to make this work item accessible to a non-technical audience?
- A 1-page executive summary is published alongside the full report, written for boards, compliance teams, and procurement decision-makers rather than implementers.
- The full report includes a regulatory mapping table that lists, by sector (banking, healthcare, insurance, pharmaceuticals, capital markets, European Union horizontal, post-quantum migration), the specific regulations driving the need and the specific protocol mechanism that addresses each.
- Comprehensive FAQs, Help Guides & step-by-step Onboarding published on the website.
- An AI Assistant is available on the website that answers integration questions, walks through SDK examples, and debugs verification errors. It also dogfoods the protocol: every reply is Vouch-signed
- the same protocol is reachable as a Claude Skill, an OpenAI Custom GPT, and a Gemini Gem, so onboarding is largely self-service even for vibe coders.
- A public YouTube demonstration is in preparation that walks through a concrete failure scenario - an artificial-intelligence agent deletes records it should not have - and shows the audit trail naming the responsible agent, the instruction it was following, and the moment of failure.
- The reference implementations include a sub-twenty-line example for each language showing how to issue and verify a credential, lowering the barrier for evaluation by engineering teams not already specialized in W3C credential work.
- The associated defensive prior-art disclosures (60 in total, published under CC0) each open with a plain-language abstract, so a reader can understand the inventive step before deciding whether to read the technical body.
New Work Item Proposal
See W3C-CCG New Work Item Process
Include Link to Abstract or Draft
List Owners
@rampyg@mspornyThis work item is an open-source community project. It is not part of the Silicon Valley Innovation program, nor of any specific government or private-sector procurement; it is sponsored by its editors and welcomes contributions from any organization.
Work Item Questions
1. Explain what you are trying to do using no jargon or acronyms.
Software agents powered by artificial intelligence are increasingly trusted to take real actions in the world on behalf of people and organizations: submitting forms, moving money, accessing medical records, sending messages, making purchases. When something goes wrong, there is no reliable way today to prove which specific agent took the action, whose instructions the agent was following, whether the agent stayed within the boundaries it was supposed to operate inside, or whether it was still the same agent at the end of the task as it was at the start.
This work item defines an open standard that gives every artificial-intelligence agent a tamper-evident identity, records in advance what the agent says it is about to do, and continuously checks while the agent runs that what it actually does still matches what it said it would do. The result is a verifiable trail that allows anyone affected by an agent's action - customers, patients, regulators, internal auditors - to trace that action back to a specific agent, a specific instruction, and a specific moment in time.
2. How is it done today, and what are the limits of the current practice?
Today, artificial-intelligence agents are authenticated using mechanisms that were originally designed either for human users (passwords, login cookies, two-factor codes) or for traditional servers (long-lived application keys, bearer tokens). These mechanisms can answer the question "is this caller authorized to make this request" but cannot answer the questions that audit, compliance, and incident-response teams actually need to answer:
The result is that organizations deploying artificial-intelligence agents in regulated environments - banking, healthcare, insurance, pharmaceutical manufacturing, capital markets - cannot produce the chain-of-custody evidence that recent and emerging regulations increasingly require (US SR 11-7 for banking model risk, HIPAA and FDA Software-as-a-Medical-Device for healthcare, NAIC AI Bulletin for insurance, the EU AI Act for any high-risk system, NIST CNSA 2.0 for post-quantum migration).
3. What is new in your approach and why do you think it will be successful?
What is new:
Why we think it will be successful:
4. How are you involving participants from multiple skill sets and global locations in this work item?
Skill sets:
Global locations:
5. What actions are you taking to make this work item accessible to a non-technical audience?