Updating did:trail focus after Anthropic Managed Agents launch - spec extension proposal

[chrishooooo-netizen]

Yesterday (April 9, 2026), Anthropic launched Managed Agents - cloud-hosted, autonomous Claude instances running multi-hour sessions via MCP server connections. I want to share how this affects the did:trail roadmap and propose two concrete spec extensions for community input.

Why this is relevant to did:trail

Managed Agents close one gap cleanly: intra-platform agent identity within Anthropic's ecosystem. Anthropic manages auth, session handling, and tool access for agents running on their infrastructure.

But they leave another gap structurally open: cross-platform, regulator-grade verification of agent deployments.

Specifically: if an enterprise deploys an Anthropic Managed Agent that prepares credit decisions (EU AI Act Annex III, Category 5), and a BaFin auditor asks "show me the audit trail of this agent's identity and authorization over the last 3 months" - the deployer cannot answer that without Anthropic's cooperation. Anthropic is a US company. The EU Cloud Act problem applies.

This is precisely the use case did:trail is designed to address.

---

Proposed Spec Extensions

Extension 1: Agent Deployment Identity (did:trail:agent:*)

Current assumption in the spec: an agent has a stable identity and directly interacts with the registry.

Reality with Managed Agents: agents are dynamically provisioned per session. The persistent identity is the deployment (a configuration), not the running instance.

Proposed addition to Section 4.2 (Identifier Modes): a new agent mode:

did:trail:agent:{deployment-suffix}

• Created and registered by the deployer organization (which already has did:trail:org:*)
• • Represents one agent deployment configuration across all its instances
• • Lifecycle: as long as the deployment is active
• • Parent: the deployer's did:trail:org DID via trail:parentOrganization
    This maps cleanly to the "deployment vs. instance" distinction common in container orchestration (Kubernetes Deployment vs. Pod).

Extension 2: PlatformIdentityBinding VC

How does an external auditor verify that a specific Anthropic Managed Agent deployment corresponds to a registered did:trail:agent DID - without asking Anthropic?

Proposed new VC type:

{
  "type": ["VerifiableCredential", "PlatformIdentityBinding"],
  "issuer": "did:trail:org:acme-corp-eu-a7f3b2c1e9d0",
  "credentialSubject": {
    "id": "did:trail:agent:acme-sales-agent-v2-de-3f8c",
    "platformIdentity": {
      "platform": "anthropic",
      "deploymentId": "managed-agent-deployment-abc",
      "attestedBy": "did:trail:org:acme-corp-eu-a7f3b2c1e9d0"
    }
  },
  "validFrom": "2026-04-01T00:00:00Z",
  "validUntil": "2027-04-01T00:00:00Z"
}

Key design decision: the deployer organization signs this VC, not the platform. TRAIL doesn't need Anthropic's (or Azure's, or Google's) cooperation to work. The deployer attests the binding from their own accountability. This is consistent with how Tier 1 KYB works today.

This makes did:trail platform-agnostic by design: the same pattern works for Anthropic, Azure AI, Google Vertex, and future platforms without any platform-specific code in the spec.

---

Open Questions for Community Input

1. Delegated Attestation vs. Self-Attestation: Should the PlatformIdentityBinding be self-attested by the deployer (as proposed) or should we require a third-party countersignature for high-risk AI deployments? The EU AI Act Tier 2 requirement seems to point toward the latter for Annex III use cases.
2. Mid-Session Revocation: Long-running agent sessions (6+ hours) create a new revocation challenge. Current spec covers < 1h to < 48h revocation latency. How should TRAIL handle "revoke an active session"? Options: (a) push notification to MCP servers, (b) session-level attestation with short TTL, (c) out-of-band.
3. Cross-Registry Scenarios: If an Anthropic Managed Agent calls an Azure AI service, and both are registered in did:trail, how does the cross-resolution work? The federation section (§3.3) specifies the protocol but needs an example for this specific scenario.
4. Compatibility with A2A: Google's Agent-to-Agent Protocol (under Linux Foundation, also April 2026) uses a different identity model. Is there a composability path between A2A agent identity and did:trail? Or are they designed for different trust levels (operational vs. compliance)?

---

EU AI Act Context

Article 12 (Record-Keeping) requires high-risk AI systems to "enable automatic recording of events throughout the system's lifetime." For a Managed Agent deployment, "lifetime" spans all sessions over potentially months or years.

Platform-internal logs do not satisfy this requirement for cross-jurisdictional audit scenarios because:

• They require platform cooperation to access
• • They are not cryptographically bound to an external, verifiable identity
• • They may not be accessible to EU regulatory bodies without triggering CLOUD Act concerns
    did:trail's audit log API (planned for v1.2.0) addresses this directly.

Full spec tracking: Issue #9

I'll be drafting this as a formal spec PR. Feedback on the approach before I write the normative text would be very helpful.