Skip to main content

Enterprise

VIA ID doesn't have dedicated enterprise features today — no SSO, no self-hosted Witness, no audit export, no SLA. This page is an honest roadmap, not a feature list: nothing below is available yet, and nothing on viaid.ai claims otherwise.

What "enterprise" would mean for VIA ID​

Given what VIA ID actually does — witness co-signing and tamper-evident logging, not identity or access management — the enterprise-relevant gaps are things like:

  • Self-hosted Witness Service. Today, minting goes through VIA ID's hosted Witness (/api/witness + /api/mint). An org that doesn't want a third party co-signing every badge would need to run its own Witness.
  • Audit / compliance export. A structured export of verification history and badge state for an org's own audit tooling, beyond what a single verify call returns.
  • SSO for any future admin surface. There is no admin dashboard today (badge/download/ contact data lives in Supabase, accessed via the service-role key, not a UI) — SSO would only become relevant once one exists.
  • SLA / support commitments. None exist today; VIA ID is early and pre-widely-used, per its own status note.

What exists today that enterprise evaluators should know about​

  • The Witness Service co-signs with a key held server-side (Vercel + Supabase, service-role key never exposed to the browser) — see the red-team pass that hardened this specific boundary.
  • All privileged writes (badge issuance, download-gate submissions, contact-form submissions) go through least-privilege Supabase RLS policies: the public key can INSERT only, never SELECT/UPDATE/DELETE — see REST API reference.
  • The download-gate and contact-form "is this a real work email" checks are explicitly not security boundaries — see Claims & terminology.

Standing up badge creation across your org (works today)​

None of this needs a feature that doesn't exist yet:

  • Standardize on the CLI/skill install (npx skills add SathiaAI/viaid) across your teams' agent build pipelines — see Quickstart.
  • One badge per agent, minted at build/ship time — not per run, not per deployment. See the FAQ.
  • Treat the badge's keystore (.keys/) as part of the deployment artifact, the same way you'd treat a credential — not as disposable build output. Losing it doesn't invalidate what's already signed, but it does mean you can't extend the log or rotate the key for that agent.

Checking badges across your org (works today)​

  • viaid scan <agent_id> runs the same six-step verification as verify, framed for vetting an inbound or third-party agent. viaid gate <agent_id> [destination] goes further and issues a KnoSky visitor-pass decision, if you also run KnoSky. See the CLI reference.
  • There's no bulk-check or dashboard tooling yet — this is CLI/scriptable only today. If you need to check many inbound agents at once, wire scan into your own CI or procurement scripts; it's a normal process exit code, nothing bespoke to parse.

Maintaining your own standards​

VIA ID reports a verdict; what your org does with it is your policy, not VIA ID's. Concretely, worth deciding explicitly rather than by default:

  • Which verdict states you'll actually accept — most orgs should treat STALE and UNKNOWN the same as "no badge" for anything consequential, not as "probably fine."
  • Whether you require evidence/coverage before trusting a capability claim — a badge with no evidence attached is identity + log only, and treating it otherwise is the most common way to over-trust a badge (see What to look for below).
  • Where badge verification sits in your existing review process — it's a check to add to vendor or dependency review, not a replacement for it.

Open standards VIA ID builds on​

VIA ID's cryptography and encoding are built entirely on open, publicly documented standards — nothing proprietary or invented for this product:

  • Ed25519 signatures (RFC 8032, IETF). Every signature on a badge — owner, agent, Witness — is Ed25519, the IETF-standardized Edwards-curve signature scheme.
  • SHA-256 hashing (FIPS 180-4, NIST). agent_id, the canonical-JSON signing payload, and every hash-chained log entry use SHA-256, NIST's standard secure hash algorithm.
  • Crockford Base32. Short codes use Douglas Crockford's widely-adopted Base32 variant (drops I/L/O/U to avoid the exact character confusion it exists to prevent). There's also an individual IETF Internet-Draft, draft-crockford-davis-base32-for-humans, though it hasn't advanced to a ratified standard.

Beyond the primitives, VIA ID's overall shape — a signed identity plus an independently verifiable, tamper-evident record — sits in the same space as several open efforts, though VIA ID doesn't implement any of them directly today:

  • W3C Decentralized Identifiers (DID). A Candidate Recommendation as of 2026, DIDs let an entity control its own identifier without a central registry. An agent_id is conceptually similar (self-issued, cryptographically bound, not centrally registered) but is not a DID — VIA ID doesn't implement the DID method spec, DID Documents, or DID resolution.
  • W3C Verifiable Credentials Data Model 2.0. Became a full W3C Recommendation in May 2025. VCs and VIA ID badges share a goal — portable, cryptographically verifiable claims about an entity — but different formats; VIA ID doesn't emit VC-DM JSON-LD or use its proof suites.
  • IETF RATS Architecture (RFC 9334). Describes attestation as Attester → Evidence → Verifier → Attestation Result. The Witness co-sign-and-verify flow follows a similar shape (agent as attester, verify as verifier, whoever checks the badge as relying party), though VIA ID doesn't formally implement RATS.
  • C2PA (Coalition for Content Provenance and Authenticity). A ratified, royalty-free open standard for tamper-evident provenance chains on media, built partly to flag AI-generated content. VIA ID applies the same core idea — a cryptographic hash chain that visibly breaks on tampering — to agent action logs instead of media files.
  • Emerging AI-agent-identity work. The space is actively forming: individual IETF drafts like draft-sharif-agent-identity-framework and draft-klrc-aiagent-auth exist but have no formal standing in the IETF standards process yet — there is no ratified AI-agent-identity standard today. VIA ID doesn't target any specific draft; it's built to be compatible with wherever this converges, not locked to one proposal.

None of this is a compliance claim — VIA ID doesn't say it "implements" or "is certified against" any of the above, see Claims & terminology. It's provenance: the primitives are open and auditable, and the overall shape is deliberately in the same family as where the wider identity/attestation/provenance world is heading, not a one-off invention.

What to look for, and what not to allow​

Concrete things to check for — and refuse — when evaluating a badge, yours or an inbound one:

  • Don't accept a verdict other than VALID as sufficient. STALE, UNKNOWN, and REVOKED all mean don't trust it as-is — see the verdict states.
  • Don't accept a capability claim with no evidence. Only a confirmed_profiles entry backed by an actual GraphSmith evaluation counts — a claim in the agent's own description or log doesn't.
  • Don't treat "not evaluated" the same as "passed." The verify page shows confirmed_profiles (evaluated and passed) and downgraded_profiles (evaluated and explicitly failed) as distinct sections on purpose — confusing "never checked" with "checked and fine" is the single most common way to over-trust a badge.
  • Don't accept "certified," "compliant," "tamper-proof," or "guaranteed" from anyone describing a VIA ID badge, including your own team's internal docs. That language is always wrong for this product — see Claims & terminology.
  • Don't treat the download-gate or contact-form email checks as identity verification — they're lead-quality heuristics, explicitly not security boundaries.
  • Do read the scope_note, especially after a compromise rotation — it flags the exact window of log entries a reader should discount, and verify deliberately does not discount them for you.

Talk to us​

If your organization needs something on this list sooner than it's built, use the "schedule a demo" option on viaid.ai — that's real signal for what to prioritize.