Pre-action authority receipt for delegated agent actions

[Roman Pelevin (rpelevin)]

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:

• one agent reasons or recommends;
• another agent prepares the action;
• a tool/runtime executes;
• the original user or owner authority can become ambiguous.

The benchmark tests whether a workflow can produce a pre-action receipt with:

• actor/runtime/tool/action/target refs;
• exact-call binding;
• delegated authority refs;
• evidence/policy refs;
• decision route;
• trace refs;
• developer-owned execution boundary.

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

[Roman Pelevin (rpelevin)]

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_action

The benchmark output then preserves the same source/campaign/surface into first_proof_next_command, so a local benchmark run can continue into a measurable first-proof path without losing the Microsoft Agent Framework route.

[AlgoVoi (Christopher Hopley) (chopmob-cloud)]

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 api.algovoi.co.uk emits a signed scoped-authorization receipt per action, binding actor, action, resource and an exact-call digest to a closed ALLOW / REFER / DENY decision, EdDSA/Ed25519 over JCS-canonical (RFC 8785) bytes, re-verifiable offline against a published JWKS.

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

[AlgoVoi (Christopher Hopley) (chopmob-cloud)]

agent-framework unifies the AutoGen and SK runtimes, so the AutoGen side ships too: algovoi-plugin-autogen (0.1.2) on PyPI:

pip install algovoi-plugin-autogen[autogen]

AlgoVoiGuardrailCapability registers as a tool_call_before hook and screens the recipient in any tool's input, returning {allow, verdict, reason} where verdict is categorical (ALLOW / REFER / DENY). It runs at admission time, before the action commits, so a REFER or DENY stops the call rather than annotating it after the fact.

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

[0xddneto (0xddneto)]

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 workReceiptId, while the authority receipt remains the only evidence for what was allowed before execution.

A deliberately small Agent Framework pilot would keep the two artifacts separate:

• the existing authority/action reference is evaluated before a consequential tool or workflow action;
• after completion, a lifecycle hook records local task/output hashes and returns an optional workReceiptId;
• the framework can attach that opaque reference to run, workflow, or delivery metadata without importing claim, wallet, or token semantics;
• a Local Receipt Mode fixture uses synthetic data only: no payment, customer data, wallet, claim, or external network requirement.

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

[Lortu | AEGIS Core (LortuArte)]

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!

[0xddneto (0xddneto)]

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.

[Lortu | AEGIS Core (LortuArte)]

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!