https://biackr0se.github.io/blog/projects/Recent content in Work on b̷I̶a̸c̷k̶r̷0̴s̸e̷Hugoen-usFri, 26 Jun 2026 00:00:00 +0000https://biackr0se.github.io/blog/projects/toolhive-ssrf/Fri, 26 Jun 2026 00:00:00 +0000https://biackr0se.github.io/blog/projects/toolhive-ssrf/<h2 id="the-target">The target</h2> <p>ToolHive (Stacklok) runs Model Context Protocol servers for you, each one in its own isolated container, behind an egress proxy, with no local credentials handed to it. The security model is explicit in the README: every MCP server is untrusted, so it stays boxed. That promise is the whole point of the tool.</p> <p>Before a remote MCP server ever reaches its container, ToolHive runs OAuth discovery against it to work out how to authenticate. That discovery runs host-side, in the ToolHive process, outside the per-server sandbox. The question, then, is whether the untrusted server gets to influence what the trusted host fetches during discovery. It does, and that is the finding.</p>https://biackr0se.github.io/blog/projects/automcp/Sat, 04 Apr 2026 00:00:00 +0000https://biackr0se.github.io/blog/projects/automcp/<h2 id="what-it-is">What it is</h2> <p>AutoMCP is an MCP server built on LangGraph that plugs LLM agents into an Elastic SIEM. It pulls security alerts, triages them, drives response actions, and performs counter-reconnaissance against the source of an attack.</p> <h2 id="why-it-exists">Why it exists</h2> <p>Alert triage is the part of detection engineering that burns analysts out. The interesting question is how far an agent can go past summarizing an alert: pivoting on it, enriching it, and acting on it, while staying inside guardrails a SOC would accept.</p>