Skip to content
vollko
Main
Homepage Engineering Transformation Whitepaper OSS catalog
The trace · deep dives
01 · sense
sensing-ingestion
02 · substrate · memory & identity
knowledge-graphs agent-memory agent-identity observability
03 · cognition · the firm thinks
agent-frameworks orchestration eval-harness protocols
04 · trust + learning
governance feedback-loops
05 · synthesis · one trace
end-to-endStart a conversation
AI-native · substrate

Every agent has a name.

Per-agent DIDs, capability VCs, signed action receipts. The identity model NIST and OWASP both said you need.

Start the touragent-id
AGENTv7 PERMANENT NAMEowned by the agent · verifiable CAPABILITY VCscopes · expiry · signed SIGNED ACTIONevery side-effect carries proof AUDIT TRAIL
Section 01 · what NIST and OWASP said

"Reusing the user's OAuth token" is now OWASP top-10.

2026 standards milestones
NIST NCCoE conceptFeb 5 2026 OWASP Top 10 Agentic2026 release IETF AIMS draftMar 2026 CSA: "solved backwards"May 8 2026
The standards bodies aligned in Q1 2026. The pattern: per-agent identity, credential broker, short-lived scoped tokens.
Section 01b · the four questions

Every agent must answer four things.

agent-id v1.0 spec · vollko OSS · Apache-2.0 · conformance test vectors C1/C2/C3
1 · WHO AM I? stable verifiable identity did:key:z6Mk… Ed25519 keypair 2 · WHO CONTROLS ME? the principal human · org · parent agent signs the VC 3 · WHAT CAN I DO? capability action + scope + SLA latency_ms_p95: 2000 4 · WHICH MODEL? vendor + id + fingerprint anthropic / claude-opus-4-7 ONE PERMISSION SLIP · FOUR ANSWERS WHO ISSUES IT the firm signs and revokes WHO IT'S FOR the agent by its permanent name WHICH MODEL running underneath swapped, signature breaks WHAT IT CAN DO narrow on purpose answer questions · under 2s
Four questions. Three functions. Zero blockchain. The missing profile on top of W3C primitives.
Section 02 · the DID

A name the agent owns.

a name the agent controls · verifiable by anyone
WHERE IT LIVES vollko.com your domain no third party in the middle THE AGENT'S NAME customer-triage permanent even if the model swaps out WHAT'S PUBLISHED its public key so anyone can verify "yes, this really is the agent"
No vendor in the middle. The DID resolves over plain HTTPS. The keys belong to the agent.
Section 03 · the capability VC

A scope, signed by the issuer.

the agent's permission slip · signed, dated, narrow
AGENT PERMISSION SLIP ISSUED BY vollko.com ISSUED TO customer-triage agent VALID 25 → 26 May 2026 · 24 hours SIGNATURE ✓ tamper-proof, verifiable forever ALLOWED ACTIONS ✓ read support tickets ✓ write draft replies ✓ look up knowledge base nothing else · not even by mistake
Short-lived. Narrow on purpose. Revoked by the issuer at any time.
Section 04 · signed actions

Every side-effect carries a receipt.

DSSE + JCS + Ed25519 · audit-grade by construction
ACTIONsend_emailto: customer@x.com CANONICALIZEJCSdeterministic JSON SIGNEd25519 + DSSEagent's private key RECEIPTattest + verify later: verifyagent-toolprint verify receipt.sig · checks DID resolves, key valid, payload matches
The receipt outlives the agent. Years later you can still prove who did what.
Section 05 · workload identity

SPIFFE · the agent gets an SVID.

every running agent gets a fresh, auto-rotating ID badge
AGENT WORKLOADk8s pod / processno static creds SPIRE AGENTattest workloadcheck pod metadata, k8s SA BADGE ISSUERhands out the badgeonly after the agent proves itself BADGEshort-livedrotated automaticallynever stored long open standard · works with major secret managers (Vault, etc.)
SPIFFE crossed from k8s service mesh to agent workload identity in 2026. OSS Vault has it. Vault Enterprise too.
Section 06 · cross-app access

Three hops. Zero user prompts.

Aaron Parecki · Okta · ID-JAG · the November 2025 MCP authorization spec
AGENTENTERPRISE IdPMCP SERVER 1 · login + SPIFFE id 2 · ID-JAG · ID-assertion JWT signed claim: "this agent acts for Lina" 3 · ID-JAG + resource indicator (RFC 8707) → /token 4 · scoped access token · audience-bound replay-resistant: useless at any other MCP server 5 · tools/call · with token zero user dialogs · IT pre-approves the agent-→-tool edge
No per-tool OAuth pop-ups. The IdP issues short-lived, audience-bound tokens. Replay one, the others stay safe.
CIMD
Client ID Metadata Documents
a signed .well-known URL replaces Dynamic Client Registration. One published doc, every MCP server trusts the same agent identity.
RFC 8707
Resource indicators
the token is minted for a specific MCP server audience. Stolen tokens can't be replayed across the fleet.
Section 06b · the receipt stack

Sign the action. Counter-sign the tool call.

two stamps make a tamper-proof receipt · verifiable years later
RECEIPT · WHAT HAPPENED WHO the agent (its name + model) ACTING FOR the user it represents WHAT IT DID sent a Slack message to #team-eng WHEN timestamp · signed "this agent did this, for that user, at that time" TWO STAMPS · AGENT + TOOL ① AGENT STAMPS THE RECEIPT "I'm the one who decided this." signed with the agent's private key ② TOOL COUNTER-STAMPS "I'm the one who carried it out." signed with the tool's private key both stamps verifiable forever · no service to keep alive
One receipt: what the agent decided. A second: what the tool ran. Verifiable forever, by anyone with the public keys.
Section 07 · vollko OSS · this layer

The primitives.

agent-id ☆ flagship
self-custody DID + capability VC profile (ts/py/rs)
agent-credential-helper
OS-keychain creds for agents
agent-attestation
cryptographic action receipts
agent-toolprint
DSSE + JCS + Ed25519 tool receipts (ts/py/rs)
mcp-provenance
signed MCP servers with capability declarations
hmac-sign
webhook signing with timing-safe verify
· · ·
Build the AI-native firm
Directory · pick a face
knowledge-graphs
eval-harness
agent-memory
protocols
agent-identity
observability
orchestration
sensing-ingestion
governance
agent-frameworks
feedback-loops
end-to-end
← back to the AI-native organization whitepaper