I'm an Infrastructure Security Engineer at Dropbox. Since 2022 I've led a team working on AI agent security, LLM development tooling, and production AI systems.
Background#
I've worked at the intersection of security and automation for most of my career, even when I didn't have a name for it yet.
After an MS in computer science with a network security focus, I spent a couple of years on small consulting projects and personal infrastructure work. That repetition taught me how much of security in practice is glue code, log plumbing, and quietly enforced invariants.
I joined American Airlines to manage their WAF. That's where I learned what defensive infrastructure at scale actually looks like: the noise floor, the political cost of false positives, and how thin the line is between a useful rule and one silently filtering traffic nobody reviews anymore.
Facebook recruited me next to investigate extensions and apps scraping their products. It started as case-by-case triage. The volume forced the work to automate. I ended up building investigation frameworks that let a small team reason about behavior across millions of accounts.
That period gave me my first real taste of the question I'm still working on: how do you systematically deal with software that acts autonomously and doesn't play by your rules? Dropbox pulled me in next, and that question still shapes the work. The autonomous software has changed shape — it's LLMs and agents now, not browser extensions — but the underlying problem hasn't gone away.
Approach#
I use LLMs to write code every day. I'm not stopping. But I see the gap between what these tools produce and what I'd ship without review.
My main interest is secure-by-default development. The goal is to raise the floor on LLM-generated code from the moment it's written, not after a human catches mistakes. Not slowing things down. Raising the floor.
The same trust problem shows up with agents. I want to hand off as much work as possible to autonomous agents. The honest reality is we can't trust them the way we'd like to. So I think a lot about sandboxing, permission models, and just-in-time controls. Not to prevent agents from being useful. So that when something goes wrong, the blast radius is contained.
It gets harder when agents reach outside their sandbox. MCP and similar tool-use protocols are powerful. They also create a real design challenge: how do you build tool interfaces an LLM can't circumvent in the name of being "helpful"? The security properties need to live in the tool itself, not depend on the model behaving as intended.
Prompt injection runs through all of this. It's the primary novel attack vector against LLMs. I don't think it can ever be fully solved. That's exactly why every layer of the stack needs to assume the model's intent can be manipulated. Defense in depth isn't optional when your foundation is probabilistic.
I'm not interested in security as a way to say "no" to AI. I want the opposite: tools and frameworks that let us say "yes" with confidence.
Services#
I lead a team of four at Dropbox. The short version: we make sure Dropbox's infrastructure and AI systems don't get owned. My weeks split between writing code, reviewing designs, and arguing about threat models.
The team ships infrastructure other engineering teams depend on. Paved roads for new LLM features. Libraries for talking to model APIs safely. Sandboxing primitives that show up in agent products. We partner with feature teams from early design through launch and into incident response.
Areas I'd be useful on a project or panel:
- AI agent and LLM application security — threat modeling, sandboxing strategies, runtime controls, and incident-response patterns for production agent systems.
- Prompt-injection defense — direct, indirect, and tool-chained variants. Which defenses meaningfully reduce risk versus which only change the attack shape.
- MCP and tool-use protocols — designing tool interfaces and MCP servers that resist over-eager LLMs and hold up under adversarial input.
- OAuth, identity, and token lifecycle — least-privilege scoping, revocation, and the design choices that decide whether a leaked token is a near-miss or a breach.
- Defensive infrastructure at scale — WAF and edge tooling, automated investigation frameworks, and the unglamorous logging and audit plumbing that makes everything else possible.
- Security strategy and program design — roadmap work, threat modeling sessions, and embedding security review in product workflows without becoming the team of "no."
Outside of Work#
Outside the day job, I write here, contribute to open-source security tooling, and read a lot — security research, distributed systems, and the occasional novel for variety. I live in the Bay Area and stay active in the local security community. If you've read something here and want to push back, share a counterexample, or just trade notes, I'd rather hear it than not.
Get in Touch#
I'm active in the Bay Area security community and happy to talk over coffee. If you're working on AI security, want to collaborate on research, or just have questions, reach out.