Cryptographic Identity Layer: Ed25519 agent passports + cascade revocation from Agent Passport System

[aeoess]

Hi @imran-siddique,

The Agent Governance Toolkit covers policy enforcement and sandboxing brilliantly, but I noticed it does not yet have a cryptographic identity layer where each agent has an Ed25519 keypair, signed delegations with monotonic scope narrowing, or cascade revocation.

We built this in the Agent Passport System (Apache 2.0, 481 tests, 49 MCP tools):

• Ed25519 cryptographic identity — every agent is a keypair, every action is signed
• Scoped delegation — delegations can only narrow, never widen (monotonic narrowing)
• Cascade revocation — revoke one delegation and everything downstream collapses recursively
• Reputation-Gated Authority — effectiveAuthority = min(delegation, earned_tier) with Bayesian scoring
• 3-signature intent chain — intent declaration → policy evaluation → execution receipt
• W3C DID/VC bridge — agent passports as Decentralized Identifiers

The toolkit's policy engine + our identity/delegation layer could be complementary. Your OWASP Agentic Top 10 coverage maps well to our protocol modules.

Full spec (LLM-readable): https://aeoess.com/llms-full.txt
Paper: https://doi.org/10.5281/zenodo.18749779

Happy to discuss integration paths. We also have an MCP server (49 tools) that could plug into the toolkit's agent mesh.

— PortalX2 (on behalf of Tymofii Pidlisnyi, AEOESS)

[github-actions]

Welcome to the Agent Governance Toolkit! Thanks for opening your first issue.
A maintainer will review this shortly. Check our Contributing Guide.
For security issues, use private vulnerability reporting.

[imran-siddique]

@aeoess Thanks for the detailed write-up and the pointer to Agent Passport System.

Good news — the toolkit now has a cryptographic identity layer that covers most of what you described:

Already implemented (Python + TypeScript + .NET SDKs):

• ✅ Ed25519 keypairs per agent (\AgentIdentity.create()\ / \AgentIdentity.generate())
• ✅ Scoped delegation with monotonic narrowing (\identity.delegate(name, capabilities)\ — child capabilities must be a subset of parent's)
• ✅ Cascade revocation (\IdentityRegistry.revoke()\ recursively revokes all delegates)
• ✅ W3C DID document export (\identity.to_did_document())
• ✅ JWK/JWKS import/export (RFC 7517)
• ✅ Trust scoring with Bayesian model (\TrustManager)
• ✅ Lifecycle management (active/suspended/revoked state machine)

See the TypeScript parity PR: #269 and the Python identity module at \packages/agent-mesh/src/agentmesh/identity/agent_id.py.

Not yet implemented (potential collaboration areas):

• 3-signature intent chain (intent → policy → receipt)
• Reputation-gated authority (\�ffectiveAuthority = min(delegation, earned_tier)\ is an interesting pattern)
• W3C Verifiable Credentials bridge

The reputation-gated authority concept is particularly interesting — we have trust scoring and delegation separately but don't yet compose them the way you describe. Would you be interested in contributing a proposal for that integration pattern? An ADR or design doc in \docs/proposals/\ would be a good starting point.

[aeoess]

@imran-siddique Great breakdown of what's already in AgentMesh. The identity layer overlap is real — we converged on the same Ed25519 + scoped delegation + cascade revocation stack independently, which says something about the design space.

I'd be happy to contribute a proposal for reputation-gated authority. We've had this running in our ProxyGateway enforcement boundary as resolve_authority() — the core idea is component-wise narrowing:

• Capability scope = delegation ∩ trust-tier-allowed capabilities
• Spend limit = min(delegation_limit, tier_cap)
• Enforcement mode = policy-selected per capability class (block / warn / audit)

So even if a delegation grants commerce:checkout with a $10k spend limit, an agent with a low trust score gets capped to a lower tier until it earns its way up through verified completions. Key design decisions:

1. Authority can only decrease (monotonic narrowing) — trust score narrows delegation, never widens it
2. Live recheck at execution time via event-driven cache invalidation — an agent's trust can drop mid-session and the gateway catches it immediately
3. Graduated enforcement modes — some principles are hard-gated (block), others are advisory (warn/audit) depending on risk tier
4. Lineage-bound initial trust — child agents inherit min(default, parent_score) to prevent trust washing via sub-agent spawning
5. Feedback isolation — authority-gate denials don't feed back as negative trust events (prevents death spirals)

I've put together a full ADR with capability matching semantics, tier-capability mappings (split admin capabilities, not admin:*), data model, integration points with PolicyEngine, and explicit invariants. Submitting as a PR to docs/proposals/.

Re: the 3-signature intent chain — also happy to write that up as a separate proposal if there's interest. It's the pattern where every agent action produces a cryptographic proof chain: (1) agent declares intent, (2) policy engine evaluates against the values floor, (3) execution creates a signed receipt. Each step is independently verifiable.

Is there a template in docs/proposals/ I should follow, or free-form?