Skip to main content

Identity and signed traces

Every agent in Culvii is issued a verifiable identity at creation — specifically, a W3C Decentralized Identifier (DID). This page explains what that means and what's in v1.

The shared-key problem​

The default trust model in most agent frameworks is "everything in the runtime shares an API key." If you have ten agents and they all run in the same process, they all use the same API key when they call models, tools, or external systems. The audit log on the receiving end shows "the API key did this." It cannot show "agent 7 of 10 did this."

That makes per-agent revocation impossible. It makes per-agent attribution impossible. It makes blast-radius analysis after a security incident impossible.

For an SDK whose differentiator is governance, this is not acceptable.

The DID model​

Culvii issues each agent a DID when the agent is created. The DID is:

  • Globally unique. Two agents can never have the same DID, even across tenants.
  • Verifiable. The DID resolves to a public key controlled by the agent's runtime.
  • Long-lived. The same agent retains the same DID across runs, deploys, and version bumps within the same workspace.
  • Captured everywhere. Every audit event, trace span, and outbound model/tool call records the DID of the agent that initiated it.

This means an operator looking at the audit log can answer "what did agent X do?" without asking "which API key was that?"

What's in v1​

  • DIDs are auto-issued for every agent at creation.
  • DIDs appear in audit events in the actor_did field.
  • DIDs appear in run traces so you can attribute every step in a multi-agent flow to the agent that took it.

What's on the roadmap​

  • Programmatic DID handling. Resolving an agent's DID from outside Culvii, rotating keys, integrating with your DID method of choice.
  • Cryptographically signed traces. Trace events for each agent will be signed with the agent's key before leaving the runtime. Today, traces are protected by transport security (TLS) and platform-side integrity controls; tamper-evidence at the agent boundary is the goal.
  • Verifiable claims. Agents holding verifiable credentials issued by your IdP, used to establish trust with downstream systems.
  • Bring-your-own DID method. Today, Culvii uses its own DID method (did:culvii:…). On the roadmap: support for did:web, did:key, and others.

The signed-trace model in particular is the architectural goal that drives the broader identity work. The current state ships the DID; the signing surface follows.

What this means in practice​

In v1, here's the most you can rely on:

  • Open the Console → Audit. Every event has the DID of the agent that triggered it.
  • Open a trace for a run. Every step is attributed to the agent (DID) that ran it.
  • Run an agent in a workflow that calls another agent. Both DIDs appear in the trace, with the call chain preserved.

That's enough to answer most operator questions today. The roadmap items make the integrity story end-to-end.

Why we're upfront about the gap​

We're spending a page describing identity because it matters and because the gap between v1 and the goal is not invisible. We could have shipped DIDs without saying anything about signing — most products would. We'd rather you know what we think the right architecture is, what's there now, and what's coming.

If signed traces are a hard requirement for your environment, talk to us about your timeline.