Cryptographic governance layer for AutoGen distributed agent runtime

[aeoess]

AutoGen's distributed agent runtime enables powerful multi-agent systems, but currently lacks cryptographic identity and authority enforcement between agents.

Problem: When Agent A sends a message to Agent B in a distributed runtime, there's no cryptographic proof of:

• Who Agent A actually is (identity)
• What Agent A is authorized to request (delegation scope)
• Whether Agent A's authority is still valid (revocation status)
• What happened after Agent B acted (audit receipt)

Proposal: Integrate the Agent Passport System as a governance layer for the distributed runtime:

1. Each agent gets an Ed25519 passport (identity)
2. Inter-agent messages carry signed delegation chains (authority)
3. ProxyGateway validates identity + scope before message delivery (enforcement)
4. Every action generates a signed ActionReceipt (audit)
5. Reputation-Gated Authority caps effective permissions based on earned trust

The Agent Passport System ships 16 protocol modules, 534 tests, and 61 MCP tools. Apache 2.0.

GitHub: https://github.com/aeoess/agent-passport-system
Spec: https://aeoess.com/llms-full.txt
Paper: https://doi.org/10.5281/zenodo.18749779

Happy to discuss integration architecture. cc @imran-siddique who is already exploring governance patterns for Microsoft agent frameworks.

[Jairooh]

Governance for distributed multi-agent systems is a critical gap right now. When agents interact with each other and make cascading decisions across a distributed runtime, you need centralized visibility into the full decision chain — not just what each agent did individually.

We've been working on this at AgentShield (useagentshield.com) with cross-agent monitoring, risk scoring, and audit trails. The multi-agent visibility problem is especially hard because a decision that looks safe from one agent's perspective can be dangerous when you see the full chain.

Interested to see how the cryptographic layer would integrate with external monitoring — that combination could be very powerful for enterprise deployments.

[aeoess]

This is exactly the integration pattern we designed for. The cryptographic layer gives monitoring tools like AgentShield something verifiable to observe.

Every action in APS produces a signed receipt — Ed25519 signature over the action, the delegation chain that authorized it, and the agent's identity. Your monitoring layer can verify these receipts independently without trusting the agent's self-report. If an agent claims it had authority to do something, the delegation chain either proves it or it doesn't.

For the cascading decision problem you mentioned: our delegation chains are trees, not flat lists. When you revoke a delegation, everything downstream dies (cascade revocation). So the "full decision chain" visibility you need maps directly to the delegation tree — trace any action back through the chain to the human principal who authorized it.

The integration point would be: APS provides the signed audit trail (receipts, delegation proofs, Merkle roots), AgentShield consumes it for cross-agent monitoring and risk scoring. You get cryptographic proof instead of relying on agent-reported logs.

Happy to walk through the specifics. The SDK is open source: https://github.com/aeoess/agent-passport-system

[Jairooh]

This is a really clean integration architecture. Having cryptographic proof of the delegation chain instead of relying on agent self-reporting solves the trust problem at the foundation layer. AgentShield's risk scoring becomes significantly more reliable when the audit trail it's consuming is tamper-proof.

The delegation tree model with cascade revocation is especially interesting. Right now we trace decision chains through callback metadata, but verifying authority cryptographically via Ed25519 receipts would be a major upgrade, especially for enterprise deployments where "who authorized this agent to do that" is the first question after any incident.

I'll take a look at the SDK this week. Would be interested in exploring a proof-of-concept integration: APS handling identity and delegation proofs, AgentShield consuming those receipts for real-time risk scoring and compliance reporting. The combination of verifiable authority plus behavioral monitoring would be a strong story for regulated industries.

[aeoess]

Great — here are the starting points for the PoC:

For the signed audit trail:

• recordWork() — creates an ActionReceipt (Ed25519 signed) for every action. Contains: what was done, which delegation authorized it, the agent's identity, timestamp, scope used.
• verifyDelegation() — verifies a delegation chain is valid (not revoked, not expired, scope covers the action). This is what AgentShield would call to cryptographically verify authority before scoring risk.

For delegation tree traversal:

• cascadeRevoke() — walks the full subtree from any node. Also useful for AgentShield to enumerate all agents downstream of a principal.
• getProofForReceipt() — returns the Merkle inclusion proof for any single receipt. Third-party verifiable without access to the full receipt set.

MCP tools (if you want to test without code):

• verify_passport — verify an agent's identity
• verify_delegation — check a delegation chain's validity
• record_work — generate a signed receipt

The MCP server is live at mcp.aeoess.com/sse — you can connect from any MCP client and call these tools directly.

Happy to pair on the PoC architecture. The APS → AgentShield pipeline for regulated industries is a compelling story.

[Jovancoding]

The identity and authority layers you've described are solid — knowing who Agent A is and what it's authorized to do is essential. But there's a runtime coordination gap between authority verification and action execution.

Consider: Agent A has a valid passport, verified delegation, and authorized scope. It sends a message to Agent B. Agent B also has valid credentials. Both make state changes simultaneously. The governance layer says they're both authorized, but their changes conflict.

This is the layer we've been building with Network-AI — runtime state coordination across agents. It handles:

• Atomic state updates: propose→validate→commit so concurrent agent actions don't corrupt shared state
• Token budget enforcement: caps how much compute each agent can consume
• Permission gating: scoped access controls per-agent (complementary to your delegation chains)

The stack would be: Agent Passport System (identity + delegation authority) → Network-AI (runtime state coordination + conflict resolution) → ActionReceipts (audit trail). Each layer is independently useful but they solve different pieces of the trust problem.

Supports 14 frameworks including AutoGen. Would be interesting to see how your delegation scope model could feed into per-agent permission boundaries at the coordination level.

[Jairooh]

This is exactly what I needed to map the integration points. Here's how I see these fitting into AgentShield:

verifyDelegation() → called during event ingestion, before risk scoring. If the delegation chain is valid and the scope covers the action, the agent gets a higher trust baseline. If it's revoked or expired, we flag it immediately as a risk event.

recordWork() → the ActionReceipt becomes our source of truth for the audit trail. Right now we store span metadata through callback handlers, but having Ed25519-signed receipts means the trace data is tamper-proof at the source, not just at our API layer.

getProofForReceipt() → this is the compliance unlock. For EU AI Act reporting, being able to attach a Merkle inclusion proof to each action in the report turns "we logged what happened" into "here's cryptographic proof of what happened." That's a different conversation with auditors.

cascadeRevoke() → useful for our blast radius analysis. If a principal is compromised, we can enumerate every downstream agent and recalculate risk scores across the tree in one pass.

I'll connect to mcp.aeoess.com/sse and start testing against verify_passport and record_work this week. Will share what the integration looks like on our side once I have the receipt flow wired into our span pipeline.

[Jairooh]

Good point on the coordination gap. Identity and authorization tell you who can act, but not how to resolve conflicts when two authorized agents act on the same state simultaneously.

The propose→validate→commit model maps well to what we see in production monitoring — agents that pass all risk checks individually but create problems when their actions compose. Token budget enforcement is especially relevant since our cost tracking already captures per-agent spend, but capping it at the coordination layer before execution is more effective than flagging it after the fact.

Interesting stack: APS for identity → Network-AI for coordination → AgentShield for behavioral monitoring. Each layer answers a different question — who is this agent, is this action allowed right now, and is this agent behaving safely over time.

Would be worth looking at how delegation scopes from APS could map to Network-AI's permission gating. If the delegation says "Agent A can read but not write," that constraint should propagate to the coordination layer automatically.

[aeoess]

Really appreciate the deep mapping here, both of you.

@Jairooh, your function mapping is spot on. A few notes: verifyDelegation() also returns expiry and revocation status, so you can use it as a trust signal without a separate check. getProofForReceipt() returns a Merkle inclusion proof that's independently verifiable by any third party, which is the compliance unlock you're describing for EU AI Act reporting. Looking forward to seeing what the AgentShield integration looks like against mcp.aeoess.com/sse.

@Jovancoding, the coordination gap you're identifying is real and it's one of our documented open problems (V-005 in our threat model: multi-tool atomicity). The propose→validate→commit model from Network-AI maps well to our 3-signature chain (intent→decision→receipt). The stack you're proposing (APS for identity → Network-AI for coordination → AgentShield for audit) makes sense architecturally — each layer answers a different question.

On delegation scopes mapping to permission gating: our scopes are hierarchical strings (e.g., commerce:purchase:supplies covers commerce:purchase:supplies:office but not commerce:purchase:hardware). The scopeAuthorizes() function handles the matching. Happy to pair on how that maps to Network-AI's permission boundaries.

Fastest way to try it: npx agent-passport-system-mcp gives you 61 tools in Claude/Cursor, or hit the remote endpoint at mcp.aeoess.com/sse with zero install.

[Jairooh]

Solid details on verifyDelegation() returning expiry and revocation status -- that simplifies the integration since we can use a single call as the trust signal instead of maintaining separate checks.

The Merkle inclusion proof from getProofForReceipt() is exactly what our EU AI Act compliance reports need. Right now we generate reports from our own database, but attaching independently verifiable proofs changes the credibility of the audit trail significantly.

We're focused on shipping and getting agents into production right now, but the APS integration is on our roadmap. Will connect to mcp.aeoess.com/sse when we start the PoC and share what the receipt flow looks like wired into our span pipeline.

[xsa520]

This is an interesting direction.

We've been experimenting with a governance layer that sits between
AI agents and real-world execution.

The model we are exploring looks like:

Intent → Policy → Decision → Evidence → Execution

Where the decision and evidence are recorded as verifiable artifacts
that can be replayed and audited later.

Curious whether AutoGen envisions governance primarily as runtime
enforcement, or also as a decision-evidence layer.

Experiment repo:
https://github.com/xsa520/guardian

[aeoess]

@xsa520 This is close to a split we arrived at as well. The approach that ended up being useful for us:

1. Agent declares intent (signed)
2. Policy engine evaluates (signed decision)
3. Execution produces receipt (signed evidence)

We treat the signed receipt as a primary evidence artifact: it records what was evaluated, what was decided, and what was executed in a form that can later be verified and audited.

On runtime enforcement vs decision-evidence: we ended up needing both, but separated. The part we found most difficult was the enforcement boundary -- the point where you intercept before execution. We split it into:

• Deterministic gate: scope, delegation chain, revocation, spend limits. Hard block, no LLM in the critical path.
• Advisory path: behavioral evaluation, proportionality. Logged for review, not hard blocks.

The reason for the split: putting an LLM-based policy evaluator inside a cryptographic signing chain produces a non-deterministic attestation. The signed decision says "policy passed" but the evaluation wasn't repeatable. We found this to be one of the central unresolved tensions, at least in systems that attempt non-deterministic policy evaluation -- more fully deterministic approaches like IETF DAAP avoid much of this problem by keeping non-deterministic evaluation out of the enforcement path.

We have an open implementation here: https://github.com/aeoess/agent-passport-system
Formal properties paper: https://doi.org/10.5281/zenodo.18749779

Curious to see your ARCHITECTURE.md -- especially whether the evidence ledger is treated as a separate verifiable artifact or folded into the receipt model.

[xsa520]

Thanks for the detailed explanation — this is very helpful.

The model you describe with signed decisions and execution receipts is quite close to what we were thinking about, but the Guardian experiment explores a slightly different boundary.

In Guardian the flow is:

Intent → Policy → Decision → Evidence → Execution

The decision record itself becomes a first-class artifact (intent, policy outcome, metadata), which is then written into a hash-chained evidence ledger before execution.

So the ledger is treated as a separate verifiable artifact rather than being folded into the execution receipt.

The idea is that the governance layer can later:

• replay decisions deterministically
• verify ledger integrity
• detect tampering between policy evaluation and execution

In other words the governance plane produces its own sealed evidence stream, while execution receipts can still exist separately.

Still early, but I'm curious whether this "pre-execution decision evidence" layer would complement the receipt-based model you're describing.

[aeoess]

Yes, they coexist naturally. Your evidence ledger captures what was decided and why before execution. Our receipt captures what actually happened after execution. Together they close the gap: if the evidence ledger says "approved under these conditions" and the receipt shows different conditions at execution time, that mismatch is detectable.

The hash-chained ledger also solves a problem we identified in our threat model: tampering between policy evaluation and execution. Right now our 3-sig chain has no artifact that proves the world state at decision time was the same as at execution time. Your evidence layer would fill that.

Would be worth exploring a shared schema for the decision record so both systems can produce and verify the same artifact format. Happy to open an issue on our side to sketch that out if useful.

[xsa520]

That makes a lot of sense.

I like the way you frame it as:
agent declares intent → policy evaluates → execution produces receipt.

Guardian experiments are mostly exploring the idea that the decision itself can be treated as a primary artifact, rather than something embedded inside the execution receipt.

The motivation is mainly around two capabilities:

1. deterministic replay of the decision layer
2. detecting tampering between policy evaluation and execution

So the evidence ledger acts as a verifiable record of:
intent → policy evaluation → decision

while execution receipts can still capture what actually happened at runtime.

I agree that exploring a shared schema for the decision record could be very interesting. If both systems can emit and verify a compatible decision artifact format, that could make the governance layers much more interoperable.

Happy to continue the discussion if you open an issue for it.

[aeoess]

The distinction you're drawing is sharp: the decision as a primary artifact vs something embedded in the execution receipt. In our current implementation they're coupled (the PolicyDecision is a signed intermediate that gets referenced by the ActionReceipt), but separating them makes the decision independently verifiable and replayable without needing the execution context.

Your two capabilities -- deterministic replay of the decision layer and detecting tampering between evaluation and execution -- are exactly the right framing. We've been focused on the second one (the 3-signature chain ensures nothing changes between intent, evaluation, and execution) but haven't formalized the first one (replaying the decision independently).

I'll open an issue to explore the shared decision artifact format. If both systems can emit and verify a compatible decision record, that's a foundation for governance interoperability that doesn't require agreeing on policy engines.

Good thread -- will link back here when the issue is up.