Pre-action authority receipts for computer-use agents

[rpelevin]

I’m testing an authority-before-action receipt pattern for computer-use agents.

The gap I’m looking at is narrow: before an agent executes a consequential action, can the workflow prove that this exact action was authorized before execution?

For this class of workflow, the boundary seems especially relevant around credentialed browser submits, external sends, workflow close, and data export.

Reference benchmark:
https://github.com/neurarelay/relay-action-card#agent-authority-benchmark

Dry-run command:

npm run benchmark:agent-authority -- --dry-run --json --source=github_discussion --campaign=agent_authority_week --surface=simular_agent_s_computer_use_authority

The benchmark is refs-only and local/dry-run: no private payloads, no downstream execution by Neura, and no claim that this project has adopted, endorsed, integrated, or been evaluated by it.

Question for maintainers/users here: is a pre-action authority receipt a useful boundary for this repo’s agent workflows, or would the better insertion point be somewhere else in the execution lifecycle?

[0xddneto]

This boundary is very relevant for AIPOU too, especially for computer-use agents that can click, submit, export, or send things in a credentialed browser.

The split I would suggest is:

• pre-action authority receipt: proves this exact action was authorized before execution;
• execution result: records what happened after the action;
• work receipt: records the larger human/agent task or run, with local hashes instead of raw prompts/outputs;
• optional claim/reward: later validator-approved AIPOU path for the human operator, separate from execution authority.

That separation matters because an authorization receipt should not imply useful work happened, and a reward/work receipt should not grant permission to execute a sensitive action.

AIPOU examples/docs:

• https://github.com/0xddneto/AI-Proof-of-Us/tree/main/examples/lifecycle-adapter
• https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/evidence-boundaries.md

For Agent-S, I would expect the strongest insertion point to be just before consequential browser side effects: submit, send, export, purchase, account mutation, or workflow close. The receipt can then be linked to the post-work workReceiptId after the task finishes.