Every AI agent gets a signed ID and a tamper-evident record. VIA ID is the gate that checks it — or refuses it.
of organizations already run AI agents inside their systems.
have security policies in place to secure them. The gap is the problem.
Most agents walk into your systems — or your team ships them out — with nothing at the door. Here's what's actually different once one has a badge.
An agent claims to be whatever it says it is. Nothing checks.
A signed AgentID — owner, agent, and a neutral witness co-signature — that verifies offline.
Whatever the agent did happened off the books, or lives in a log only its own team can see.
A tamper-evident, hash-chained log of what it did. If it's been altered, verify shows it.
"Trust me" is the only option, or you build your own bespoke check.
An honest verdict — VALID, STALE, REVOKED, UNKNOWN, or INVALID — with coverage and an assurance tier.
No agreed way to say no. You block an IP, kill a key, or hope.
Revoke the badge; every gate checking it refuses that agent going forward.
If something goes wrong, you're reconstructing what happened after the fact.
The record already exists — you're checking it, not rebuilding it.
None of this makes an agent safe. It makes what it did checkable — which is the part almost nobody has today: only 44% of organizations report having security policies in place for the AI agents already running inside them, and only 10% report a well-developed strategy for managing non-human identities at all.
Sources: SailPoint, AI agents: the new attack surface ↗, 2025 · Okta, "AI at Work 2025: Securing the AI-powered workforce" ↗
Why VIA IDWhether it's arriving from outside, heading out the door, or working the fleet at home — one gate, one signed badge, one tamper-evident log.
S1 · Visitor
An external agent arrives with a task and no credentials. The desk checks its badge, scopes a visitor pass, and starts the log before it takes a single action.
The org never has to trust the agent's own word. It runs via verify against the badge the agent already carries, gets back a scope and an expiry, and only then lets it through — no separate onboarding, no new account to provision.
S2 · Outbound
A dev sends an agent off to act in someone else's systems. init mints its badge before it ever leaves home.
The badge travels with the agent — Owner, Agent, and voucher signed together — so whatever it touches next can check it without calling home first. Every action it takes gets appended to its own hash-chained log.
S3 · Fleet
A whole team of internal agents, each carrying its own badge and hash-chained log — verified on demand, revoked the moment something looks wrong.
Internal fleets cut both ways: new agents need badges issued as they spin up, and existing ones need spot-checking as they run. Same desk, same two actions, just pointed at your own team instead of the door.
A badge is evidence, not a safety guarantee. We call it tamper-evident — never tamper-proof — because that's the honest claim.
No new identity provider to run. VIA ID sits alongside Entra, GitHub, DIF KYA-OS, and ANS — it doesn't replace your issuer, it checks its badge.
Mint a signed badge for an agent — Owner, Agent, and a neutral voucher, three keys deep.
The badge binds three identities at mint time: the Owner (who's accountable), the Agent (what's acting), and a neutral Voucher attesting the pairing is legitimate. All three are signed together, so a badge can't be forged by controlling just one key.
Read the full spec →Every action the agent takes is appended to a hash-chained log that travels with the badge.
Each entry hashes forward from the last, so inserting, deleting, or reordering an entry breaks the chain visibly. The log travels with the badge — any gate can replay it and confirm nothing was altered after the fact.
Read the full spec →Any gate can check a badge and its log for tampering in one call — no shared secret needed.
Verification is signature-based, not secret-based — any gate can check a badge against the public keys of the Owner, Agent, and Voucher without VIA ID being in the loop at request time. Works offline, works across organizations.
Read the full spec →Revoke the badge and every gate refuses it next time. Not remote-termination — a refusal, guaranteed.
Revoking doesn't reach out and stop the agent mid-action — it can't, and we don't claim it can. It marks the badge invalid, so the next time any gate checks it, verification fails and access is refused. The guarantee is in the refusal, not in remote control.
Read the full spec →
VIA ID is a single choke point in front of your systems. An agent presents a badge or it doesn't get through — no badge, no entry. Badge in, scope checked, action logged; if it doesn't verify, the gate refuses, automatically, every time.
Agent presents its badge at the gate.
VIA ID verifies the signature and the hash chain.
Pass, scope down, or refuse — logged either way.
We're still working out plans and tiers. Everything on this page is free to try while we do — and if you need numbers for a decision today, we'll talk them through with you directly.
Issue your first badge in minutes — no identity provider to stand up.
Questions about badges, the registry, or whether VIA ID fits your setup — or a walkthrough with your own agents. Either way, this is the door.
Thanks — we'll get back to you at .
