VAP application example · Verifiable Evidence for AI-Assisted Security Research
Make AI-assisted security research verifiable, from actions to findings.
Status: design proposal
Informative · non-normative
Trace who authorized the work, what the agent observed, and how each finding was reached.
This application proposal combines VAP observation records and delegation records so that whoever receives a finding can see what it rests on and how far it has been confirmed.
The application design is at the design stage. No implementation or test result has been released.
Last checked
01 · The problem
A report that says “found it” does not show the whole investigation.
When an AI reports that it has found a problem, that report alone leaves four things unclear.
01
Authority and scope
Who authorized which targets and operations? Which version of the rules applied at run time?
A record that work was delegated to an AI internally and permission obtained from the target organization are different things.
02
Source of observations
How was each URL discovered? What was actually retrieved?
From which URL, when, and by what route the material behind a judgment came is part of the record.
03
Basis for judgment
What was observed, and what was inferred? If an assessment was corrected, can the original judgment and the reason be traced?
Unless observed facts, referenced information and unconfirmed conditions are kept apart, inference travels as if it were fact.
04
What was actually done
Do the allow/deny decisions match the traffic that actually took place?
Whether decision and execution matched can only be checked by comparing both records.
Five records that cannot stand in for one another
The record that research was authorized, the pre-retrieval decision, the actual traffic, the technical assessment, and the decision on notifying the target company are each a different record.
Authorization recordWho approved which targets, operations and period.
Pre-retrieval decisionHow an operation was allowed or denied before it was performed.
Actual trafficWhat was sent and what was received, including failures and interruptions.
Technical assessmentWhat was concluded from the observations, and what was left unconfirmed.
Notification decisionWhether to inform the target company, and what to tell it.
For example, a record that an operation was decided as “allowed” does not show that the operation was carried out as decided. Conversely, a record of traffic alone does not show whether that traffic stayed within what was authorized.
02 · Combining VAP, OAP and DAP
Linking the provenance of observations with records of delegated actions.
VAP (Verifiable AI Provenance Framework) is a cross-domain framework for making records of AI decisions and actions verifiable after the fact. VAP v1.2 registers OAP, which covers observation of web material published by third parties, and DAP, which covers actions an agent takes under delegated authority. Both are Working Drafts.
Terms used on this page
Provenance
The history of a record or piece of data: when, where, by whom and how it was created and handled.
Delegation
One party (the principal) entrusting work or authority to another party — here, an AI agent — within a defined scope and period.
Verifiability
The property that a third party can check whether records were altered, and how records relate to one another, without having to trust whoever produced them.
External anchoring
Fixing a digest (hash value) of records in an outside service that the record keeper cannot rewrite alone, such as a timestamp authority or a transparency log.
Non-normative
Not a requirement of a specification; reference material to aid understanding.
Composition of one deployment — as described in VAP v1.2
Domain profile
OAP
Observed Artifact Provenance
Covers the provenance of web material that a third party published and that was retrieved over a network, observed at a URL. It targets records of material that may later be disputed, deleted, edited or denied.
v0.1.1 Working Draft · VSO-VAP-OAP-001
+
Cross-cutting capability
DAP
Delegated Access Provenance (common name VAP-AGENT)
Covers the provenance of agent access, tool invocation, action and data transfer under authority delegated by a principal. It is not tied to any domain and is used together with a domain profile.
v0.1.0 Working Draft · VSO-VAP-DAP-001
↓Both inherit the requirements of the Shared Assurance Core below
Common foundation
VAP
Shared Assurance Core
Requirements inherited by every profile and capability, including the integrity, provenance, traceability and accountability layers, external anchoring (INT-006), and the Completeness Invariant (INT-008), which makes post-anchor omission and split-view presentation detectable at anchor granularity.
Figure: where OAP and DAP sit in VAP v1.2. One deployment combines OAP (a domain profile for the provenance of observations) with DAP (a cross-cutting capability for the provenance of delegated actions), and both inherit VAP’s Shared Assurance Core. Each description follows the text of VAP v1.2 (§2.2.6, §4.5.2, §4.6 and §5.4).
Stated in the specification A deployment uses exactly one domain profile and may invoke zero or more cross-cutting capabilities. Each invoked capability must be declared, and where both constrain the same event class, the stricter constraint applies (VAP v1.2 §4.6.3).
Stated in the specification OAP is described as composing with DAP where retrieval is performed by an autonomous agent (VAP v1.2 §4.6.4 and §5.4).
Stated in the specification A Working Draft is a stage at which event names, field names and invariant formulations are expected to change; it is not for production conformance claims (VAP v1.2 §4.5.2).
Scope of what was checked As of this page’s preparation (20 October 2026), the texts of OAP and DAP are not posted in VSO’s public repositories. The explanations on this page are based on the text of VAP v1.2.
Proposed on this page — not official fields defined in OAP or DAP
Additional considerations for security research
For security research, we are considering linking the following information to observation records and delegation records. Which record should carry each item, and in what form, has not been decided.
01Relationship between the asset and its operatorWhich organization the observed domain or service was judged to be operated by, and on what basis.
02How the URL was discoveredWhere the URL came from — a reference in public HTML, DNS, existing observation data whose terms of use were checked, and so on.
03Basis for the product and version observationFrom which part of which response a product name or version number was read.
04Advisories referencedThe source of the vulnerability information used for matching, and its version at the time it was consulted.
05Unconfirmed conditionsConditions that cannot be confirmed from outside, such as the version of the code actually running, individual patches, or whether a feature is in use.
06Correction history of the assessmentWhen an assessment changes: the original assessment, the new one, the reason, and who made the change.
What the specification states, and what this page proposes
The left side of each row is what VAP v1.2 states; the right side is this page’s own application proposal. The right side is not a definition in OAP, DAP or VAP.
Observation records
Stated in the specification
OAP is a domain profile for the provenance of records of web material published by third parties and observed at a URL (§2.2.6, §5.4). It refers to an ObservationScopeManifest and to an attempt-closure invariant, Invariant OAP-1 (§5.4; their definitions are in the OAP text).
Proposed on this page
Link how each URL was discovered, and the basis for each product and version observation, to the observation record.
Delegation records
Stated in the specification
DAP is a cross-cutting capability for the provenance of agent access, tool invocation, action and data transfer under authority delegated by a principal (§4.6.2). VAP’s responsibility schema includes a delegation_chain of delegator, delegatee, scope and validity period (§4.4.3).
Proposed on this page
Treat internal delegation to an agent and permission obtained from the target organization as separate records.
Composition
Stated in the specification
A deployment consists of one domain profile and zero or more declared capabilities; where constraints overlap, the stricter applies (§4.6.3). OAP composes with DAP where retrieval is performed by an autonomous agent (§4.6.4, §5.4).
Proposed on this page
Link OAP and DAP records along six research stages: setting the scope, delegation, pre-retrieval decision, observation and retrieval, technical assessment, and notification, correction and handover.
Version of the rules
Stated in the specification
VAP’s policy identification (policy_id, §7.1) identifies the verification policy under which events were produced. It does not represent the rules for what research may or may not do.
Proposed on this page
Reference the version of the research rules (targets, permitted and prohibited operations, period of application) from the delegation record and the pre-retrieval decision record.
Detecting alteration and omission
Stated in the specification
External anchoring is required at all conformance levels (INT-006). For any anchored batch, a third party must be able to detect omission or split-view presentation after anchoring (Completeness Invariant, INT-008). Events that were never recorded are out of reach (Appendix A).
Proposed on this page
When verification is implemented, state the trusted record source, how records are fixed externally, and the scope being verified.
Assessment, notification and correction
Stated in the specification
There is an abstract provenance model (actor, input, context, action, outcome; §4.2.2) and an override_history (§4.4.3). The VAP v1.2 text defines no records specific to security assessments or notification decisions (the OAP and DAP texts have not been checked).
Proposed on this page
Treat observed facts, referenced information, likely applicability, unconfirmed conditions, the notification decision and the reason for a correction as separate records.
Scope of assurance
Stated in the specification
Conformance to VAP or a profile does not constitute compliance with any law and does not warrant that recorded decisions are correct, fair or safe; it concerns only the integrity, completeness at anchor granularity, and attributability of the records (§1.6). VAP does not prevent, block or intercept AI behaviour (Declaration).
Proposed on this page
Design the evidence mechanism and execution control as separate mechanisms.
03 · A research flow that links the evidence
Trace a single finding back to the original observation and judgment.
The stages below are an application proposal for linking records (proposed on this page). Under “related specification elements”, each stage lists only what VAP v1.2 actually states.
1
Setting the research scope
What to link
Targets, permitted and prohibited operations, version of the rules, period of application
Related specification elements
Stated in the specificationOAP’s ObservationScopeManifest (referred to in §5.4) Proposed on this pageMapping it to the research scope
2
Delegation to the agent
What to link
Delegator, acting party, scope of delegation, changes and revocation
Related specification elements
Stated in the specificationDAP (§4.6.2); the delegation_chain in the responsibility schema (§4.4.3)
3
Pre-retrieval decision
What to link
Planned operation, allow/deny decision, and its basis
Related specification elements
Stated in the specificationWhat DAP covers (access, tool invocation, action; §4.6.2) Proposed on this pageRecording the decision before retrieval and linking it to the retrieval record
4
Observation and retrieval
What to link
Actual target, time of retrieval, response, failures and interruptions
Related specification elements
Stated in the specificationOAP (§5.4); the attempt-closure invariant, Invariant OAP-1 (referred to in §5.4)
Stated in the specificationThe abstract provenance model (§4.2.2); nothing specific to assessments is defined Proposed on this pageRecording observed facts and inferences as separate items
6
Notification, correction and handover
What to link
What was notified and why, reasons for corrections, handover to the people who will respond
Related specification elements
Stated in the specificationoverride_history (§4.4.3); nothing specific to notification or handover is defined Proposed on this pageKeeping the before and after of a correction, and its reason, linked to the original assessment
Internal delegation and the target organization’s permission are different things
Internal delegation
Within the organization doing the research: who entrusted which agent with what scope of work. Changes to and revocation of the delegation are recorded too. The intent is to map this to what DAP covers — actions under delegated authority (proposed on this page).
≠
The target organization’s permission
Which scope and period of testing the target company has authorized. This is a separate record, linked to the version of the authorization letter or contract.
Internal delegation creates no authority to access third-party systems. Operations that presuppose the target organization’s permission (for example, additional testing under a permission or contract) are linked to the record of that permission; an internal delegation record is never used in its place.
Keep execution control and the evidence mechanism separate
Execution control
Execution control enforces the scope of operations in the system.
Evidence mechanism
The evidence mechanism produces records of those decisions and of their execution that can be checked afterwards.
Evidence records alone cannot prevent prohibited operations. VAP is a framework for after-the-fact verification and does not prevent, block or intercept AI behaviour (VAP v1.2, Declaration). Preventing prohibited operations requires separate execution control.
04 · An example with synthetic data
Two findings may both say “candidate” — check what stands behind each.
An example built from a fictitious target and synthetic data. It contains no real company, URL or vulnerability information. The display is static and for explanation only; no signature or hash value has been verified.
Evidence card (example)
Synthetic data
Cryptographic verification: not performed
Example of a conditional problem candidate for a fictitious target
Data type
Synthetic data
Target
A fictitious public website, https://shop.example/ (.example is a domain name reserved for examples)
Origin of the URL
A reference in public HTML (a script referenced by the home page’s HTML)
Rules applied
Demo research policy demo-policy, version 3 (fictitious)
What was observed
A plugin name and an apparent version string, demo-gallery 2.3.1
Matching result
Matches the affected range “below 2.4.0” of demo advisory DEMO-ADV-0001 (fictitious)
Unconfirmed
The version of the code actually running, whether individual patches were applied, whether the feature is in use
Assessment
Conditional problem candidate
Notification status
Not sent
Cryptographic verification
Not performed in this example
Example details: see how the records link (this is not a verification step)
Research scope DEMO-SCOPE-01 — target: shop.example / permitted: retrieving public pages / prohibited: bypassing authentication, load-inducing operations / rules: demo-policy version 3
Notification — not sent (no notification decision has been recorded)
All record IDs are fictitious values for explanation. They are not official OAP or DAP event names or field names. Opening this list does not verify any signature, check any external anchor, or detect tampering.
What to state if verification is implemented
If detection of alteration, omission or substitution is implemented in future, at least the following three points will be stated (proposed on this page).
Trusted record source
Whose records, signed with which keys, serve as the starting point for verification.
How records are fixed externally
In which outside service (a timestamp authority, a transparency log, and so on) record digests are fixed, and how often. In VAP v1.2, external anchoring is required at all conformance levels (INT-006).
Scope of verification
Which batches, periods and kinds of record were verified. Post-anchor omission or split-view presentation can be within reach of detection; actions that were never recorded cannot be detected (VAP v1.2 §4.1.7, Appendix A).
VAP v1.2 recommends an Evidence Pack: a bundle a third party can verify offline, containing events, audit paths, anchor records, external anchor proofs, public keys, policy documents and similar material (§9.3). The example on this page is not an Evidence Pack.
05 · What can be verified, and the limits
Being able to verify the evidence is not the same as the judgment being right.
These are the premises for evaluating this evidence design. Read them as part of the design.
What this design aims to do, and what that alone does not guarantee
What the design aims to do
What that alone does not guarantee
Detect alteration of stored records
That observations represent reality completely and accurately
Trace judgments and their basis
That a vulnerability exists, or that it can be exploited
Cross-check delegation records against operation records
That the target company gave permission, or that the research was lawful
Verify evidence within a declared scope
That no unmeasured or unrecorded action took place
A hash added afterwards does not, by itself, show prior approval
Adding a hash afterwards does not, by itself, show that an approval record existed before the research. This design considers linking approval records and execution records to external anchors, so that one can check by when each record existed. The approver’s authority and the validity of the approval need to be confirmed separately.
This proposal is an evidence design for verifying research records after the fact. It does not grant access to any target, and it does not guarantee that a vulnerability exists, legal compliance, or independent certification.
Position in the specification: conformance to VAP or a profile does not constitute legal compliance and does not warrant that recorded decisions are correct (VAP v1.2 §1.6). Events that were never measured are, by construction, outside the reach of verification (VAP v1.2, Appendix A).
06 · Implementation plan
Implementation plan: EVIDECT
Service: in development
Evidence integration: design stage
EVIDECT is a security research service being developed by VeritasChain Co., Ltd. We are considering a design that links observation, delegation, assessment and notification records to the process of examining public information and similar sources for possible problems.
Support for VAP, OAP and DAP as presented on this page is an application design proposal. Implementation status, test results and any conformity assessment will each be shown together with material that can be checked.
Our own implementation plan. It is not an independent adoption by an outside organization.
Service
In development
Evidence integration using VAP, OAP and DAP
Design stage
Published conformance test results
None
Service information
There is no publicly available service website (as of ).
07 · Frequently asked questions
Frequently asked questions
Does this design guarantee that a vulnerability found by AI is real?
No. Verifying the evidence can show whether records were altered afterwards and how a finding links back to the original observations and judgments. On its own, this design does not guarantee that a vulnerability exists or that it can be exploited.
What are OAP and DAP?
Both are Working Drafts registered in VAP v1.2.0 Draft 3. OAP (Observed Artifact Provenance) is a domain profile for the provenance of records of web material published by third parties and observed at a URL. DAP (Delegated Access Provenance, common name VAP-AGENT) is a cross-cutting capability for the provenance of agent access, tool invocation, action and data transfer under delegated authority.
If work is delegated to an AI internally, may it examine a target company’s systems?
Internal delegation creates no authority to access third-party systems. This design treats internal delegation and the target organization’s permission as separate records. It does not grant access to any target, and it does not guarantee that research is lawful.
Does recording evidence prevent prohibited operations?
No. VAP is a framework for after-the-fact verification and does not prevent, block or intercept AI behaviour. Preventing prohibited operations requires separate execution control that enforces the scope of operations in the system.
Has EVIDECT been certified under VAP or independently verified?
No. EVIDECT is a service being developed by VeritasChain Co., Ltd., and its evidence integration using VAP, OAP and DAP is at the design stage. No conformance test results or independent verification results have been published.
How can I send comments on this application design?
Write to the standards contact listed in the VAP specification, standards@veritaschain.org. Comments do not amount to normative changes to VAP or any profile.
08 · Specifications, publication status and review
Check the specifications, and review the design.
The material this page refers to, and the publication status of related outputs. Status is always given in words.
OAP — Observed Artifact Provenance v0.1.1Working DraftVSO-VAP-OAP-001 · listed in the profile registry of VAP v1.2 §4.5.2. The text is not posted in VSO’s public repositories (checked 20 October 2026).
DAP — Delegated Access Provenance (VAP-AGENT) v0.1.0Working DraftVSO-VAP-DAP-001 · listed in the capability registry of VAP v1.2 §4.6.2. The text is not posted in VSO’s public repositories (checked 20 October 2026).
Synthetic sampleStatic example onlyThe example on this page (HTML). No machine-readable sample file has been produced.
Verification resultsNone (not performed)No cryptographic verification has been performed on the example on this page.
Evidence integration in EVIDECTDesign stageEvidence integration using VAP, OAP and DAP is at the design stage. No code, evidence set or conformance test result has been published.
Review the application design
We welcome comments on this application design, for example on:
Whether the distinction between the five records (authorization, pre-retrieval decision, actual traffic, technical assessment, notification decision) is sufficient.
Which OAP or DAP records the additional considerations should be linked to.
Whether the premises of verification (trusted record source, how records are fixed externally, scope of verification) are stated clearly enough.
Comments do not amount to normative changes to VAP or any profile. Specification changes follow VSO’s change management process (VAP v1.2 §10.3).
Contact
The standards contact listed in the VAP specification.
Added icons and a FAQ; added search and sharing metadata (structured data and share images).
Added an opening comparison; split the EVIDECT status; narrowed the explanation of hashes and prior approval; moved the organization and implementation-status disclosure to its own section.
First edition published (design proposal; informative, non-normative)
Implementation status (disclosure as stated in VAP v1.2)
There are zero external implementations of VAP or any VAP profile, and zero Evidence Packs accepted in any proceeding. VeritasChain Co., Ltd., which provides VSO’s operating base, holds ten paid service contracts with European organizations in regulatory technology, financial trading, and audit and assurance (client names withheld pending individual consent). These contracts are not external implementations of VAP or VCP, and they are not independent validation of those specifications.