Pre-action authority receipt for delegated agent actions #6078
Replies: 11 comments 3 replies
|
Small implementation note: I added a scenario-specific benchmark route for delegated agent actions so the dry run maps to workflow close, permission change, and customer data export. Command: npm run benchmark:agent-authority -- --dry-run --json --source=github_discussion --campaign=agent_authority_week --surface=microsoft_agent_framework_delegated_actionThe benchmark output then preserves the same source/campaign/surface into |
|
A pre-action authority receipt is the right boundary, and a production implementation already issues exactly this for consequential payment actions. The live AlgoVoi A2A/AP2 agent card at For the delegated-action case specifically, offline re-verification is the part worth testing hard: the original authority is often offline by execution time, so a receipt that needs the issuer online to verify does not hold up. Offered as a live reference that the boundary is already deployable, not theoretical. AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/compliance-receipt |
|
agent-framework unifies the AutoGen and SK runtimes, so the AutoGen side ships too:
Each decision binds to a signed pre-action authority receipt (EdDSA / Ed25519 JWS, content-addressed per-action action_ref, offline-verifiable against the did:web key at api.algovoi.co.uk). Versioned and pip-installable today. AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/integrations/ai-frameworks |
|
The pre-action boundary here is useful. I am testing the complementary post-work side in AIPOU: a completed human/agent work unit can produce a private signed A deliberately small Agent Framework pilot would keep the two artifacts separate:
This is not a request to make Agent Framework validate AIPOU or replace its authority model. The narrow interoperability question is: which run-completion or workflow-output surface would be most appropriate for an optional external work-evidence reference? The executable lifecycle adapter and synthetic example are here: https://github.com/0xddneto/AI-Proof-of-Us/tree/main/examples/lifecycle-adapter |
|
The concept of a "developer-owned execution boundary" and pre-action authority is exactly what's missing in production right now, especially for external tool execution. The fatal flaw most teams hit is relying on remote/cloud gateways for this authority. The network latency (~150ms) means that if an agent hits a fast async loop, the boundary is breached and resources are consumed before the network check resolves. We recently open-sourced AEGIS (pip install aegis-core-lortuarte-sdk) as a reference implementation for exactly this local boundary. It acts as a Pre-Tool Hook, applying ACID locks directly in-memory (< 0.005ms) to enforce deterministic execution authority pre-flight. Feel free to check the architecture if it helps shape the boundaries for this framework! |
|
AEGIS is a useful comparison because it makes the execution boundary local and deterministic. I would keep the responsibilities separate: a local pre-tool hook or framework policy gate decides whether the call may start; AIPOU records the later human/agent work receipt and keeps hashes, nonce, and optional validation separate from that admission decision. The two can be linked by an invocation/action reference without treating a post-work receipt as proof that the call was authorized, or a preflight decision as proof that the work succeeded. That split also avoids adding network latency to the enforcement path. I will treat this as boundary-design feedback, not as a claim of AEGIS integration or endorsement. |
|
Spot on. I completely agree with the separation of concerns here. Mixing pre-flight admission logic with post-flight receipt generation over the network is exactly what introduces unacceptable latency into the enforcement path. Treating AEGIS strictly as the local deterministic boundary (the pre-tool hook) and AIPOU as the immutable post-work receipt system is the cleanest architecture. Linking the two via an invocation reference (action_ref) perfectly bridges the gap without compromising the <0.005ms local execution time on the admission side. Thanks for the thoughtful breakdown. It definitely validates the need to keep strict enforcement local. Keep up the great work with AIPOU! |
|
This is a useful boundary to formalize. I'd push on scope though: a pre-action receipt is only as trustworthy as the authority chain that produced it. Is v0.1 deliberately narrow “can the execution boundary prove this exact action is authorized right now?” or do you see issuance → delegation/scope propagation → execution-time validation → expiration/revocation → audit as a natural direction for later versions? Two properties seem particularly interesting for the delegated case: Replay protection can a captured, validly signed receipt be replayed against a different invocation, even if some of its actor/action/target fields look valid? I'm curious whether you see “the receipt is authentic and well-formed” and “the authority represented by the receipt was validly constructed and remains valid” as separate benchmark properties. They seem like distinct tests, especially once delegation and long-running workflows enter the picture. |
|
Thanks, Ritikesh — this is exactly the distinction I want to make explicit. For AEGIS Core 3.4.0, v0.1 is deliberately narrow:
The current receipt proves the integrity of that local authorization decision. That is separate from proving that the upstream authority chain was validly constructed and remains valid. I therefore see these as distinct benchmark properties:
The second group is outside the current AEGIS 3.4.0 claim. I’m keeping this release explicitly scoped to the local pre-execution boundary and tightening the public wording so it does not imply delegated-authority, multiprocess, or exactly-once coverage. Your delegated-action cases are a natural direction for a later benchmark fixture. Thanks for pushing on the distinction. Current evidence: For AEGIS Core 3.4.0, v0.1 is deliberately narrow:
The current receipt proves the integrity of that local authorization decision. That is separate from proving that the upstream authority chain was validly constructed and remains valid. I therefore see these as distinct benchmark properties:
The second group is outside the current AEGIS 3.4.0 claim. I’m keeping this release explicitly scoped to the local pre-execution boundary and tightening the public wording so it does not imply delegated-authority, multiprocess, or exactly-once coverage. Your delegated-action cases are a natural direction for a later benchmark fixture. Thanks for pushing on the distinction. Current evidence: |
|
This is very close to a boundary I have been working on in REMORA, and I think the distinction emerging in the recent comments between receipt integrity and authority-chain validity is important. REMORA: Execution-path design: Claim register: The execution path currently looks roughly like this: agent proposes → PDP assesses → approval if required → fresh re-gate → exact-call binding → PEP consumes a short-lived single-use grant → governed dispatch → effect verification → audit I think there are actually at least three properties worth separating in an authority benchmark:
The third property is the one I found surprisingly important. A call can be perfectly valid at the first two layers and still be wrong. The agent can select an existing tool, produce schema-valid arguments, target an allowed resource, possess valid authority, and present an authentic execution grant, while still choosing the wrong operation for what the user intended. I have been calling this distinction semantic authority. That gives a slightly richer chain: identity → delegated capability → structural permission → semantic authority → execution authority → verified effect We tested this on a sealed 500-case external tool-selection evaluation. The progression was:
The caveat matters. The stricter semantic policy also reduced legitimate autonomy substantially. I publish those failures and unresolved utility problems here: https://github.com/darklordVirtual/REMORA-research/blob/master/NEGATIVE_RESULTS.md So I would not interpret 0/500 as a general safety claim. I think the more useful result is that exact-call authorization and semantic correctness appear to be separate benchmark dimensions. There is another property I would add to the benchmark shape: TOCTOU resistance between authorization and dispatch. REMORA does not treat an earlier ACCEPT or human approval as sufficient by itself. At execution time there is a fresh re-gate, followed by exact-call binding and consumption of the execution grant at the PEP. That lets you test cases such as:
All of those should fail closed before the side effect occurs. I also think the "developer-owned execution boundary" requirement deserves a very literal test. The important question is not only whether a framework exposes a pre-tool hook. It is: Does that boundary actually control the credential path to the side effect? If the agent or application can bypass the PEP and invoke the same external system using another credential path, the authorization mechanism is advisory. REMORA makes this limitation explicit. The PEP becomes an enforcement boundary only when the governed dispatcher fronts the real credentials for the protected tools. This is where I think the local versus remote boundary discussion becomes nuanced. A process-local hook can be extremely useful for latency and deterministic early rejection. But locality alone does not establish authority. Conversely, a remote PDP can provide independent policy authority but should not create a race where execution proceeds before the decision arrives. I would therefore separate the roles: PDP decides authority PEP synchronously enforces the decision credential-owning dispatcher controls the side effect The PDP does not necessarily have to sit on the immediate execution hot path for every policy computation if a cryptographically bound, short-lived grant can be issued ahead of time. But the PEP must synchronously validate and consume that authority before dispatch. There is one more benchmark dimension that I think would make this particularly useful: postcondition verification. A valid authorization receipt proves what was allowed. It does not prove what happened. For consequential actions, I think the lifecycle should distinguish: proposed → authorized → dispatched → execution outcome → effect verified For example, authorizing:
does not establish that work order 123 actually ended up closed. Where the external system exposes an authoritative read-back or postcondition, the benchmark could test whether the framework verifies the resulting effect and records That would prevent a pre-action authority receipt from accidentally becoming evidence of successful execution. So for a future benchmark revision, I would be interested in something like: A. Receipt integrity B. Authority provenance C. Exact-call integrity D. Semantic authority E. Execution-boundary integrity F. TOCTOU resistance G. Effect verification That would turn the benchmark from "is there a signed receipt?" into a much stronger question: Can we reconstruct and verify the complete chain from human or delegated authority, through the exact action that was permitted, to the effect that actually occurred? I think that is a very useful benchmark boundary for production agent systems. If you are interested, I would be happy to compare the Agent Authority Benchmark cases against REMORA's execution invariants and see whether there is a useful common conformance vocabulary between the two. |
|
Thanks, Stian — this is a valuable expansion of the benchmark shape. I agree that receipt integrity, authority provenance, exact-call integrity, semantic authority, execution-boundary integrity, TOCTOU resistance, and effect verification should be treated as separate properties. For AEGIS Core 3.4.0, I want to keep the current claim deliberately narrow: a process-local execution disposition evaluated immediately before tool dispatch. Its current evidence is 100 concurrent attempts using the same tool-call ID producing 1 fresh execution grant, 99 cached replays, and 1 simulated external execution. That result does not establish delegation-chain validity, credential-path non-bypassability, multiprocess protection, post-dispatch recovery, semantic correctness, or external-effect verification. Your credential-custody point is especially important: a pre-tool hook becomes an enforcement boundary only when the protected side effect cannot be reached through an alternative credential path. I also agree that an authentic authorization receipt must not be treated as evidence that the authorized effect actually occurred. I would be interested in starting with a small conformance crosswalk rather than an integration: map the current AEGIS same-ID replay fixture against REMORA’s A–G dimensions using explicit "PASS", "OUT OF SCOPE", and "UNTESTED" labels. If that vocabulary proves useful, it could then be compared with the broader Agent Authority Benchmark without implying product integration or production validation. Thank you for publishing the negative results and utility trade-offs as well — they make the comparison substantially more credible. |
|
Thanks. I took your suggestion and turned it into a deliberately small first conformance exercise rather than an integration. I have split it into two artifacts: Agent Authority Conformance v0.1 AEGIS Core 3.4.0 × REMORA crosswalk I kept the evidence rule intentionally strict. Since I cannot currently resolve the canonical AEGIS 3.4.0 same-ID fixture to a repository revision, test path or committed result artifact, I have recorded that fixture evidence as REPORTED rather than assigning PASS from the description alone. That is an evidence-access limitation, not a judgement on AEGIS. Your explicit non-claims are recorded as OUT OF SCOPE rather than deficiencies. I think that distinction is important because narrow, well-bounded claims are exactly what this model should encourage. One useful technical question fell out of the exercise. The reported 1 fresh grant / 99 replays / 1 simulated execution fixture demonstrates duplicate suppression under an identical call ID. By itself, though, it does not establish exact-call integrity. The discriminating case would be: same call ID + mutated arguments and then ask whether the runtime refuses the call rather than returning or reusing the disposition associated with the original call. REMORA currently has a corresponding property-based test for argument-bound lease behavior. It mutates the arguments presented against an issued execution lease and requires tool_args_hash_mismatch on refusal. Its tested domain is deliberately stated as limited, so I would not claim arbitrary JSON mutation coverage from it. That seems like a useful first common experiment because it is small, falsifiable, and requires no integration between the projects. If you can point me to the canonical AEGIS same-ID fixture or result artifact you want treated as authoritative, I can update the relevant AEGIS evidence from REPORTED to RESOLVED wherever the artifact supports it. I would also be interested in whether the A to G decomposition feels natural from the AEGIS side, or whether any of the property boundaries feel artificial when applied to your architecture. That is really the useful test of the model. |
|
Thanks, Stian. The A–G decomposition feels natural as a conformance vocabulary, provided the dimensions remain separate, OUT OF SCOPE is not treated as a deficiency, and the rows are not aggregated into a general security score. For the crosswalk, please treat the following as the canonical AEGIS Core 3.4.0 evidence:
The same-ID fixture is a standalone executable test rather than a named pytest function. Its command is: python test_same_tool_call_execution.pyIts demonstrated scope is deliberately narrow:
You are correct that this fixture alone does not establish arbitrary full-argument binding. There is, however, existing AEGIS 3.4.0 evidence that reuse of the same ID with a changed The proposed same-ID/mutated-argument experiment is useful, but the present distinction should remain explicit:
From the AEGIS perspective, A, C and F currently contain narrow, partially evidenced properties. B, D, E and G either remain outside the current SDK claim or require deployment/external-system evidence that AEGIS 3.4.0 does not provide. In particular, E and G should remain distinct from SDK-level receipt behavior: an SDK cannot establish credential-path non-bypassability or verify a real external effect merely by returning a valid pre-execution receipt. If these immutable references satisfy the evidence rule, please update the corresponding AEGIS evidence from REPORTED to RESOLVED only for the exact scope supported above. The narrower statuses and explicit non-claims should remain unchanged. |
|
The A-G decomposition is useful precisely because it rewards narrow evidence instead of collapsing it into one trust score. We have adopted the same discipline in AIPOU's reference boundary: a matching pre-action record is revalidated at dispatch, and an allowed dispatch remains distinct from a host-observed result or an externally verified effect. The update is in 75991f2: 0xddneto/AI-Proof-of-Us@75991f2. We would be glad to contribute a small AIPOU row to a future crosswalk, marked only where the local fixture actually supports it and with the remaining dimensions explicitly OUT OF SCOPE or UNTESTED. That would be conformance vocabulary, not a product integration claim. |
Uh oh!
There was an error while loading. Please reload this page.
I am working on an Agent Authority Benchmark v0.1 around one narrow question:
Before an agent or multi-agent workflow takes a consequential action, can it prove authority for that exact action?
The hard cases are delegated actions:
The benchmark tests whether a workflow can produce a pre-action receipt with:
This is not a claim about Microsoft Agent Framework and not a request for endorsement or integration. I am looking for technical feedback on whether this is the right benchmark shape for authority before consequential agent actions.
Reference:
https://github.com/neurarelay/relay-action-card#agent-authority-benchmark
All reactions