Brooks McMillin
Infrastructure Security Engineer at Dropbox
I lead a team focused on AI agent security and LLM tooling. We build the frameworks engineers use to ship AI features safely.
About
I'm a security engineer who treats AI as the next infrastructure problem. After a decade across web application firewalls, abuse investigations, and platform security, I now lead a small team at Dropbox focused on the messiest part of modern shipping: keeping AI features from quietly turning into attack surface.
My background is unusual for AI security work — I came up through hands-on operational security, not ML research. That shapes how I think about agents and LLMs. I treat them as capable but fundamentally untrusted processes, the same way I'd treat a third-party binary running in production. The interesting question isn't "can we trust the model?" — it's "what does the system look like when we assume we can't?"
Most of my time goes to the unglamorous side of that question: sandboxing, permission boundaries, identity, and the developer-facing tooling that makes secure defaults the path of least resistance. The goal is for engineers to ship AI features quickly and for the security guarantees to come with the framework, not as an afterthought review.
mcp-authflow: OAuth 2.0 for Production MCP Servers
Open-sourcing mcp-authflow and mcp-authflow-resource: an RFC-compliant OAuth 2.0 framework for MCP servers, plus a one-command example server. Why MCP deployments need real auth, what the two packages do, and three non-obvious gotchas from production.
Read ArticleCurrent Focus
AI Agent & Infrastructure Security
My team keeps AI agents from doing things they shouldn't. We give engineers the tools to ship AI features without creating new attack surface — sandboxes, permission systems, identity primitives, and runtime guardrails that work for autonomous, semi-autonomous, and copilot-style systems alike.
We work on a small set of problems and try to solve them well. The bet is that getting the primitives right — capability tokens, scoped sandboxes, audit trails that survive production — is more durable than trying to detect every prompt injection variant after the fact. Defense in depth, but for systems that are probabilistic by design.
What we work on
- Sandboxing, permissions, and runtime controls for autonomous AI agents
- LLM security tooling that fits into existing developer workflows
- Threat modeling for MCP, multi-agent systems, and tool-use patterns in production
- Identity, access control, and data protection for AI/ML infrastructure
- Internal frameworks that make secure-by-default the easiest path for shipping AI features
- Audit logging and incident response patterns for non-deterministic systems
How I Approach the Work
A few principles that guide what my team builds and how we evaluate trade-offs. They've held up across roles at Facebook, American Airlines, and Dropbox, and they're what I'd point to if you asked why our work looks the way it does.
Build, don't just review
Security teams that only operate as gatekeepers don't scale, and the work isn't very interesting either. I'd rather ship a framework that makes the right thing easy than write a policy document telling people not to do the wrong thing. Most of what my team produces is code, not slide decks.
Assume the model can be manipulated
Prompt injection is the primary novel attack vector against LLMs and I don't think it's solvable. Every layer of the stack should assume the model's intent can be steered by an attacker. That assumption changes the design — capability boundaries, tool interface design, and just-in-time access all become non-optional.
Contain blast radius
Autonomous agents will do something unexpected. The question is what happens when they do. If I know exactly what an agent can touch and how to revoke it cleanly, I can hand off real work without losing sleep. Sandboxes, scoped credentials, and revocable tokens do more for trust than guardrails the model can talk its way around.
Raise the floor, don't slow the team
Secure-by-default tooling earns its keep when it makes the easy path the safe path. I optimize for "engineer ships AI feature without thinking about security" rather than "engineer fills out a security review form." The win is when the floor on a feature shipped at midnight is good enough that nobody has to lose sleep over it.
Featured Projects
MCP OAuth Framework
productionAn OAuth 2.0 framework for protecting MCP servers. Ships as three pip-installable packages: auth server, resource server, and a runnable example.
- Authorization server with PKCE, dynamic client registration, and RFC 6749 errors
- Resource server with RFC 7662 introspection and SSRF protection
TaskManager
productionA task manager built around a real OAuth 2.0 auth server. Includes a Python SDK and MCP server, so my AI agents can manage tasks too.
- Full OAuth 2.0 authorization server with PKCE support
- Security testing suite with Vitest
SMS Communications Suite
productionSend and receive SMS through GSM modems. Includes CLI tools and libraries in both Go and Python.
- Cross-platform GSM modem interface (Go + Python)
- Interactive CLI chat interface
ReMarkable Research Toolkit
productionTools for managing research papers on reMarkable tablets. Uses AI to classify and sort them automatically.
- AI-powered research paper classification
- Zero-config rmapi binary management
Recent Appearances
Real lessons from building specialized agents on shared infrastructure. Covers capability bounding, prompt injection detection, memory isolation, and OAuth device flow.
LLMs Will Never Be Fully Secure
podcastA discussion on malicious MCP servers and common AI security mistakes. Plus why prompt injection sticks around and how to deploy AI safely.
A security audit of MCP servers and their OAuth setups. 90% of the bugs are old problems. AI agents just amplify them.
A three-layer framework for catching LLM security mistakes before they reach production.
Let's Connect
Interested in AI security, collaboration, or speaking? I'd like to hear from you.
More About Me