FAQ

Grouped by who's asking. Every answer here reflects what's actually built and shipped today — if something's on the roadmap instead, it's labeled as such, not described as if it exists.

For developers

Do I need a VIA ID account to create a badge?

No. The CLI (init/log/verify/rotate) needs zero account, zero API key, and makes zero network calls. The browser flow at viaid.ai also needs no account — keys are generated client-side and only public keys/signatures ever reach the server.

Should I mint a badge once per agent, or once per run?

Once per agent, when it's built or about to ship — not once per run, not once per deployment. The agent_id is meant to identify the agent across its whole lifetime. See Quickstart.

What happens if I lose the keystore (.keys/)?

The badge itself still verifies — the signatures and log entries already recorded are unaffected — but you can no longer extend the log or rotate the key. Treat the keystore as part of the agent's deployment artifact, the same way you'd treat a credential, not as disposable build output.

When should I rotate my agent's key, and what happens if I suspect it's compromised?

Two scenarios, one command, different arguments:

• Routine hygiene — viaid rotate <agent_id> routine. No incident, just periodic key hygiene. agent_id never changes (it's the hash of the agent's inception event, fixed forever); only the signing key does, via a pre-committed rotation chain — anyone checking the badge can prove the new key really is a continuation of the same agent, not a fresh identity.
• Suspected compromise — viaid rotate <agent_id> compromise <ISO-timestamp-suspected-since>. verify then adds a note to the verdict's scope_note flagging that window — it does not silently discount those log entries for you; a reader has to decide what to trust from that period themselves.

Either way, an org checking the badge later can see the rotation history and the reason for each rotation (last_rotation_reason, last_rotation_at). See Integrate your agent → Rotating the agent's key for the exact commands, and Badge schema → Rotation events for the underlying field-by-field mechanics.

Do I have to log every single action my agent takes?

No — log actions a human would want an audit trail for (an API call, a file write, a decision with real consequences), not every internal model thought. Wrapping every function call in log is noise, not a record. See Integrate your agent.

Can I just declare my agent "approved for X" myself?

No. Capability claims only carry verification weight when backed by an actual GraphSmith evaluation, attached via viaid eval. A self-declared capability — in the log, in a README, in the agent's own description — has zero verification weight and shouldn't be presented as approved. See What not to do.

Does attaching the badge headers to a response prove anything by itself?

No — it's a pointer, not a proof. viaHeaders() adds two headers; the receiving party decides whether to fetch the verify URL and what to do with the result. Don't build retry, caching, or wrapper logic around it — it's two headers.

What if GraphSmith or KnoSky aren't installed?

init, log, verify, and rotate work standalone with zero dependencies. eval needs GRAPHSMITH_HOME; gate needs KNOSKY_HOME — both throw explicitly if the dependency isn't available rather than silently skipping. See the CLI reference.

Verifying a badge

How do I actually check a badge?

Three ways — paste the short code into viaid.ai, open the verify link/QR directly, or run viaid verify from the CLI. See Verifying a badge for the full walkthrough.

Where do I get the agent's ID from in the first place?

System-to-system: from the X-VIA-ID-Agent/X-VIA-ID-Verify-URL HTTP headers, if the agent's integrator attached them. In a chat window: if the integrator wired in the announceLine() helper, the agent can state one fixed sentence with its ID when asked — but that's opt-in per integrator, not universal, so plenty of agents still won't volunteer it. See Finding the agent's ID.

What does a VALID verdict actually tell me?

That the identity hash, all three signatures (owner, agent, Witness), and the log's hash chain all check out, and the badge hasn't expired or been revoked. It does not mean the agent is safe, well-behaved, or compliant with anything — see Claims & terminology for the exact language VIA ID uses (and avoids) on purpose.

Can a badge be faked?

A forged or altered badge fails at least one of the six verification steps — the identity hash won't match, a signature won't check out, or the log's hash chain will break at the altered entry. See Badge schema for exactly which check catches what.

Do I need to trust VIA ID (the company) to verify a badge?

No. Verification is fully offline once you have the badge file or its rendered page — the CLI's verify command doesn't call any VIA ID server to check signatures or log integrity. Only minting or co-signing a new badge needs the hosted Witness Service.

What can I do with a verified badge, versus not having one at all?

See What you can do with the result for the full before/after — short version: without VIA ID you're trusting the agent's own word; with it, you're checking a cryptographic record independently.

Enterprise

Do we need new tooling to start requiring badges from vendors or inbound agents?

No dedicated dashboard exists yet, but viaid scan <agent_id> (and viaid gate, if you also run KnoSky) already let you vet and gate an inbound agent today from the CLI — see Checking badges across your org.

Can we self-host the Witness Service, so a third party isn't co-signing our badges?

Not today — that's a real, acknowledged gap on the Enterprise roadmap, not a hidden limitation.

Is there an audit export or admin dashboard?

Not today. Badge, download-gate, and contact-form data live in Supabase, accessed via a service-role key — there's no admin UI yet for an org to browse its own verification history.

What open standards does VIA ID build on?

See Open standards VIA ID builds on — the short version: the cryptography (Ed25519, SHA-256) is built on ratified IETF/NIST standards; the overall shape is in the same family as W3C DID/Verifiable Credentials, IETF RATS, and C2PA, without implementing any of them directly.

What should we never treat as a guarantee?

Any language claiming a badge is "certified," "compliant," "tamper-proof," or a safety guarantee — that's always wrong, regardless of who says it. See Claims & terminology and What to look for, and what not to allow.