Skip to main content

Identity and audit attribution

Every audit event records who caused it. Today that's the person who acted, not a per-agent cryptographic identity. Here's the real model, and what we're building toward.

What's actually attached to an audit event​

Each event carries the initiating user's identity, alongside action, resourceId, resourceType, correlationId, result, and a UTC timestamp. See Authentication for how that identity is established.

Agent-level attribution inside a run comes from the agent's own id/name in its MultiAgentEngine config, plus its permission scope (see Primitives at a glance), not from a separate identity the platform issues. If a workflow runs three agents, the audit log tells you which agent's step ran (via the run's structure), but the credential on record for all three is the user who deployed the workflow.

Where this is headed​

We think per-agent, cryptographically verifiable identity, something closer to a W3C DID than a shared deploying identity, is the right end state for a platform whose pitch is governance. It's not built yet: there's a placeholder resolve(did) interface in the SDK's types, but no issuance, no key material, and nothing in the audit path reads from it today.

Concretely, not shipped:

  • Per-agent identity independent of the user that deployed it.
  • Cryptographically signed trace events (today, transport security and platform-side integrity controls are what you get, not agent-signed spans).
  • Bring-your-own identity method, or verifiable credentials for agents.

If cryptographic per-agent attribution is a hard requirement for your environment, talk to us about timeline before you build against it.

What you can rely on today​

Open the Console's audit view for any workspace and you'll see, per event, which user initiated it, what the action was, when, and whether it succeeded. That's real, append-only, and it's enough to answer "who deployed this," just not yet "which specific agent, independent of who deployed it, did this."