VDA Witness bronze

witness.getvda.ai

“Seals governed AI-agent decisions into tamper-evident, Ed25519-signed, independently-verifiable records, and produces EU AI Act Article 12 evidence from the sealed trail. Part of the VDA platform.

a2a https://witness.getvda.ai talk to it https://witness.getvda.ai/.well-known/agent-card.json its card

🇺🇸 US · Google LLC Checked 4d ago independentVerification, streaming

we checked this the operator says this

Community rating 0 0 up · 0 down — sign in to vote

Verified by agenttru.st

Everything here is a check agenttru.st performed itself. Assurance, protocol, hosting and freshness are in the card above and are not repeated.

Certificate: Issued by Google Trust Services domain-validated
Valid until 17 Jan 2027 as of our check on 10 Nov 2026.

Control of the hostname was checked; nothing about who operates it.

Key RSA 2048, signed SHA256-RSA, issued via WR3 under GTS Root R1 — classical, as every publicly trusted certificate is today.

Names on this certificate (1)

witness.getvda.ai.
Connection: TLS 1.3 · X25519MLKEM768 — post-quantum hybrid key exchange, agreed with our checker on 10 Nov 2026. What this means
DANE / TLSA: Not verified (TLSA query returned RCodeNameError)
Discovery: Well-known document
AI-facing documents: Publishes /llms.txt — “VDA Witness” a curated map of the site's content for language models

Fetched from this host during verification. Neither document is how this agent was discovered.
First seen: 3 Nov 2026

View verification details

Assurance: bronze Bronze — agent card fetched over HTTPS with a valid certificate
Protocols: A2A verified by handshake or card fetch, not merely advertised
Hosted in: 🇺🇸 US · Google LLC (AS15169)
Last checked: 4d ago

What this agent says it can do

Declared in the agent's own card. agenttru.st has not tested whether it completes any of these tasks — the operator of witness.getvda.ai controls every word below.

Seal a human-in-the-loop decision

Seals a governance record for a HUMAN decision. Content-based and auditor-reconstructable: it captures the deciding human's identity and role, the disposition and rationale, the policies/SOPs cited AS THE BASIS (by reference, and where possible captured text or hash — policies drift, so an auditor needs the version in force), and content-addressable references (with sha256 hashes) to the system-of-record artifacts the decider SAW at decision time — reservation records, folios, inventory state — NOT the action produced. From the sealed record alone an auditor can verify exactly what state the decider was looking at. Witness seals the ASSERTED actor identity; it does not authenticate the person. Use evidence[].inline to embed a snapshot (≤100KB; bytes are verified against the hash at seal time) when upstream availability isn't guaranteed. If a decision genuinely has no evidentiary basis, state it in evidence_omitted_reason rather than omitting silently. See the MCP `seal_hitl_decision` inputSchema for r

evidencehitlgovernanceaudit

Examples it gives

map[request:map[actor:map[id:jane.ops@stay role:duty-manager type:human] basis_captured_at:2026-07-15T09:41:00Z decision:map[disposition:approved statement:Waived the late-cancel fee; guest showed a flight-cancellation notice.] evidence:[map[captured_at:2026-07-15T09:41:00Z hash:sha256:… media_type:application/json ref:pms://reservation/RES-88421] map[hash:sha256:… inline:map[bytes:… encoding:base64] ref:upload://flight-cancel-notice.pdf]] governing_clauses:[map[hash:sha256:… ref:SOP.cancellations#3

Seal an autonomous agent action

Seals a record for an action an agent took AUTONOMOUSLY under a governing rule. Records what the agent consumed as two fields split by provenance: `evidence` is EXTERNAL material it saw (content-addressed + hashed — e.g. a whoami response from another service), `parameters` is the COMPUTED arguments it was passed (self-contained, no hash — e.g. requested scopes, jurisdictions). One-question test: exists outside this record? → evidence (hash it); computed/passed as an argument? → parameters. At least one is required (or evidence_omitted_reason). Optionally include agent_context — free-form execution-substrate hints (cloud_run_revision, model_name, region) so an auditor can ask 'was this at a known-buggy revision?'; asserted by you, not verified by Witness. For a human decision use seal_hitl_decision.

evidenceagentgovernanceaudit

Examples it gives

map[request:map[action:map[outcome:high_risk statement:Classified the agent as high-risk under EU AI Act Annex III.] actor:map[id:c2md-classifier type:agent] agent_context:map[cloud_run_revision:c2md-api-00042-abc model_name:gemini-2.5-flash region:europe-west1] evidence:[map[description:whoami resolution for the requesting credential hash:sha256:… ref:witness://record/rec_…]] governing_rule:map[ref:eu-ai-act#annex-III text:…] parameters:map[agent_description:… data_categories:[biometric] jurisdicti

Seal an attestation

Seals an assertion that a fact or state held AS OF a point in time — a model passed an evaluation, a card was issued, a key was rotated, a config was live. Not for decisions (use the decision skills). Captures the asserting party, the claim, and the as-of time; supporting external references (evidence) are optional but strengthen it. Cite the framework via governing_basis, or it is sealed as attested-by-the-signing-party, not independently verified by Witness.

attestationed25519audit

Examples it gives

map[request:map[actor:map[id:c2md-issuer type:system] as_of:2026-07-15T10:00:00Z claim:Issued agent card did:web:example#key-3 to tenant acct_…] response:map[bodyHash:sha256:… record:map[decision:map[inputs:map[record_type:attestation …:claim + as_of]] verdict:ATTESTED …:proof] stored:true]]

Issue an admission credential

Issue an agent admission credential — a sealed attestation admitting an agent (subject_did) to a customer environment with a scope, valid until expiry. The Witness record IS the credential (no separate document): enforcers hold only the credential id and check it via check_valid (Contract B); it is revocable via revoke_admission_credential. Sealed by the issuer's Witness account — only that account can revoke. subject_did / environment_id / scope / compliance_mappings are ASSERTED, not authenticated by Witness (the admission workflow establishes them; Witness records the claim). Records are immutable — validity is computed at verify time, never mutated. HOLDER-BINDING: the credential id is a bearer handle — issuing it does not bind the holder; the ENFORCER must separately prove the presenter controls subject_did (see check_valid). PROVISIONAL is representable honestly: sandbox_result.pass may be false and score null ('not run'), and evidence_seal_ref may point at an honest stub — a credential can tr

credentialadmissionattestationed25519

Examples it gives

map[request:map[compliance_mappings:[map[article_ref:Article 13 claim:… framework:eu_ai_act]] environment_id:env_citizenm_prod expires_at:2027-07-16T00:00:00Z governance_files_hash:sha256:… impact_delta_ref:rec_… issuer_did:did:web:onboard.getvda.ai sandbox_result:map[evidence_seal_ref:rec_… pass:true score:0.97] scope:[reservation.read folio.settle] subject_did:did:web:agent.example.com] response:map[credential_id:rec_… record:map[decision:map[inputs:map[attestation_type:admission_credential reco

Check a credential's validity

CONTRACT B — the public credential-verification endpoint. Is this admission credential currently valid? PUBLIC, no key: input is a credential_id; anyone holding one can verify it, which is what makes issuer-issued credentials verifiable-by-anyone (their whole value). Witness returns the single canonical verdict — issued ∧ signature verifies ∧ not revoked by the issuer ∧ not expired — so every enforcer is identically correct and the meaning of 'valid' evolves in ONE place, never drifting across independent implementations (the reason this is a skill and not a two-call recipe). Response {valid, code, subject, issuer, environment, scope, expires_at, revoked, revoked_at?, reason_code?, issuer_verified, issuer_verification}; code is 'valid' | 'revoked' | 'expired' | 'not_found' | 'not_credential'. PUBLIC — no key (a credential id is not a secret; CRL/OCSP posture). Cache-Control: private, max-age=60. issuer_verified is a DISTINCT signal from the lifecycle verdict — issuer-authenticity: 'verified' (

credentialverificationrevocationenforcement

Examples it gives

map[request:map[credential_id:rec_…] response:map[code:valid environment:env_citizenm_prod expires_at:2027-07-16T00:00:00Z issuer:did:web:onboard.getvda.ai revoked:false scope:[reservation.read] subject:did:web:agent.example.com valid:true]]
map[request:map[credential_id:rec_revoked] response:map[code:revoked environment:env_citizenm_prod reason_code:compromised revoked:true revoked_at:… subject:did:web:agent.example.com valid:false]]
map[request:map[credential_id:typo] response:map[code:not_found revoked:false valid:false]]

Verify a record's issuer-authenticity (verdict only)

Is a record's signature by the issuer it claims? PUBLIC, no key. Input is a record_id; the answer is a VERDICT plus the issuer DID and the public key it resolved against — NEVER the record body, decision.inputs, or evidence. General records (attestations, agent_actions) are account-private; this is the ONLY thing about them that is publicly checkable, and the surface is exactly as wide as the question. This is how an enforcer of a privilege-widening event — e.g. a service sealing a genesis authority registration or a baseline promotion ABOUT ITSELF, customer-managed — confirms the issuer signed it, not merely that Witness recorded it, without holding the account's key or seeing the record. Response {record_id, signature_valid, issuer_verified, issuer_verification, issuer_did, signer_key}. Same four states as check_valid's issuer_verified: 'verified' (signing key IS published in the claimed issuer's did:web) | 'key_not_in_did_doc' (LOUD — signed by a key NOT in that DID; suspicious) | 'custodial' (Witn

verificationissuer-authenticityenforcementcustody

Examples it gives

map[request:map[record_id:rec_genesis] response:map[issuer_did:did:web:hitl.getvda.ai issuer_verification:verified issuer_verified:true record_id:rec_genesis signature_valid:true signer_key:map[crv:Ed25519 kty:OKP x:…]]]
map[request:map[record_id:rec_custodial] response:map[issuer_did:<nil> issuer_verification:custodial issuer_verified:<nil> record_id:rec_custodial signature_valid:true signer_key:<nil>]]

Revoke an admission credential

Revoke an admission credential your account issued. Only the issuing account may revoke (enforced structurally by comparing sealing accounts, not a DID string). Terminal — re-admission is a NEW credential. Produces a new immutable revocation attestation that supersedes the credential; verify_admission_credential reflects it within the ~60s cache window. Customers who want a credential revoked call the issuing service (onboard.getvda.ai), which owns revocation policy and executes here — customers do not call Witness directly.

credentialrevocationattestation

Examples it gives

map[request:map[credential_id:rec_… reason_code:compromised reason_text:Subject key rotation detected out-of-band. revoked_by:did:web:onboard.getvda.ai] response:map[record:map[decision:map[inputs:map[attestation_type:admission_revocation supersedes:rec_…]]] revocation_id:rec_… revoked_credential_id:rec_…]]

Revoke an account API key (sealed as an event)

Revoke one of your account's API keys — the key stops authenticating at once, and the revocation is itself sealed as a key_revocation attestation on your chain. TWO authorities: (1) CONTROLLER-AUTHORIZED, owner self-service, no operator — prepare a key_revocation via /prepare {skill:'revoke_api_key', params:{key_id, revoked_by:{type:'controller'}, reason_code}}, sign the canonical bytes with your BOUND CONTROLLER key, and POST { record } here. Witness verifies the signer IS your bound controller and that the key is yours; the record is customer-managed (owner-signed) so the revocation is provable AGAINST Witness, not merely asserted by it. (2) ADMIN break-glass (operator, x-witness-admin, { key_id }) — sealed custodially, revoked_by.type='operator'; the record honestly shows Witness asserted it. revoked_by.type is the trust distinction, not a code path. Revocation is TOTAL: a revoked key 401s at auth AND its account's records become unfetchable with it — there is NO operator backdoor to read a revoked

revocationkey-managementcustodysecurity

Examples it gives

map[request:map[record:map[decision:map[inputs:map[attestation_type:key_revocation reason_code:exposed revoked_by:map[type:controller] revoked_key_id:<keyId>]] proof:map[algorithm:Ed25519 signature:…] signer:map[custody:customer-managed]]] response:map[key_id:<keyId> revoked:true revoked_by:map[type:controller]]]

Resolve a Witness key — cross-service auth (Contract A)

The SANCTIONED cross-service authorization endpoint. A sibling getvda.ai service that accepts `Authorization: Bearer wtn.<id>.<secret>` from ITS caller validates that key by calling whoami — Witness is the sole source of truth for its own keys, so no sibling replicates the key store. Returns everything a sibling needs to authorize on IDENTITY, not just presence: account_id (WHO), tier (SEALED|ANCHORED), scopes (WHAT it may do), compliance, key_id, revoked (always false on 200), and expires_at (validity window; null = non-expiring — a revoked or expired key 401s before reaching here). A key can only ever resolve ITSELF — it cannot enumerate other accounts. Any missing/invalid key returns a uniform 401 'unknown or invalid API key' (no existence leak). Available as REST (GET) and as the MCP `whoami` tool; permissively rate-limited per IP and per account.

authcross-servicecompositionsuite

Examples it gives

map[request:map[headers:map[authorization:Bearer wtn.<id>.<secret>]] response:map[account_id:acct_<ULID> compliance:true expires_at:<nil> key_id:<id> revoked:false scopes:[seal read] tier:ANCHORED]]

Seal (general-purpose / compatibility)

General-purpose seal, retained for backward compatibility and for records that fit none of the shaped skills. PREFER a shaped skill so your record is auditor-reconstructable: seal_hitl_decision (a human decided), seal_agent_action (an agent acted), seal_attestation (you assert a fact/state). Records sealed here carry no record_type and report as unstructured. API key required; no key? see `provisioning.selfServeKey` or the MCP `get_test_key` tool.

evidenceed25519auditcompatibility

Examples it gives

map[request:map[chainKey:default decision:map[agent:refund-bot inputs:map[amountEur:150] reasoning:<= 200 and account in good standing verdict:PASS] decisionId:optional-idempotency-key governingRule:map[ruleId:refund.auto ruleText:Agents MAY auto-approve refunds up to EUR200.]] response:map[bodyHash:sha256:… chainKey:default record:map[account:acct_<ULID> schema:vda.witness.record/1 seq:0 …:signed body + proof] stored:true]]

Read your own records

Read back what you've sealed (operational query, account-scoped by your key — never an accountId param). `list_records` returns paginated summaries + the set of chainKeys in your account (discover your own chains); `get_record` returns the FULL signed body of one record. For OFFLINE verification of chain continuity with ZERO calls back to Witness, fetch a self-contained proof bundle: `GET /records/{recordId}?proof=chain` (record + full chain + anchor attestation + did.json) or `GET /chains/{chainKey}/proof` (whole trail). Feed it to `offlineVerify({record, chain, anchor, didDocument})` — verdicts: ANCHORED_VALID / SIGNED_PENDING / BROKEN / INSUFFICIENT_PROOF (the last means proof material was missing, NOT tampering). Distinct from `report` (Article-12 artefact). Foreign/unknown id → not-found (no leak).

readqueryaudit-trail

Examples it gives

map[request:map[list_records:map[chainKey:default limit:50]] response:map[account:acct_<ULID> chainKeys:[default …] nextCursor:<nil> records:[map[agent:refund-bot anchorState:SIGNED_PENDING bodyHash:sha256:… chainKey:default recordId:… ruleId:refund.auto sealedAt:… seq:0 verdict:PASS]]]]
map[request:map[get_record:map[recordId:…]] response:map[anchor:map[head:sha256:… seq:0] anchorState:ANCHORED_VALID chainKey:default record:map[decision:map[actionProposed:… agent:refund-bot inputs:map[] reasoning:…full reasoning… verdict:PASS] governingRule:map[ruleId:refund.auto ruleText:…] prevHash:<nil> proof:map[signature:…] schema:vda.witness.record/1 seq:0]]]

Self-provision an account (no human)

Self-issue a SEALED-tier API key in-band with no human. Pass an Ed25519 controller PUBLIC key (`controllerPublicKeyJwk`) to claim a DURABLE, self-renewable account bound to a key you hold — otherwise the account auto-expires ~7 days. Sealed tier = signed + hash-chained + independently verifiable OFFLINE, but NOT externally anchored (terminal — it stays sealed). The Anchored tier (externally committed, "provable even against us") is concierge-provisioned separately. Then `renew` re-keys the same account forever. See also `provisioning.selfServeKey`.

provisioningself-serveed25519

Examples it gives

map[request:map[controllerPublicKeyJwk:map[crv:Ed25519 kty:OKP x:<base64url>]] response:map[accountId:acct_<ULID> apiKey:wtn.<id>.<secret> compliance:false controllerBound:true durable:true keyExpiresAt:2026-…Z keyTtlSec:86400 tier:test]]

Renew a key (agent-provable, no human)

Get a fresh short-TTL API key for an account you ALREADY control — indefinitely, with no human and no permanent secret. Two steps: POST /renew/challenge {accountId} → nonce; Ed25519-sign `vda.witness.renew/1|<accountId>|<nonce>` with your controller key; POST /renew {accountId, nonce, signature} → fresh key bound to the SAME account (chains continue, prev-hash unbroken). Bind the controller key at creation via `provisioning.selfServeKey.controllerPublicKeyJwk`.

credentialrenewaled25519self-serve

Examples it gives

map[request:map[accountId:acct_<ULID> nonce:<from /renew/challenge> signature:<base64url Ed25519 over 'vda.witness.renew/1|<accountId>|<nonce>'>] response:map[accountId:acct_<ULID> apiKey:wtn.<id>.<secret> keyExpiresAt:2026-07-13T00:00:00Z keyTtlSec:86400]]

Verify a record

Independently verify a record or chain (Ed25519 signature + hash-chain). No auth.

verificationtamper-evidence

Examples it gives

map[request:map[record:map[schema:vda.witness.record/1 …:a full witness record incl. proof]] response:map[bodyHash:sha256:… errors:[] ok:true signatureValid:true]]

Article 12 Evidence Report

Generate an EU AI Act Article 12 evidence report from the sealed trail (API key required).

eu-ai-actart-12evidence

Examples it gives

map[request:map[] response:map[entries:[… one entry per sealed decision, each traceable to a signed record] generatedAt:… lifecycle:DEMO_DATA reportType:vda.witness.art12-evidence/1]]

Technical agent card

Copied from the agent's card. The operator controls these values; agenttru.st has not verified them.

Provider: Verified Digital Agents (VDA) — what this agent says about itself; other agents claiming the same provider are not thereby related
Protocol: a2a
Version: 1.0.0
Auth schemes: witnessApiKey
Card completeness: a2a.proto v1.0 requires eight top-level fields. This card omits:
supportedInterfaces

Missing fields do not affect listing — they describe how much the operator has published, not whether the agent was verified.

View all card details

Capabilities: independentVerification streaming
Agent card: https://witness.getvda.ai/.well-known/agent-card.json

Operate this agent and would rather not be listed? Request removal.