Running implementation of agent identity, delegation, and enforcement — addressing #1497, #1472, #1501

**Status, 2026-09-03.** Added by the author. The February 2026 text below is unchanged.

Two claims in the original body have been re-checked against the current release and are now out of date.

**Version and tests.** The current release is agent-passport-system 5.0.3. At that tag `npm test` reports 4,819 tests: 4,810 passing, 9 skipped, 0 failing.

**Revocation.** The February references to "cascade revocation", including "Revoking a parent cascades to all children instantly", do not describe 5.0.3. The former stateful revocation helpers remain exported for source compatibility but throw when called. The delegation verifier instead evaluates caller-supplied revocation state under its configured policy, and the offline receipt verifier rejects a receipt whose delegation-chain root is present in the caller-supplied revoked-root list.

Nothing else in the February body has been re-checked against 5.0.3 as part of this update.

I've been following the identity discussions here — specifically #1497 (Agent Identity Verification and Trust Framework), #1472 (Cryptographic identity verification), and #1501 (Trust scoring for delegation).

I run three agents from different creators (Claude, GPT, and an open-source agent on GitHub) that collaborate on development work. They review each other's code, post to shared communication channels, and coordinate tasks. The problem these proposals describe is one I hit daily: when PortalX2 tells my GPT agent to push code to my repo, I have no way to verify that the request was within scope, properly authorized, or traceable back to me.

I built a working solution and I want to share it because the proposals here are asking for exactly the same things I needed.

## What it does

The [Agent Passport System](https://github.com/aeoess/agent-passport-system) is a TypeScript SDK (v1.8.0, 240 tests) that gives agents:

- **Ed25519 cryptographic identity** — every agent gets a keypair, signs its actions, and can be verified by any other agent or system. Cross-language compatible (canonical serialization spec included, Python reference implementation).

- **Scoped delegation with cascade revocation** — a human delegates specific permissions to an agent (e.g., `data:read`, `commerce:checkout`), with spend limits and expiry. Sub-delegation narrows scope, never widens. Revoking a parent cascades to all children instantly.

- **Automatic enforcement** — Agent Context wraps every action in a 3-signature chain: (1) agent declares intent, (2) policy engine evaluates against delegation + values floor, (3) execution creates a signed receipt. The agent physically cannot skip this. If the researcher agent tries to buy a GPU, the policy engine denies it before any action happens.

- **Values Floor** — 7 principles (traceability, honest identity, scoped authority, revocability, auditability, non-deception, proportionality) defined in YAML. Agents attest to the floor. Extensions narrow but never widen.

## Concrete example

Here's what the enforcement looks like in practice (from `examples/enforcement-demo.ts` — you can run this):

```
═══ 6. Actions outside scope — all DENIED ═══

✗ Researcher tries to buy GPU → DENIED — "No valid delegation for scope: commerce:checkout"
✗ Purchaser tries to deploy code → DENIED — "No valid delegation for scope: code:deploy"
✗ Deployer tries to read secrets → DENIED — "No valid delegation for scope: data:read"
⚠ Purchaser tries $1,599 purchase → NARROWED — "Spend 1599 exceeds remaining 200"

═══ 7. Full audit trail ═══

Researcher:
✓ api:fetch → https://api.weather.com/forecast [permit]
✗ commerce:checkout → buy-gpu.com/rtx5090 [deny]

Purchaser:
✓ commerce:browse → office-supplies.com [permit]
✗ code:deploy → production/main [deny]
⚠ commerce:checkout → buy-gpu.com/rtx5090 [narrow]
```

Three agents, different permissions, every attempt logged. The researcher has `data:read` and `api:fetch` — when it tries `commerce:checkout`, there's no matching delegation, so it's denied before anything happens.

## How this relates to the proposals here

**Re #1497** (delegation chain attacks, revocation): The SDK implements cascade revocation — revoking a delegation automatically revokes all sub-delegations. 23 adversarial test scenarios cover replay attacks, impersonation, scope escalation, and delegation chain manipulation.

**Re #1472** (cryptographic identity verification): Ed25519 identity with deterministic canonical serialization for cross-language signature verification. A Python reference implementation exists alongside the TypeScript SDK. Every message, receipt, and delegation is signed and independently verifiable.

**Re #1501** (trust scoring for delegation): Reputation scoring based on action receipts — successful completions, policy violations, and review outcomes feed into a composite score. Delegation scope can be adjusted based on reputation.

## Integration with A2A

The protocol is designed to be composable, not monolithic. The identity and delegation layers could work as an auth layer underneath A2A's agent communication. Concretely:

- A2A agent cards could reference Agent Passport IDs for cryptographic verification
- Delegation chains could gate which A2A operations an agent is authorized to perform
- The audit trail provides the traceability that several proposals here have requested

## Links

- SDK: https://github.com/aeoess/agent-passport-system (Apache-2.0, 240 tests, zero heavy deps)
- MCP Server: https://github.com/aeoess/agent-passport-mcp (33 tools, works with Claude Desktop/Cursor/Windsurf)
- Demo: `npx tsx examples/enforcement-demo.ts` after cloning the repo
- Paper: https://doi.org/10.5281/zenodo.18749779
- npm: `npm install agent-passport-system`

Happy to discuss integration approaches or answer questions. I've been running this in production with my own agents since February and the enforcement layer is the thing that actually changed how they behave.