I'm an Infrastructure Security Engineer at Dropbox, where I lead a team working on AI agent security, LLM development tooling, and production AI systems.
I've been working at the intersection of security and automation for most of my career, even when I didn't have a name for it yet. After finishing my MS in computer science with a network security focus, I spent a couple of years trying to build security tooling with friends as a startup. The company didn't go anywhere, but the instinct to build tools rather than just operate them stuck with me. I moved to American Airlines to manage their WAF, then got pulled to Facebook where I investigated extensions and apps that were scraping Facebook products. That work naturally led to building automation frameworks to scale the investigations, and it gave me my first real taste of the problem I'm still working on: how do you systematically deal with software that acts autonomously and doesn't play by your rules? Dropbox recruited me from there, and the thread has continued.
What I Do at Dropbox
I lead a team of four. The short version: we make sure Dropbox's infrastructure and AI systems don't get owned.
- AI agent security - sandboxing, permission models, runtime monitoring for autonomous agents
- LLM security tooling - internal tools that help engineers ship AI features without introducing prompt injection, data leakage, or model abuse
- OAuth and identity - token lifecycle, least-privilege access, the boring but load-bearing stuff
- Security strategy - roadmap, threat modeling, working across teams
What I'm Interested In
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 be comfortable shipping without review. My main interest is secure-by-default development: making LLM-generated code more reliable from the moment it's written, not just after a human catches the 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, but the honest reality is that we can't trust them the way we'd like to. I think a lot about sandboxing, permission models, and just-in-time controls. Not to prevent agents from being useful, but so that when something goes wrong (and it will), the blast radius is contained. If I know exactly what an agent can do, I can delegate to it without losing sleep.
It gets harder when agents reach outside their sandbox. MCP and similar tool-use protocols are powerful, but they create a real design challenge: how do you build tool interfaces that an LLM can't circumvent in the name of being "helpful"? The security properties need to be baked into the tool itself, not dependent on the model behaving as intended. And when an agent acts on your behalf across services, questions like "who authorized what" and "how do I revoke it cleanly" become infrastructure problems, not theoretical ones.
Prompt injection runs through all of this. It's the primary novel attack vector against LLMs, and 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: building the tools and frameworks that let us say "yes" with confidence.
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.