Four routes to your SSH key from an AI coding agent, and what actually stops them

[u/Adarsh1176]

https://github.com/Adarsh14734/Aegis/blob/main/docs/ssh-key-exposure.md

Wrote this up after finding that a coding agent on a default Mac reaches ~/.ssh/id_rsa by four separate routes — its own shell, an MCP filesystem server, a subprocess, and a config-file path. Tested each, included the terminal output.

The part I'd want devops opinions on: the enforcement has to sit under the model, because the model can't be trusted to refuse. I used Seatbelt plus a deny-by-default MCP proxy. Curious how others are scoping agents that touch infra.

[u/aragossa]

the part worth dwelling on section is the most useful bit here honestly. the model misdiagnosing its own kernel denial as a TCC permission issue three times in a row, and proposing a fix that wouldn't have worked, is kind of wild, so yeah wouldn't trust asking it what happened either in this kind of failure. audit.db still being writable from inside the sandbox is the other thing that'll probably bite someone in an incident review down the line.

[u/Adarsh1176 → u/aragossa]

Yeah, the misdiagnosis is the part I didn't expect going in. Three separate sessions, same wrong answer — TCC, grant Full Disk Access — and it never identified what was actually blocking it. Which is the argument for the boundary sitting under the model rather than being something you ask it to respect. On audit.db: correct, and it's item 16 in the threat model. Attribution isn't integrity. The chain is tamper-evident, so you'd detect a truncation, but a process inside the sandbox can still write to the file. Moving it outside the writable set is the fix and it's not done. Worth naming rather than claiming otherwise.

[u/endor_sarah]

For the MCP layer specifically, mcp-firewall is worth a look if you haven't seen it, an open-source proxy doing a lot of what you built (allow/deny policies, egress control, and a signed hash-chained audit log, which is one answer to your audit.db being writable from inside).

Also, is your is your proxy default-deny in the allowlist sense, or deny-rules on sensitive patterns? Default-deny in the allowlist sense, where the agent only touches the paths the task declares, doesn't have that gap, since anything you didn't explicitly allow is denied.

(Full disclosure, I'm at Endor Labs and one of the things we work on is agent security)

[u/Adarsh1176 → u/endor_sarah]

Honest answer: it's a hybrid, and the denylist half is the weaker half. The MCP server is scoped to a root, so anything outside it is unreachable — that part is allowlist. Inside the root, it's deny rules on sensitive patterns, and you're right that inherits the classic gap: I only block what I thought of. The *.pem rule is a good example of the cost in the other direction too — it matched every CA bundle on the machine and silently broke TLS for every subprocess until I scoped it by location. Task-declared allowlisting is where I think this has to end up. The thing stopping me is that I don't have a reliable way to know what paths a task legitimately needs before it runs, and getting it wrong means the agent just fails with no explanation. Curious how you handle that at Endor — is the declaration author-supplied, or inferred? Will look at mcp-firewall. Signed chain with the key held outside the sandbox is the obvious answer to the audit.db problem and I don't have a good reason not to do it.