The delegation chain problem APOA addresses is one of the hardest to test for, and one of the most dangerous in production.

We run adversarial tests against MCP and A2A implementations. The delegation-specific finding: in every multi-hop scenario we've tested, the downstream tool or agent authenticates the immediate caller but has zero visibility into the original human's intent or approval. Agent A calls Agent B calls Tool C - Tool C sees B's credentials and trusts the request. Whether the human ever authorized that specific delegation path is unknowable.

The DeepMind paper you referenced (Feb 2026) identified this theoretically. Our tests confirm it empirically across real implementations.

Two specific observations relevant to APOA's design:

1. Revocation latency matters more than initial authorization. Most delegation failures we see aren't unauthorized from the start - they're actions that were authorized when the session began but shouldn't be authorized anymore (context changed, incident declared, scope reduced). A policy layer needs sub-second revocation propagation through the delegation chain.

2. The may_act claim approach (RFC 8693) helps but is insufficient. It tells you who delegated to whom, but not the scope of delegation. Did the human approve 'read this database' or 'do whatever you need'? Most implementations we test default to the broadest interpretation.

We published research on this governance gap: Constitutional Self-Governance for Autonomous AI Agents - specifically mechanism GG-04 (escalation protocols) and GG-07 (cross-agent consistency verification) address delegation chain integrity.

Would be interested to see how APOA handles the revocation propagation problem.

@juanfiguera — the cascade revocation is the critical piece. Good to see it as a first-class operation rather than an afterthought.

One finding from our adversarial testing that might inform the RevocationStore interface design:

Revocation propagation latency is the attack window. In our MCP delegation chain tests, the gap between revoking a parent token and the downstream agent actually honoring that revocation was the single most exploitable moment. With short-lived tokens (your second method), we measured 8-15 seconds of residual access after revocation in the best case. With CRL polling (third method), it was minutes. An agent that receives a valid task during that window will execute it.

The instant push method is the only one that closes this to sub-second, but it requires the agent provider to maintain a persistent connection to the authorization server — which creates its own availability dependency. What happens when the push channel drops? Does the agent fail-open (dangerous) or fail-closed (breaks legitimate workflows)?

We have delegation chain tests in our harness that specifically target this window. If APOA has a reference implementation or test server, we could run them and report exact propagation latencies under different RevocationStore backends. The harness ships with MCP + A2A protocol tests — adding delegation-specific scenarios for APOA would be straightforward.

The DeepMind paper's framing of 'intelligent delegation' assumes revocation is instantaneous. It isn't. Quantifying that gap is where the real security engineering lives.

Really interesting framing — "Agentic Power of Attorney" captures the delegation model well. The key challenge is making the PoA enforceable and auditable, not just declarative.

I've been building a production implementation of a very similar concept. protect-mcp acts as a policy enforcement proxy for MCP tool calls. The "Power of Attorney" in our model works like this:

1. Delegation declaration: An operator creates a policy file that declares what tools an agent is allowed to use, under what conditions (rate limits, trust tiers, approval requirements)
2. Runtime enforcement: The proxy intercepts every tools/call and evaluates it against the policy — blocking, rate-limiting, or requiring human approval as specified
3. Cryptographic evidence: Every decision produces an Ed25519-signed receipt that captures the full context — what was decided, what policy was in effect, what trust tier the agent had

The receipts are the critical piece that makes APOA auditable. If an agent acts within its delegated authority, you have signed proof. If it tries to exceed its authority, the proxy blocks it and the receipt shows exactly what was attempted and why it was denied.

We also have a companion system for agent identity — ScopeBlind Passport — that lets agents present signed credentials to prove their authorization level.

Would love to compare notes on the policy schema and see if there's alignment on the delegation model.