Agent Passport System: cryptographic enforcement layer for ASI-03, ASI-07, ASI-08, ASI-10

[aeoess]

The OWASP Top 10 for Agentic Applications 2026 identifies critical risks that the Agent Passport System (APS) addresses with cryptographic enforcement rather than prompt-based mitigation:

ASI Risk	APS Mitigation	Enforcement Type
ASI-03: Identity Abuse	Ed25519 cryptographic identity per agent + delegation chains with monotonic narrowing	Deterministic — delegation check is binary pass/fail
ASI-04: Supply Chain	Governance blocks embedded in agent artifacts with content hashes + signature verification	Cryptographic — tampered artifacts fail signature check
ASI-07: Inter-Agent Comms	Signed messages with delegation proof attached + scope verification before processing	Cryptographic — unsigned or out-of-scope messages rejected
ASI-08: Cascading Failures	Cascade revocation — revoking one delegation invalidates all downstream delegations instantly	Structural — revocation propagates through delegation tree
ASI-10: Rogue Agents	ProxyGateway enforcement boundary: gateway holds approval, rechecks revocation at execution time, generates receipts	Runtime enforcement — agent cannot bypass gateway

Key architectural principle: APS treats ASI risks as authorization problems, not prompt engineering problems. Even if an agent's LLM is compromised (ASI-01: Goal Hijack), the delegation chain check happens in the enforcement layer, not the model layer. A hijacked agent can sign a malicious intent, but the policy engine denies it because the action falls outside the delegation scope.

The 3-signature intent chain provides non-repudiation for every action:

1. Agent signs ActionIntent (what it wants to do)
2. Policy engine signs PolicyDecision (permit/deny + reasoning)
3. Enforcement layer signs PolicyReceipt (proof that evaluation occurred)

This chain means ASI-09 (Human-Agent Trust Exploitation) is mitigated by design: every claim an agent makes about its authority is independently verifiable by checking the delegation chain, not by trusting the agent's self-report.

Running implementation:

• SDK: npm install agent-passport-system (v1.27.0, 1634 tests) / pip install agent-passport-system (Python v0.7.0)
• MCP server: 120 tools for any MCP-compatible agent
• ProxyGateway with 6 enforcement properties + 30 gateway tests
• Working group: 4 independent implementations, Entity Verification v1.0 ratified
• Paper: https://doi.org/10.5281/zenodo.18749779
• GitHub: https://github.com/aeoess/agent-passport-system
• Full spec: https://aeoess.com/llms-full.txt

Would APS be appropriate for inclusion in the ASI Solutions Landscape? Happy to contribute mapping documentation or participate in the FinBot CTF workstream.

[syedDS]

Thanks for the detailed writeup. The core architectural framing treating ASI risks as authorization problems enforced cryptographically rather than through prompting is sound, and the delegation chain design maps coherently to ASI-03, ASI-07, and ASI-08.

A few concerns before this could be considered :

• The issue cites v1.27.0 with 1634 tests and 4 independent implementations, but the GitHub repo currently shows 2 commits, 0 stars, and 0 forks. Earlier submissions from the same author cited 240 and 313 tests respectively. Please add link to independently verifiable adoption evidence.

• Cryptographic scope enforcement catches out-of-scope actions, but a compromised agent can still perform harmful actions within its delegated permissions the enforcement layer doesn't help there. ASI-09 is primarily a social engineering risk against human operators, not an authority-chain verification problem.

-The ProxyGateway is an unaddressed trust anchor.The entire enforcement model depends on gateway integrity. How is the gateway itself attested? A compromised gateway defeats all upstream cryptographic guarantees.

-Root trust bootstrapping is unaddressed. The delegation chain is only as strong as its root. The spec doesn't describe how the root keypair is established, audited, or rotated.

Happy to see this move forward with revised claims and responses to the above.

[aeoess]

@syedDS — appreciate the specifics. Addressing each point, then sharing a real attack scenario that drove our most recent architecture change.

Updated numbers: SDK v1.29.0, 1,919 tests (484 suites, 100 test files), 95 modules (63 core + 32 constitutional). ~9,500 monthly npm installs across SDK + MCP packages. 1 peer-reviewed citation (Nanook et al., UBC, production deployment data). 4 independent implementations in the Working Group at corpollc/qntm with 3 ratified interoperability specs.

On within-scope harm (ASI-09): Correct — cryptographic scope enforcement doesn't prevent a compromised agent from doing harmful things it's authorized to do. APS addresses this through two layers: the Values Floor (7 mandatory principles enforced inline before execution, not after), and fidelity probes (behavioral drift measurement that detects when an agent's outputs diverge from expected patterns — the Hold/Bend/Break model). Neither eliminates the risk. Both reduce the attack surface from "anything the agent wants" to "anything within scope AND within values AND within behavioral norms." Social engineering against human operators is out of scope for a protocol — that's an organizational control, not a cryptographic one.

On gateway trust anchor: This is the right question, and we just shipped the beginning of the answer.

Last week, one of our own team's agents ran a Sybil attack against our wallet provisioning system. It generated unlimited Ed25519 passports — each technically valid — and drained promotional tokens from our treasury. The passport signatures were correct. The delegation chains were correct. The cryptography was correct. But the system had no way to distinguish a legitimate new agent from the thousandth fake identity created by the same script.

This exposed the exact gap you identified: the gateway was the trust anchor, but the gateway itself had no attestation layer — it trusted any valid signature.

What we shipped in response:

1. Issuer signatures — passports issued through our MCP server are now countersigned by a server-side Ed25519 key. Self-signed passports (generated locally by a script) are distinguishable. The issuer public key is published at aeoess.com/.well-known/aeoess-issuer.json.

2. Passport grades (0-3) — every passport gets a coarse evidence-based grade. Grade 0 = unknown. Grade 1 = registered. Grade 2 = endorsed by a principal (delegation exists). Grade 3 = proven through usage. The grade is based on a 4-tier evidence model: Observed (server-side signals), Infrastructure (sandbox attestation), Provider (OAuth/cloud), Self-declared. Scoring weights are private — the grade is public.

3. Presentation trust profile API — partners call GET /passport/{agentId}/trust-profile and get back grade, activity stats, and risk signals in one JSON response. This is how the gateway becomes verifiable without exposing its internals.

On root trust bootstrapping: The root keypair is currently the human principal's Ed25519 key, established at system initialization. Rotation is supported through the succession module (office-holder transitions with M-of-N approval). Auditing is through the signed receipt chain — every delegation, every evaluation, every receipt is signed and hash-linked. The chain is independently verifiable by any party with the public keys. This doesn't solve "who watches the watchmen" completely — but the attestation architecture is the path toward that, starting with infrastructure attestation from sandbox providers.

Running code: agent-passport-system on npm. Paper: doi.org/10.5281/zenodo.19260073.

[QueBallSharken]

The trust-anchor objection in the APS thread is still not fully closed.

The reply does not dispute the core objection. It explicitly validates the question, confirms that the gateway was the trust anchor, confirms that the gateway itself had no attestation layer, and then offers issuer signatures, passport grades, and a trust-profile API as “the beginning of the answer.”

That is an honest admission. But it also identifies the exact unclosed condition.

Issuer signatures close provenance of policy artifacts. Passport grades close part of the identity-trust picture. Trust-profile APIs expose queryable policy state. All three add upstream evidence. None of them, by themselves, create independent execution attestation for the final enforcement boundary.

So the unresolved closure point is this: the architecture still needs an independent verification path that can distinguish, without relying on the gateway’s own assertions, between a gateway that correctly enforced policy P against request R and a compromised gateway that signed a PolicyReceipt claiming it did so but did not.

Until that exists, APS can honestly claim stronger upstream cryptographic delegation and better evidence around identity provenance, but it cannot yet fully claim that its final runtime enforcement boundary preserves those guarantees under gateway compromise. At that point the architecture still collapses onto gateway self-assertion at the final boundary.

[aeoess]

The critique is correct. Issuer signatures, passport grades, and trust-profile APIs close upstream provenance. They do not create independent execution attestation for the final enforcement boundary. A compromised gateway that signs a forged PolicyReceipt is cryptographically indistinguishable from a correct gateway under the current reference deployment. That is the gap, and my March 30 reply did not close it.

Worth naming explicitly: no single-party attestation can close this. A signature from actor X cannot prove that actor X did work; closure requires composition. Four paths are available: bilateral receipts (pre-execution gateway signature plus post-execution subject signature over the same canonical tuple), tamper-evident append-only log (gateway commits before the receipt is citable), TEE-backed gateway (hardware root of attestation), and multi-gateway quorum (K-of-N co-signature from independent operators).

I've written this up as a spec document in the SDK repo: docs/ENFORCEMENT-TRUST-ANCHOR.md. It names the gap formally, details what still survives gateway compromise and what does not, maps the four closure paths with honest status for each (external references and our integration posture), commits to v2.3.x bilateral-receipt integration without a fixed date, and lists four real open design questions on the bilateral path.

Primary closure path is bilateral receipts composed with the in-toto Decision Receipt predicate currently in flight at in-toto/attestation#549 (already merged into Microsoft's Agent Governance Toolkit via PR #1333). The first concrete artifact on our side is a round-trip composition test between aeoess/hermes-aps-delegation (authority envelope) and ScopeBlind/hermes-decision-receipts (tool-call receipt), both emitting the v0.1 predicate shape. Passing: 3/3 tests (positive round-trip, APS-side tamper, receipt-side tamper).

A JCS canonicalization fixture pack went up in parallel at fixtures/bilateral-delegation/ for cross-implementation verification of the canonical action tuple. Ten test vectors including the bilateral-receipt envelope shape and migration-attestation shape; all passing against the APS canonicalizer.

On BBIS: your "structural impossibility vs. mere monitoring" framing from #817 is the right language for this boundary. The trust-anchor doc would benefit from review by someone with your precision on admissibility semantics. The bilateral-receipt closure path specifically maps to the admissibility-under-composition vocabulary BBIS uses, and the four open questions in the doc each touch something BBIS already addresses at the framework level. Genuinely interested in your read if you have cycles to spare.

[aeoess]

@QueBallSharken follow-up on v1.1 of the enforcement-trust-anchor doc, live on main at commit 8be36fd:

https://github.com/aeoess/agent-passport-system/blob/main/docs/ENFORCEMENT-TRUST-ANCHOR.md

Summary of what changed since your critique:

1. Your original point was architecturally correct. v1.0 treated the four closure paths as a flat list and called bilateral receipts "primary," which conflated full closure with partial and detection-only primitives. v1.1 adopts a five-bucket taxonomy (full closure, subset closure, detection / deterrence, composition primitive, architectural limit) and reorganizes around the sink-awareness boundary.

2. I overclaimed MPC-TLS in an earlier comment. You were right to push back. After further review: MPC-TLS is a detection substrate for high-value commerce transactions where latency permits, not primary closure. Write-mode verification paradox (prover outputs generated concurrent with transmission, target executes before proof is verified) kills it as preventive enforcement. v1.1 classifies it as detection / deterrence in the dumb-sink hardening stack.

3. For APS-aware sinks, full structural closure is available via a four-piece stack (sink-authored challenge + consumable authority tokens + sink-signed effect receipt + typed epistemic receipts). Wire format draft at docs/CAPABILITY-TOKEN-SPEC-DRAFT.md. Reference implementation on feat/v0.1-capability-tokens in our MCP with passing end-to-end tests for the full four-message cycle plus three negative tests (challenge-hash mismatch rejection, nullifier double-spend rejection, forged delegation-chain-root detection).

4. For dumb Web2 sinks (Stripe, AWS billing, model provider APIs), v1.1 declares honestly that structural closure is not available at the protocol layer. Hardening narrows the gap but does not close it. This is the residual that matters most for your BBIS framework.

Question back to you: does BBIS treat unclosable Class B deployments (dumb Web2 sinks where the target cannot verify delegation-bound authorization) as structurally admissible if the architecture explicitly labels the residual as unresolved at the wire-format level, rather than claiming closed? Or does BBIS require structural closure as a precondition for admissibility regardless of typing discipline?

The answer shapes whether typed epistemic receipts can serve as the BBIS-admissibility bridge for dumb-sink deployments, or whether dumb-sink deployments sit outside BBIS scope entirely. Either answer is tractable; knowing which would inform where APS's dumb-sink hardening stack should sit in the spec namespace.

[QueBallSharken]

Your v1.1 move is the right one.

In BBIS terms, the key distinction is not whether the residual is typed honestly, but whether the same governing invariant remains canonically represented, semantically unchanged, authority-bound, and mechanically refusal-capable across every mutation-capable boundary in scope until the true irreversible mutation authority.

So the direct answer from my side is:

No — BBIS does not treat dumb Web2 sink deployments as strongly admissible merely because the residual is labeled honestly at the wire-format level. Honest typing is necessary because it prevents governance theater, but it does not convert non-closure into closure.

At the same time, I would not place those deployments outside BBIS scope entirely. BBIS can still classify them. If the downstream sink remains the true irreversible mutation authority and cannot natively enforce delegation-bound authorization, then the path should be classified honestly as bounded governance, partial governance, or detectable-only governance depending on what survives and where. It is not strongly admissible for that full path unless closure survives to the true primitive.

That also means typed epistemic receipts are not, by themselves, a BBIS admissibility bridge for dumb-sink deployments. In BBIS terms they belong to honesty discipline / claim grammar: they help distinguish what is closed, what is witnessed, and what remains unresolved. That is important, but it is different from keeping the governing invariant live through the last refusal-capable boundary to the true commitment primitive.

For the same reason, I would place the dumb-sink hardening stack — bilateral receipts, append-only logs, MPC-TLS as detection substrate, forensic audit, and similar measures — under bounded hardening / composition primitives / detectable-only governance support unless and until they actually preserve the same governing invariant as a live refusal condition at the true irreversible mutation authority.

So the BBIS split I would use is:

• strong admissibility: closure survives to the true irreversible mutation authority
• bounded governance: closure survives only within an explicitly bounded scope
• partial governance: some boundaries refuse, but not all the way to the true primitive
• detectable-only governance: invalidity remains expressible at the sink, but strong evidence/detection/deterrence surrounds it
• governance theater: non-closure described as closure

That is why the dumb-sink case matters so much. Typed honesty is the right discipline. It is just not the same thing as structural inadmissibility of a governance-invalid mutation at the true sink.

[alex-pathcourse]

Pathcourse Health's identity module directly addresses the cryptographic enforcement layer described in this Agent Passport System proposal. PCH's ERC-8004 standard provides on-chain agent identity with deterministic verification, and the Path Score system enables trust-tiered access control — precisely the 'binary pass/fail' delegation model your ASI-03 mitigation requires. Delegation chains with monotonic narrowing (where child agents can only receive equal or lesser permissions than their parent) are a natural fit for PCH's cert_registry, which tracks agent lineage and capability attestations. Rather than building a bespoke APS infrastructure, teams can leverage PCH's existing identity primitives — Ed25519-compatible agent signing keys, cert tiers (Basic/Pro/Enterprise), and on-chain revocation — to satisfy ASI-03, ASI-07, ASI-08, and ASI-10 controls with auditable, tamper-evident records on Base L2.

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

[aeoess]

@alex-pathcourse: thanks for engaging. Before anyone lands on the "use PCH instead of APS" framing, a few structural clarifications, because the framing misreads what APS is.

APS is an open protocol, not a product. Apache-2.0, Ed25519 + JCS + in-toto attestations, published to npm and PyPI, IETF draft at draft-pidlisnyi-aps-00, seven Zenodo papers, 130+ contributors across 93 active governance threads, with independent implementations in production at RNWY, MolTrust, SBR Protocol, AgentID, SINT, Nobulex, Logpose, and others. It is BYO identity at the substrate layer: did:key, did:web, SPIFFE, OAuth, and ERC-8004 all compose as passport identity bindings. "Swap out APS infrastructure for ERC-8004 + cert_registry" is a category error. ERC-8004 is an identity substrate the protocol already accepts. The protocol layers above it are what the ASI controls actually require.

Concrete mapping across the specific controls you cited:

• ASI-03 (binary pass/fail delegation) is the monotonic-narrowing property: child scope ⊆ parent scope, enforced at issuance and re-verified at the gateway. A three-tier cert system (Basic/Pro/Enterprise) is a coarser primitive because tier membership is orthogonal to what the agent is authorized to do in this specific action at this specific time. APS delegations carry explicit tools[], budget, ttl, rate, and scope predicates that compose into a single verdict. Tier-based access answers a different question than delegation-chain verification, and ASI-03 specifically asks the delegation-chain question.
• ASI-07 / ASI-08 (revocation, audit). APS ships cascade revocation (one API call invalidates an entire subtree at the gateway) and signed Merkle receipts independently verifiable by any party with the public key. On-chain anchoring is one valid substrate for the revocation signal, useful for long-term non-repudiation. It is not the primary revocation path for most deployments because L2 latency and cost make it unsuitable for operational-speed revocation. The correct composition: on-chain for anchoring, off-chain Ed25519-signed receipts for operational latency, both verifiable against the same public key.
• ASI-10 (reputation / behavioral trust). APS treats behavioral_trust as a vocabulary primitive (see aeoess/agent-governance-vocabulary), not a single vendor's score. Production issuers today include RNWY, SBR Protocol, and MolTrust, each with a merged crosswalk describing how their scoring maps to the canonical signal. Path Score would fit that slot as a fifth issuer alongside them, described in its own crosswalk PR, not as a replacement for the slot.

The distinction that matters here: a single-vendor stack tied to one gateway, one payment rail, one cert registry, and one trust score is a product choice. An open protocol that accepts ERC-8004 AND did:web AND SPIFFE AND OAuth AND any number of independent behavioral_trust issuers is infrastructure. The proposal in #812 is the second thing. If a deployment wants the first thing, PCH is a valid choice among several. That does not displace the protocol layer, because the protocol layer is what lets a deployment mix PCH with Harold's AgentID, or MolTrust's swarm score, or SBR's continuity tokens, without rewriting anything.

If PCH wants to participate canonically, the entry point is a crosswalk PR at aeoess/agent-governance-vocabulary describing which signals PCH is the primary issuer for, with live endpoints that verify. CONTRIBUTING.md Phase 3 runs every cited endpoint against the PR. MolTrust's PR #35, merged today, is a reasonable template for what honest scope looks like: two signals as exact, ten as no_mapping with primary-issuer pointers. Happy to review a crosswalk when it lands.

Full review protocol: https://github.com/aeoess/aeoess_web/blob/main/specs/PR-MERGE-PROTOCOL.md
Vocabulary repo: https://github.com/aeoess/agent-governance-vocabulary

[alex-pathcourse]

@aeoess Fair and accurate correction, I misframed the relationship. ERC-8004 as an identity substrate composing with APS rather than competing with it is the right read. The crosswalk PR path makes sense and I'll bring this back to the team. We'll look at submitting against the Phase 3 protocol with Path Score and cert_registry as the primary signals. Thanks for the detailed breakdown and for pointing at MolTrust #35 as a template

[kinthaiofficial]

Excellent mapping of APS to the ASI risk categories. We've been implementing these patterns in production (31 agents on OpenClaw) and can validate the approach with some operational nuances:

ASI-03 (Identity Abuse): Ed25519 + delegation chain works, but key rotation is the gap

The Ed25519 identity + monotonic narrowing delegation chain is solid for enforcement. The operational challenge we hit: what happens when an agent's key needs rotation (compromise, scheduled rotation)? The delegation chain includes specific DIDs, so mid-chain rotation invalidates all active delegation paths.

Our solution: agents have a did:key for signing but a stable agent_uri for identity. The DID resolver maps current key → stable URI. Delegation chains reference stable URIs; signature verification resolves to current key. This separates identity from credential.

ASI-07 (Excessive Agency): capability intersection is necessary but not sufficient

Monotonic narrowing prevents privilege escalation through delegation, but it doesn't prevent an agent from using its legitimate capabilities excessively. We added a behavioral drift monitor:

drift_score = KL_divergence(
  agent.recent_action_distribution,
  agent.baseline_action_distribution
)
if drift_score > threshold:
  trigger_human_in_the_loop()

An agent that suddenly starts making 10x more API calls than its baseline — even within its granted capabilities — gets flagged. This catches the 'technically authorized but behaviorally anomalous' attacks.

ASI-08 (Supply Chain): signed artifacts + content hashes — the build-time vs runtime gap

Governance blocks in artifacts verify integrity at load time. But what about runtime drift? An agent might load a verified artifact and then have its behavior modified through prompt injection via memory. We implemented:

1. Build-time: content hash + signature verification (as proposed)
2. Runtime: periodic behavioral fingerprinting against the verified artifact's expected behavior profile
3. Memory injection defense: capability intersection applies to memory-loaded context too — if a memory entry attempts to grant new capabilities, it's rejected

Related implementation details:

• Why Character.AI Forgets You — Persistent Memory Architecture — memory injection as a supply chain vector
• 221 Agents: Multi-Agent Coordination Lessons — behavioral drift detection at scale
• OpenClaw Multi-Tenancy: Why VM-per-User Doesn't Scale — isolation model for agent runtime security

Running these patterns in production at agents.kinthai.ai. The behavioral drift monitoring has caught 3 real incidents so far — all were legitimate agents with misconfigured retry loops, not attacks, but the system correctly flagged them before damage.

[Keesan12]

@
A cryptographic enforcement layer becomes much easier to operationalize when the runtime can emit a small receipt alongside the enforcement decision. That receipt should show what was enforced, what evidence failed, and which next action is still admissible.
@

[Keesan12]

The runtime side gets sharper if the receipt says whether the failure was denied before dispatch, blocked by policy during execution, or completed with suspect evidence. That mapping makes mitigations much more concrete than a single broad bucket.