AI didn’t replace our Security Team, it multiplied it

Webflow's security engineers built AI into triage and post-incident work. One change alone saved 504 hours in a single quarter.

AI didn’t replace our Security Team, it multiplied it

Andy Gombar
Staff Detection and response Engineer
View author profile
Andy Gombar
Staff Detection and response Engineer
View author profile
Table of contents

Mature security used to mean a SOC: analysts on shift, watching a wall of monitors, waiting for an alert to trigger. That's the model. Webflow runs detection and response without it.

For years, the assumption in security has been straightforward: mature detection and response programs required a SOC (Security Operations Center). A team of analysts looking at a wall of monitors waiting for an alert to trigger.

That model made sense when the only way to scale human judgment was to hire more humans.

The Honest Version of the AI in the SOC

The AI in security conversation is mostly vendor noise right now. Every tool promises to fix one silo of the SOC. Triage. Enrichment. Threat intel. Buy enough of them and you've just rebuilt the same fragmented stack with an AI badge on each piece.

What nobody is talking about loudly enough is this: you don't have to buy your way to AI-assisted security. A small, technical, and motivated team can build these capabilities internally, with tighter integration, better context, and far more control than any vendor product will give you.

At Webflow, we've spent the last year integrating AI into our detection and response workflows. Not as a pilot. Not as a demo. In production, actively refined, and still evolving. And the most important thing we've learned is this:

AI didn't change what good security looks like. It changed how much one team can do.

What We Actually Built

Webflow's security detection and response program is engineer-led. There's no SOC. There are no dedicated analysts rotating through shifts. There's a small team of security engineers responsible for the full lifecycle, from writing and testing detections, responding to incidents and improving the system over time. For a long time this meant ruthless prioritization, because you can't possibly investigate everything. You make tradeoffs.

AI shifted those tradeoffs in two concrete ways.

1. Triage That Doesn't Start From Zero

Every alert used to begin the same way: open the ticket, pull the context, check asset ownership, correlate recent activity, make a preliminary severity call. The work isn't hard, but its time consuming. Logging into multiple platforms to validate logs across multiple systems before any real investigation even begins.

Honestly, AI forced our hand here. When we saw a 200% increase in detections in a single quarter, it became clear that the old model, every alert starting from zero, every triage done manually, wasn't going to hold. We had to rethink the workflow, not just add capacity.

We now use AI to do the assembly work before an engineer ever looks at an alert. By the time a human is involved, the ticket already has enriched context, relevant historical signals, and a preliminary severity assessment. And for alerts where we have high confidence as a false positive, we've built auto-close mechanisms that handle resolution without human intervention entirely. That's not a shortcut. It's a deliberate architectural decision built on top of months of tuning and validation. We know exactly which alert patterns meet the bar for auto-close, and we review that criteria regularly as our environment changes. These small changes saved our team 504 hours of time over a single quarter. 

The engineer still makes every judgment call that matters. The AI handles the setup, and takes the clear false positives off the board entirely.

What we've seen in practice: faster triage, less context-switching fatigue, and higher-quality investigations because engineers are starting from a more complete picture rather than building it from scratch under pressure.

2. LLMs as an Investigation Partner

The harder problem is the ambiguous investigation, the kind where signals need to be stitched together across identity, endpoint, and application layers with no playbook that cleanly applies. Regardless of experience, often responders are left thinking ‘Where do I do next?”.

This is where we've been experimenting with LLMs most carefully. Not to make decisions, but to reduce cognitive load during complex triage: summarizing raw log volumes, surfacing similar past incidents and their associated playbooks, suggesting next steps, and drafting initial timelines that an engineer then validates and extends. The human stays in the loop at every meaningful decision point. That's not a limitation we're working around. It's a design principle. AI surfaces, organizes, and suggests. Engineers validate, decide, and act. The moment that boundary blurs is the moment you introduce risk that's hard to audit and harder to explain after the fact.

We're deliberate about where we trust AI output and where we verify it independently. That trust is earned incrementally, the same way we earn trust in any new detection logic before we let it run unsupervised.

3. AI in the Post-Incident Process

One of the most underrated applications of AI in security isn't in the detection or response phase at all. It's in what happens after an incident closes.

Post-incident analysis is one of those processes that everyone agrees is valuable and almost everyone fails to invest in. When you've just spent hours or days in response mode, sitting down to write a thorough post-incident analysis feels like the last thing you have energy for. The result is usually documentation that's thinner than it should be, action items that don't get tracked, and lessons that don't make it back into the playbooks.

We've started using AI to change that.

After an incident closes, we feed AI the full body of evidence from the response: every message from the incident channel, any meeting transcripts, notes, timeline documents, and relevant artifacts. The AI then does the synthesis work that used to take hours:

  • Reviewing all communications and documents to reconstruct a complete incident timeline.
  • Drafting the post-incident analysis, capturing what happened, what we got right, what we missed, and where we got lucky.
  • Generating action items with enough context that they're actually actionable, not just vague reminders.
  • Updating or creating playbooks based on what the incident revealed, filling gaps, correcting assumptions, and capturing the edge cases that only show up in real incidents.

It's easy to write a post-incident review that focuses on what went wrong and what went right. The harder and more valuable thing is capturing the lucky breaks, the things that went well not because of the system but in spite of it. Those are often where the most important improvements hide. AI is surprisingly good at surfacing them when it has full context of the incident communications.

The result is post-incident documentation that's more complete, produced faster, and actually feeds back into the detection and response system rather than sitting in a folder somewhere. Every incident produces a concrete output: an updated playbook, a flagged gap, a proposed detection rule. AI does the legwork. Engineers do the validation and close the loop. The difference is that nothing gets lost in the exhaustion after a hard incident.

The Part Most AI Security Content Skips

Here's what doesn't get said enough: AI-assisted response is only as good as the foundation underneath it.

Before we could get value from AI triage, we needed:

  • Clean, reliable data pipelines feeding our SIEM, and not just data volume, but properly formatted and normalized data that AI can actually reason against meaningfully.
  • A well-maintained asset inventory so enrichment is accurate.
  • Detection logic tuned tightly enough that AI isn't just processing noise faster.
  • Documented playbooks and incident history for LLMs to reason against.

If those things aren't in place, AI doesn't solve the problem. It scales it. Noisy detections become noisier. Stale context gets surfaced confidently. False positives get triaged more efficiently, straight into wasted engineering time.

The teams we've seen struggle with AI in security aren't failing because they chose the wrong model. They're failing because they're trying to use AI to compensate for foundational gaps that AI can't fill.

What "Model-Agnostic" Actually Means for Us

We're deliberately not locked into a single AI provider. The tooling in this space is evolving too fast to make that bet, and the underlying capability matters more than the brand.

What we've found is that the right question isn't "which model?" It's "where does AI judgment add value, and where does it need a human check?" That question has to be answered per use case, per risk level, and honestly, per incident type.

Some alerts are good candidates for AI-assisted auto-triage. Others, anything touching privileged access, customer data, or potential breach scenarios, get human eyes first, with AI as a supporting layer rather than a lead one. That's a deliberate architectural choice, not a gap we're planning to close.

What a Small Team Can Actually Do Now

Running security for a scaling company without a SOC used to mean accepting a ceiling on how much you could cover. You'd tune detections to reduce volume, automate the obvious stuff, and triage the rest by priority.

That ceiling has moved. Not because AI is magic, but because AI handles the repeatable cognitive work well enough that engineers can spend more of their time on the judgment-intensive work that actually requires them.

Faster triage. Better investigation quality. Less fatigue on high-volume alert days. We're still measuring the long-term impact carefully, but the directional signal is clear.

A small, well-structured security team with AI integrated into every loop of the incident response lifecycle allows us to operate at a level that would have required significantly more headcount two or three years ago. That's not a vendor pitch. It's what we're seeing in practice.

The Takeaway

You don't need a SOC. You need a system, one with clean data, tight detections, documented processes, and feedback loops that make it smarter over time. AI doesn't replace that system, It allows a small team of engineers who trust each other to move at the speed of the business without needing to scale headcount to do it. Build the foundation first. Understand your threat landscape before you automate. And when you do bring AI into the loop, be honest about where it earns trust and where it still needs a human check.

That's the version of AI-assisted security that actually works.


Last Updated
July 17, 2026
Category

Related articles

Audit trails are a feature, not a compliance tax
Audit trails are a feature, not a compliance tax

Audit trails are a feature, not a compliance tax

Audit trails are a feature, not a compliance tax

Security
By
Mohit Bansal
,
,
Read article

verifone logomonday.com logospotify logoted logogreenhouse logoclear logocheckout.com logosoundcloud logoreddit logothe new york times logoideo logoupwork logodiscord logo
verifone logomonday.com logospotify logoted logogreenhouse logoclear logocheckout.com logosoundcloud logoreddit logothe new york times logoideo logoupwork logodiscord logo

Get started for free

Try Webflow for as long as you like with our free Starter plan. Purchase a paid Site plan to publish, host, and unlock additional features.

Get started — it’s free
Watch demo

Try Webflow for as long as you like with our free Starter plan. Purchase a paid Site plan to publish, host, and unlock additional features.