Repository navigation
Question: signed receipts for selected OODA computer-control / action handoffs? #14
Description
Hi — I found mnehmos.ooda.mcp while looking at MCP servers where agents can observe, decide, and act on a real computer through shell, filesystem, screen, input, browser, clipboard, window, and process/session tools.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace mnehmos.ooda.mcp’s OODA design, shell execution, filesystem tools, CRUD database, screenshot tools, keyboard/mouse control, window management, clipboard tools, browser automation, interactive sessions, batch dispatcher, safety limits, config, OS records, or normal MCP/client logs. The receipt only proves a narrow claim:
a specific signer signed a specific claim, and the signed claim has not been altered.
mnehmos.ooda.mcp seemed relevant because it exposes a broad computer-control surface through MCP: CLI execution, file read/write/copy/move/delete, diff editing, persistent CRUD state, screenshots and screen-change detection, keyboard/mouse input, window control, clipboard read/write, system/process/network tools, browser automation, interactive process sessions, SSH/REPL-style sessions, and batch/parallel execution.
A BoundaryAttest receipt could potentially bind selected events like:
- MCP server/tool reference;
- OODA phase reference, such as observe, orient, decide, or act;
- client/session reference;
- command/action digest;
- shell stdout/stderr/exit-code hash;
- file read/write/edit/delete request digest;
- resulting file hash;
- screenshot or screen-change result hash;
- keyboard/mouse/window action digest;
- clipboard read/write result hash;
- browser automation request/result hash;
- interactive session or process reference;
- CRUD record/change hash;
- batch operation summary hash;
- per-operation success/failure summary;
- status, such as observed, decided, executed, refused, edited, deleted, clicked, typed, captured, automated, batched, failed, exported, or handed off;
- timestamp/event ID;
- signer/public key ID.
The strongest use case would be when a command result, file mutation, screenshot, UI action trace, browser automation result, clipboard operation, interactive session output, batch execution report, debugging packet, support handoff, or audit artifact leaves the mnehmos.ooda.mcp runtime, and another user, reviewer, downstream agent, customer, or future audit trail should not have to fully trust a screenshot, copied terminal output, mutable filesystem state, clipboard state, browser state, or transient MCP transcript.
BoundaryAttest would not prove the command was safe, the agent made the right decision, the UI action had the intended effect, the file content was correct, the browser page was trustworthy, the user was authorized in a legal sense, the machine stayed unchanged afterward, or the runtime was uncompromised. It would only prove that a specific claim about a selected computer-control action/artifact/handoff was signed and has not been altered after export.
Does this kind of portable signed receipt fit anything you imagine around mnehmos.ooda.mcp, especially around shell execution, file mutations, screenshots, keyboard/mouse actions, browser automation, interactive sessions, batch operations, or downstream audit/debugging handoffs? Or are the current OS records, config, MCP responses, batch summaries, and client logs enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn whether signed receipts are useful where MCP servers expose unrestricted computer-control capabilities to agents.
Activity