Brooks McMillin

Agents blur the line between code and user, and the old security playbook doesn’t cover them. My team works on a small set of problems and tries to solve them well — the bet is that getting the primitives right beats chasing every prompt-injection variant after the fact.

That playbook gap shows up in specific ways. A code-reviewing agent with filesystem access will happily follow instructions embedded in a docstring it’s summarizing — the classic prompt-injection case, but the same class of bug reappears anywhere an agent treats retrieved content as untrusted-and-yet-executable. A multi-agent pipeline that lets one worker’s output become another’s system prompt inherits every trust-boundary violation of the first, silently, because nothing in the wiring forces a boundary to exist. Neither failure is a bug in the model; both are missing controls in the system around it. That’s the reframe worth sitting with: stop asking whether the model will behave, and start asking what happens when it doesn’t — what has access to what, what a compromised step can reach, and what it takes to notice and contain the blast radius. Once you take that as the starting assumption, most of the work becomes ordinary systems security: identity, least privilege, auditability, sandboxing. The interesting part is doing that translation without also making agents unusable.

• Sandboxing, permissions, and runtime controls for autonomous agents
• Threat modeling for MCP, multi-agent systems, and production tool use
• Secure-by-default frameworks that make the safe path the easy path

When I evaluate a new agent capability, I start from three questions: what’s the worst thing this can do if every input is adversarial, who or what enforces that ceiling, and can we prove it held after the fact. If the answer to the second question is “the model’s judgment,” that’s not a control — it’s a hope, and hopes don’t survive contact with real usage. I’d rather ship a narrower capability with a hard boundary around it than a broader one that depends on the agent behaving. In practice that means building sandboxes and permission systems that agents can’t talk their way out of, keeping an audit trail detailed enough to reconstruct what actually happened after an incident, and treating every new tool or integration as an expansion of the attack surface until proven otherwise. The goal isn’t zero risk — it’s making the failure modes boring: contained, detectable, and cheap to recover from, instead of novel and catastrophic.

Agent adoption is moving faster than the controls around it. Companies are wiring LLMs into code review, customer support, and internal tooling with real write access, often before anyone has mapped what a compromised agent could actually do with that access. Regulators are starting to pay attention — the EU AI Act’s requirements for high-risk systems and a growing list of agent-specific incident disclosures are early signals, not the whole story — but policy will lag the deployments for years.

In the meantime, the practical exposure sits in the supply chain: an MCP server pulled from an unaudited registry, a third-party agent framework with no story for tool-call authorization, a plugin that can read more than the task in front of it needs. None of that requires a sophisticated attacker; it just requires nobody having asked the boring question of what’s actually allowed to happen. That gap — between how fast agents are being deployed and how carefully their permissions are being designed — is where most of the near-term risk lives, and where most of the interesting engineering work is too.

I take on a small number of consulting engagements — security reviews of agent and LLM systems, MCP server audits, and hardening for production deployments. If you’re just comparing notes on what’s breaking in production, that’s welcome too. The inbox is open.