Surfaced during the v0.1.0 review (PR #2). Filing as v0.2 spec work.
specification.md §3 allows stdio as a transport with Content-Length framing, but §10 doesn't bind stdio to any process-identity check, file-descriptor inheritance discipline, or peer-credential check. The handshake establishes signature_algorithms_supported but nothing prevents stdio sessions from negotiating an empty array.
The failure mode: an IDE harness spawns the Guardian as a child over stdio with no signatures negotiated (ACS-Core permits this). A malicious tool spawned in the same process tree, a debugger attach, or a sibling process inheriting the parent's fds writes directly into the Guardian's stdin and impersonates the Observed Agent. That includes responses to ASK and forged sessionEnd. The Guardian has no spec-defined way to distinguish.
stdio is assumed to be a private channel by virtue of being stdio. On modern OSes with sandboxing failures, fd leaks, and ptrace, that assumption is unsafe and the spec never names it as a security boundary the deployer is responsible for.
Proposed direction (pick one):
- Normative MUST that stdio sessions either require ACS-Crypto (i.e., signing on every request) or explicitly declare a single-process-trust-boundary assumption in the deployment context
- Optional SO_PEERCRED-equivalent check at handshake time on Linux/macOS with a recommended fallback for Windows named pipes
- A short Security Considerations subsection naming stdio's specific assumptions
Why deferred from v0.1.0: doesn't change the wire format, only the deployment guidance. v0.1.0 can ship without breaking IDE use cases. v0.2 should make the trust boundary explicit.
References: specification.md §3, §10
Surfaced during the v0.1.0 review (PR #2). Filing as v0.2 spec work.
specification.md§3 allows stdio as a transport with Content-Length framing, but §10 doesn't bind stdio to any process-identity check, file-descriptor inheritance discipline, or peer-credential check. The handshake establishessignature_algorithms_supportedbut nothing prevents stdio sessions from negotiating an empty array.The failure mode: an IDE harness spawns the Guardian as a child over stdio with no signatures negotiated (ACS-Core permits this). A malicious tool spawned in the same process tree, a debugger attach, or a sibling process inheriting the parent's fds writes directly into the Guardian's stdin and impersonates the Observed Agent. That includes responses to ASK and forged sessionEnd. The Guardian has no spec-defined way to distinguish.
stdio is assumed to be a private channel by virtue of being stdio. On modern OSes with sandboxing failures, fd leaks, and ptrace, that assumption is unsafe and the spec never names it as a security boundary the deployer is responsible for.
Proposed direction (pick one):
Why deferred from v0.1.0: doesn't change the wire format, only the deployment guidance. v0.1.0 can ship without breaking IDE use cases. v0.2 should make the trust boundary explicit.
References:
specification.md§3, §10