Hi — I found coven-reach while looking at MCP projects where agents read, write, inspect, or hand off workspace artifacts.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected agent actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace coven-reach’s MCP responses, OpenCoven logs, workspace state, tool output, file permissions, or normal agent coordination. The receipt only proves a narrow claim:
a specific signer signed a specific claim, and the signed claim has not been altered.
Your repo seemed relevant because coven-reach provides workspace filesystem tools for agents, including read/write/list/find/familiarity/secret-check behavior, and appears to be part of the broader OpenCoven ecosystem for multi-agent coordination.
A receipt could potentially bind selected events like:
- workspace artifact read or written;
- file path or safe workspace-relative path;
- pre/post artifact hash;
- generated report or summary hash;
- secret-check result hash;
- OpenCoven agent/session/task reference;
- MCP tool name;
- privacy-preserving argument/result digest;
- status;
- timestamp/event ID;
- signer/public key ID.
The strongest use case would be when a workspace artifact, generated report, secret-check result, or agent-produced file is handed to another agent, maintainer, reviewer, CI job, or downstream workflow, and they should not have to fully trust the original local MCP runtime or workspace state.
BoundaryAttest would not prove the file contents are correct, the secret check is complete, the agent action was wise, or the system is safe. It would only prove that a specific claim about a selected artifact or handoff was signed and has not been altered after export.
Does that kind of portable signed receipt fit any workflow you imagine for coven-reach or OpenCoven, especially around workspace artifact handoffs or selected security-check outputs? Or are normal MCP responses and local/OpenCoven logs enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around MCP workspace and agent-coordination tools.
Hi — I found coven-reach while looking at MCP projects where agents read, write, inspect, or hand off workspace artifacts.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected agent actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace coven-reach’s MCP responses, OpenCoven logs, workspace state, tool output, file permissions, or normal agent coordination. The receipt only proves a narrow claim:
Your repo seemed relevant because coven-reach provides workspace filesystem tools for agents, including read/write/list/find/familiarity/secret-check behavior, and appears to be part of the broader OpenCoven ecosystem for multi-agent coordination.
A receipt could potentially bind selected events like:
The strongest use case would be when a workspace artifact, generated report, secret-check result, or agent-produced file is handed to another agent, maintainer, reviewer, CI job, or downstream workflow, and they should not have to fully trust the original local MCP runtime or workspace state.
BoundaryAttest would not prove the file contents are correct, the secret check is complete, the agent action was wise, or the system is safe. It would only prove that a specific claim about a selected artifact or handoff was signed and has not been altered after export.
Does that kind of portable signed receipt fit any workflow you imagine for coven-reach or OpenCoven, especially around workspace artifact handoffs or selected security-check outputs? Or are normal MCP responses and local/OpenCoven logs enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around MCP workspace and agent-coordination tools.