Approving one action must not approve its twin

[theoadam2506-rgb]

Authority’s first evidence-backed article examines a narrow authorization failure:

If two agent actions are identical in every relevant field except their action-instance identifier, should an approval granted to one authorize the other?

In the reproduced scenario:

• A1 and A2 have the same fingerprint, requester and invoked delegation.
• Approval P1 is granted only to A1.
• P1 is not consumed.
• A1 is AUTHORIZED.
• A2 remains REQUIRES_APPROVAL.

Removing the action_id comparison incorrectly allows A2 to reuse P1. The mutation causes three regression tests to fail.

The result is intentionally limited. It demonstrates action-instance approval binding in Authority V0. It does not establish cryptographic identity, exactly-once execution or protection against every form of replay. It also does not mean that every fingerprint-scoped authority query must distinguish A1 from A2: AVAILABLE, INVOKED and RECORDED answer different questions.

Article:

https://authority-graph.com/articles/approval-binding-action-instance

French version:

https://authority-graph.com/fr/articles/approval-binding-action-instance

Implementation evidence:

46e1321

Questions for discussion:

1. In which systems should approvals always be bound to one action instance?
2. Are there legitimate workflows where approval reuse across identical fingerprints is desirable? If so, how should that broader scope be represented explicitly?
3. What identifier or evidence should allow two organizations to establish that they are referring to the same action instance?
4. Does the distinction between AVAILABLE, INVOKED and RECORDED authority expose a missing case or an incorrect assumption?
5. Can you provide a minimal counterexample in which Authority’s current result should be different?

Corrections, questions and reproducible counterexamples are welcome. Please report exploitable vulnerabilities privately through GitHub Private Vulnerability Reporting or security@authority-graph.com rather than posting them here.

This article and discussion were prepared with material AI assistance. The cited implementation, tests and claims were reviewed and approved by Théo Adam.