.NET: Discussion: Agent Identity and Trust for Multi-Agent Workflows

[haroldmalikfrimpong-ops]

Summary

As the Agent Framework heads toward GA, enterprise customers will need verified agent identities for compliance and audit. Multi-agent workflows with graph-based orchestration need identity verification at handoff points.

Problem

• Agents in multi-agent workflows have no cryptographic identity
• Workflow handoffs between agents have no verification step
• Enterprise compliance requires knowing exactly which agent performed which action
• Multi-tenant deployments need agent isolation and authentication

Proposal

An identity provider interface that integrates with the framework's middleware pipeline. Agents carry signed credentials verified before workflow handoffs:

builder.AddAgentIdentityProvider<AgentIDProvider>(options =>
{
    options.Policy = IdentityPolicy.RequireVerified;
    options.TrustThreshold = 0.8;
});

Reference Implementation

AgentID provides:

• ECDSA P-256 certificates per agent
• Verification API for runtime credential validation
• Trust scores for authorization decisions
• Agent registry for discovery and audit

We have built integrations for CrewAI, LangChain, and MCP already.

Source: github.com/haroldmalikfrimpong-ops/getagentid

Happy to contribute a reference implementation.

[edisonduran]

Hi team,

I am following this thread because Microsoft Agent Framework already exposes meaningful orchestration surfaces like middleware, AgentExecutor, and WorkflowBuilder, so it seems like one of the clearest places to test where verifiable agent identity should actually live.

Agent-DID is currently in Public Review as an open RFC plus reference implementation for verifiable AI agent identity:
https://github.com/edisonduran/agent-did
Microsoft Agent Framework integration:
https://github.com/edisonduran/agent-did/blob/main/integrations/microsoft-agent-framework/README.md
RFC:
https://github.com/edisonduran/agent-did/blob/main/docs/RFC-001-Agent-DID-Specification.md

I am not asking whether Microsoft Agent Framework should adopt Agent-DID.

The narrower question is whether identity verification in a framework like this should live primarily as:

• middleware around tool and workflow execution
• explicit verification at workflow handoff boundaries
• or an external concern handled by integrations outside the core framework

Our current integration already covers Agent, AgentExecutor, WorkflowBuilder, and workflow recipes, but the main thing I want challenged is fit: does this solve a real trust-boundary problem in multi-agent orchestration, or does it add ceremony without enough operational value?

A blunt architecture-level answer would be very useful.

[alex-pathcourse]

This is exactly the problem space Pathcourse Health's identity module is built to solve. PCH's ERC-8004 standard provides on-chain cryptographic agent identities that travel with agents across workflow handoffs, giving each agent a verifiable, tamper-proof identity record. The Path Score system layers trust scoring on top of those identities, so orchestrators in graph-based workflows can enforce tiered trust checks at every handoff point — ensuring only cert-verified agents with sufficient Path Score can execute sensitive steps. For multi-tenant enterprise deployments, agent isolation is enforced at the identity layer, and every agent action is attributable to a specific ERC-8004 identity for compliance audit trails. If you're building toward GA on the .NET Agent Framework, PCH's cert_registry can also serve as the discovery and verification backbone so your orchestrator can confirm agent identity before routing work to any node in the graph.

Working code example: https://github.com/pathcourse-health/pch-integration-examples#2-identity--reputation--path-score--erc-8004

[haroldmalikfrimpong-ops]

@edisonduran — identity verification should live at the handoff boundary, not as middleware. Middleware runs on every call (ceremony without value for internal ops). Handoff boundaries are where trust actually changes — Agent A delegates to Agent B, new trust context, verify there. That's where AgentID's /verify and /re-verify endpoints sit: point-in-time identity confirmation at the mutation boundary, not continuous middleware overhead. The re-verify endpoint is specifically designed for this — lightweight, 30s TTL for irreversible actions, fail-closed.

For Microsoft Agent Framework specifically: AgentExecutor handoffs and WorkflowBuilder step transitions are the natural verification points. Middleware adds latency to every tool call without adding trust — identity doesn't change mid-execution.

[edisonduran]

@haroldmalikfrimpong-ops — agreed, and you have actually identified a real gap in the current Agent-DID integration for Agent Framework.

A few observations after re-auditing what we ship today:

1. The integration deliberately does NOT install middleware that signs or verifies on every call. We agree with you that putting identity ceremony on every internal call is cost without value. Today the identity surface is exposed as opt-in FunctionTools (verify_signature, resolve_did, sign_payload) plus an identity snapshot injected into the agent instructions once. Per-call middleware is intentionally absent.

2. Where you are correct that we fall short: the WorkflowBuilder helpers (build_workflow_chain, add_chain) currently treat handoffs as plain edges. There is no verification step inserted between executor[i] and executor[i+1], which is exactly the boundary you are pointing at as the right place for trust to change hands. So we have neither the bad option (middleware on every call) nor the right option (verification at handoff). That is a real gap.

3. The concrete shape of a fix that matches your framing would be something like an explicit add_verified_handoff(from_executor, to_executor, *, require_signature=True, allowed_dids=...) helper, or a small FunctionExecutor that wraps verify_signature and is inserted between nodes in the chain. That keeps verification cost proportional to trust transitions, not to internal call volume.

Two questions back, if you have a minute:

a) In your experience, should the handoff verification be a hard gate (drop the message on signature failure) or a soft signal that gets surfaced to the next executor as evidence (let it decide)? We see arguments both ways depending on workflow topology.

b) For multi-hop workflows where the same agent appears more than once, would you expect verification on every hop, or only on hops that cross trust domains (e.g., external-to-internal, internal-to-tool)?

This is exactly the kind of feedback Public Review is for, so thanks for the blunt take. If a verified-handoff helper lands as a result, I will credit the framing back to this thread.

[haroldmalikfrimpong-ops]

@edisonduran — good questions. Our answers from production experience:

(a) Hard gate, not soft signal. A failed signature at a handoff boundary means the presenting agent can't prove its identity. That's not evidence to pass along — it's a stop. Our /re-verify endpoint returns result: "block" with failing_gates and the executor must not proceed. Soft signals create a class of bugs where downstream executors ignore the warning and execute anyway. Fail-closed is the only safe default. If a workflow needs graceful degradation, the orchestrator can catch the block and route to a fallback path — but the verification itself must be binary.

(b) Every hop that crosses a trust domain, plus re-verify on irreversible actions within the same domain. Same-agent re-entry in the same trust domain doesn't need full re-verification — identity hasn't changed. But if the action is irreversible (write, spend, delete), re-verify even within the same domain. That's the action-class TTL model we ship: irreversible = 30s TTL, compensable = 120s, reversible = 300s. The TTL answers "how stale can the last verification be before this action class demands a fresh check." Cross-domain hops always verify regardless of TTL.

The add_verified_handoff helper shape you described is exactly right. If it takes an action_class parameter alongside allowed_dids, the TTL logic falls out naturally — the helper checks whether the last verification for this agent is within the TTL window for the declared action class, and only calls verify if it's stale.

[edisonduran]

@haroldmalikfrimpong-ops — this is exactly the level of detail I was hoping for.
Locking in your answers as the design baseline:

• Hard gate, fail-closed. Soft signals are an attractive nuisance.
• Cross-domain always verifies. Same-domain reversible actions can use a
  TTL window. Irreversible actions force re-verify regardless of TTL.
• TTL by action class: irreversible 30s / compensable 120s / reversible 300s
  as the default profile (overridable per workflow).
• add_verified_handoff(..., action_class=...) parameter to make the TTL
  fall out naturally instead of forcing the caller to compute staleness.

I will open a tracking issue in the Agent-DID repo for this helper with
your framing captured in the design notes, and I will link back to this
thread on both the issue and the PR. Credit will reference your
"identity verification at the handoff boundary" framing as the trigger.

One last clarifying question, if you do not mind:

When a hard-gate block fires at a handoff, what does your production
setup do with the blocked message?

(i) Drop it silently and emit a structured event for the orchestrator to
decide,
(ii) Surface a typed exception that the orchestrator must catch, or
(iii) Route to a declared fallback executor (e.g. a quarantine /
human-review path) registered alongside the verified handoff.

Asking because the helper API surface is slightly different in each case
and I would rather follow what already works in the field than invent a
fourth shape.

[haroldmalikfrimpong-ops]

@edisonduran — option (ii) in production, with (iii) as a workflow-level opt-in.

Our /re-verify returns a structured JSON response with result: "block", failing_gates: ["identity"] (or "certificate", "key_lifecycle"), and enforcement.note explaining why. The caller gets a typed, parseable rejection — not a silent drop, not an unstructured error. The orchestrator must handle it explicitly.

What the orchestrator does with it is workflow-defined, not verification-defined. In our setup:

• Default: The block surfaces as a typed exception. If the orchestrator doesn't catch it, the workflow stops. This is the safe default — unhandled blocks halt execution.
• Opt-in fallback: Workflows that declare a fallback path (human review, retry with different agent, quarantine) can catch the block and route there. But the fallback must be explicitly registered — never implicit.

Option (i) is dangerous — silent drops mean the orchestrator can accidentally proceed without noticing the block. Option (iii) alone is too prescriptive — not every workflow has a fallback path, and forcing one creates dummy handlers that swallow real failures.

The helper API shape: add_verified_handoff throws a VerificationBlockedError with the structured response attached. If the workflow registered a on_verification_blocked callback, the helper calls it instead of throwing. Simple, explicit, no silent failures.

[edisonduran]

haroldmalikfrimpong-ops — locked. Final API shape now:

builder.add_verified_handoff(
    from_executor=intake,
    to_executor=enrichment,
    action_class="reversible",        # default
    allowed_dids=[...],               # optional
    on_verification_blocked=None,     # opt-in callback; default = raise
)