I build ML/AI that transforms security operations

This started as a simple way to help leadership visualize operations — ticket counts, open, closed, pending, SLA data. Flat. It wasn't until Columbia's IWIK framing — start from the decision, not the data — that a different question surfaced: not what data do we have, but what actually needs to be known. On a flat team with no dedicated platform group, answering that became the job.

I turned that reframe into an enrichment pipeline: semantic embeddings and clustering that give flat ticket data the threat-framework context it never had, mapped to MITRE ATT&CK. On top of that, a GenAI summarization layer — deterministic status fields, human review guardrails — cut incident reporting from multi-day manual workflows to minutes, without cutting corners on rigor.

Then I opened it up: a natural-language interface on Model Context Protocol so any peer, manager, or exec can ask a scoped, audit-logged question in plain language instead of waiting on a hand-built report. I'm extending that same foundation into orchestration now, piloting automated incident triage that other security teams can build on.

All of it sits on top of live incident response work — leading investigations end-to-end, coordinating with engineering, legal, and product. The through-line is the same one Columbia gave me: start from the decision, work backward to the data. A dashboard nobody checks is just noise with better formatting.

Stack: Python, scikit-learn, SageMaker, AWS Lambda, S3, QuickSight, Terraform, BERT embeddings, MCP

When an insider-threat incident at another company hit the news, we ran a tabletop: if we faced the same thing, what would our response capability actually look like? The honest answer was that we could probably identify a bad actor — eventually — but getting there meant untangling weeks of legal and privacy process first. I pitched a rapid prototype for an insider threat program to leadership. Even working through that same red tape early on, it went well enough that leadership told me to build out the team and grow it.

The program scaled across five business units — Ring, Blink, Amazon Key, Sidewalk, and eero — around a threat-narrative framework: for each service, I work with the team that owns it to map what it does, how a threat could actually materialize, who the realistic adversaries are, and whether execs are prioritizing that risk. Those narratives drove 50+ bespoke risk indicators, tailored to each team rather than copy-pasted across all of them — so when an indicator fired, we knew exactly what it meant to that builder team and what it implied for the business, instead of it being just another alert lost in the noise.

Embedding in the AppSec intake process meant catching insider-risk gaps in the planning conversation, before a service shipped — often leading builder teams to refactor or add preventative controls for day one instead of bolting them on after an incident. That work drove org-wide adoption of two-person authorization for access to critical customer data, and thin-client endpoint enrollment for all customer service agents, first- and third-party.

To make readiness measurable, I built an Insider Threat Posture Matrix — a scalable way to score a business unit's security capability and gaps. The same narratives and indicators are now informing how Customer Service, Loss Prevention, and Fraud think about their own insider risk. A threat you can name in plain language is a threat a builder team can design around before it becomes an incident.

I joined Ring and was pulled out of a team meeting within my first hour on the job — an active security event, all hands on deck. What I found was a giant Slack thread, too many service owners in the room, and no real structure: every step lived in a coworker's head. We didn't even have a clear map of who owned which service or who was on-call. My first task at Ring was building the Incident Response Program from scratch, on the NIST framework.

That structure got tested fast. Account-takeover incidents were escalating into swatting — real danger at a customer's home, not an abstract severity rating. Our partnership with Customer Service made the first signal: CS started fielding complaints and engaged Incident Response quickly, and within 20 minutes of that first escalation it was clear this was an ATO. The tabletops paid off — having the right runbooks in place meant we already knew the right points of contact, which cut response time instead of costing it.

The open question that came out of it was how to measure containment when bad actors keep shifting tactics and the indicators of compromise change under you. That pushed a broader defense-in-depth conversation with stakeholders — including investment in web application firewalls — so containment wasn't just about closing one account, but raising the cost of the next attempt.

From there, I formalized what worked: automated SOAR pipelines for threat response, and cutting AWS CloudWatch log onboarding from 3–4 weeks to roughly 30 minutes through reusable patterns and automation. The outcome was IR that scaled — structured workflows that compressed manual investigation tasks from days to minutes, so the team could grow without growing linearly.

This is where I set my foundation: learning how systems break at scale, and how people actually use them. Supporting global IT operations for 130K+ employees and optimizing cloud infrastructure taught me reliability, usability, and distributed-systems thinking — not just fixing individual hosts.

I built a data analytics platform for cloud infrastructure optimization: my first real lesson in turning messy, incomplete operational data into actionable insight. Incident response and security don't happen in a vacuum — they run on top of complex, real-world infrastructure, and understanding that infrastructure is where effective security engineering starts.