Applying AI Agents to Infra Security with Mohit Bansal

AI security triage can stall when every alert waits for a human. Mohit Bansal explains how Webflow cut supply chain triage from roughly six hours to six minutes. The conversation covers developer laptop inventories, exposed credentials in MCP configs and agent transcripts, and why agents need reliable infrastructure context. It also explores repository maturity gates, production patching gaps and AWS account boundaries that contain mistakes.

Summary

When the next critical vulnerability lands, every security team asks the same question: are we affected, and where? In one week this October that question arrived four times at once. There were two critical PHP vulnerabilities, a high-severity Node.js vulnerability and compromised CA certificates. If a human triages each of those by hand, the humans become the bottleneck, and attackers who now move faster than ever won’t wait for them. Mohit Bansal, Senior Manager of Security Engineering at Webflow, describes his team’s answer: AI in every step of the security workflow. Agents triage alerts and supply chain incidents, and the developer laptop gets checked as seriously as production. What holds it together is old-fashioned: an inventory the agent can query, an environment kept clean enough to defend, and accounts that contain whatever the agents get wrong.

Mohit leads infrastructure security, incident response, corporate security and vulnerability management at Webflow. That includes software supply chain defence and the work of letting everyone in the company use AI safely. Webflow started as a no-code website builder and is now used heavily by enterprises. By Mohit’s estimate it hosts roughly 1% of the world’s websites, “so that makes my task really difficult”. Before Webflow he spent close to six years at Okta in DevSecOps and application security engineering management, and before that he worked in security engineering at Walmart Labs. He writes and speaks about npm supply chain attacks and AI agent security, with talks at BSides Las Vegas, Blue Team Con 2026 and OWASP Bay Area.

Triage at Machine Speed, With a Human at the Threshold

What should an AI agent do with a security alert before a human sees it?

It should gather the context a human would have gone looking for, decide with a stated level of confidence whether the alert is real, and pull in a person only when that confidence says it’s worth their time.

Take a week with ten serious incidents in it. Traditional incident response, with someone manually triaging each one and calling it out, can’t run ten in parallel. Mohit’s framing is blunt: “The humans are the roadblock for all the alerts.” So the goal isn’t to remove people. It’s to stop them being the step every alert waits on.

At Webflow, alerts from the cloud security posture management (CSPM) and cloud-native application protection (CNAPP) tools feed a security orchestration, automation and response (SOAR) pipeline, where AI models do the first pass. Mohit picked an ordinary example on purpose. Someone logs in to AWS from an IP address in a country where Webflow doesn’t operate. Baseline controls should already prevent most of this: AWS Control Tower guardrails, SSO-only access. When something gets past them anyway, an alert fires. The agent then fetches context from internal systems such as Slack and the HR system. Is this an employee on PTO who travelled there? In Mohit’s example that points to a false positive, and no human had to do the digging.

We’d treat travel as supporting context, not proof. It explains the location, but it doesn’t show that the employee started the session. Before the agent dismisses the alert, it should also check the authentication and session evidence: how the login was authenticated, and whether the session’s activity matches what that employee normally does.

The design question is where the confidence threshold sits and who sets it. Mohit’s goal is stated plainly: “We don’t want the humans to be the roadblock, we want the AI agent to triage them with a certain level of confidence.” His SecureWorld piece on decision latency, co-written with Tushar Badlani, describes the careful version. The triage agent starts in shadow mode. It gets autonomy only for specific alert types, once its accuracy on that type crosses a threshold checked against the team’s own ground truth. Reversible actions go to automation first, and irreversible ones stay with people. It’s the same staged path we argued for in episode #19: assisted first, unattended later.

Supply Chain Attacks Land on Laptops First

The login example is routine. Supply chain incidents were the case that forced real automation.

Where should you look when a malicious npm package is published?

In production, in GitHub, and on every developer laptop. The laptops are the place most teams forget.

Early in 2026 Webflow saw about three supply chain incidents a week, and triage was eating the team’s time. The automated response checks the CNAPP tool for whether the package is deployed anywhere and scans GitHub for references. Then it checks the endpoints, which manual triage had shown nobody in the industry was really covering. Endpoint agents now give the team a view of which packages are installed on every machine, no more than five minutes old.

The reasoning is about where packages actually live. Developers download far more than they ship. They test things, automate things and try things out. If a package is in production, there’s a good chance twice as many packages sit on developer laptops. That makes the laptop a large threat surface that a CNAPP tool never sees.

Inventory is only half of it. The other half is not trusting the registry. When a package is published to npm or PyPI, AI agents analyse it and decide with a stated confidence whether it’s malicious. Then that verdict is checked against the inventory. Together those took Webflow’s supply chain triage from roughly six hours to roughly six minutes.

That speed comes from data most companies already collect. Endpoint management and device scanning tools already sit on every developer machine. What’s new is reading their output as a supply chain signal instead of a compliance report.

Your MCP Config Is a Credential Store

If laptops hold the packages, they also hold the keys, and agents have made that worse.

Where do AI coding agents leave credentials on a developer’s machine?

In plain text, in MCP configuration files, .env files and agent transcripts.

Credential stealers used to go after SSH keys. Now there’s something better on the disk. Developers paste credentials into coding agents without much thought, and those credentials end up in transcript files. We covered that in episode #18 and again in episode #23. Mohit adds the config side. To make life simpler for agents, people store secrets in config files and environment files, unencrypted. “If you look at the MCP config on your laptop, you would be shocked.”

The usual defence is that the ecosystem taught people to do it. Most MCP server READMEs say “put your API key here as an environment variable” and stop. That’s fair, but you can still do better than the README. Wrap the server’s launch command in your password manager’s CLI, so the key gets read at start time and handed to the process instead of sitting in a file. With 1Password, op run does this:

{
  "mcpServers": {
    "example": {
      "command": "op",
      "args": ["run", "--env-file=./mcp.env", "--", "npx", "-y", "example-mcp-server"]
    }
  }
}

# mcp.env holds references, not secrets
EXAMPLE_API_KEY=op://dev/example-mcp/api_key

That isn’t a sealed box. 1Password’s own docs warn that other processes run by the same user may be able to read those environment variables, and anyone with sudo can read them too. It’s still better than plain text that every infostealer knows where to find. Any password manager with a CLI works the same way.

Mohit’s team is exploring the same direction: pulling secrets from password managers, AWS or GCP so that agents can use them without a stream of OTPs and fingerprint prompts. He expects this to be “a tough problem to solve”, because the more friction you add, the more developers route around it.

Inventory Is the First Thing an Agent Needs

Secrets are one thing an agent shouldn’t hold. An inventory is the thing it can’t work without.

If you’re a 40-developer team facing a critical CVE tomorrow, where do you start?

Start by finding out what you actually run and which versions it’s on. Then patch, ideally at the base image, with automation that rebuilds and redeploys everything built on it.

We gave Mohit the consultant’s version of the problem: a 40-developer company that’s modern in CI/CD and light on AI, facing something like this week’s Node.js release. His first move is to ask whether any tooling can say what lives in the environment. At that size, shadow IT and shadow AI are common, because teams move fast and centralise little.

Teams that plan ahead have adopted base container patching, so a vendor fix gets applied once, at the base. That isn’t the end of it. Updating a base image doesn’t change the images built from it or the containers already running, and Docker’s own guidance is to rebuild images often. The “patch once” part only works if automation then rebuilds or rebases every affected application image, tests it and redeploys it. Teams with minimal visibility can now get a long way with an agent, because scanning has become a commodity and a capable model can sweep every environment for the vulnerable Node.js version.

That sweep needs one of two things. Either the agent has an inventory to query, or it has credentials for every place and rebuilds the inventory each time you ask. The second option is slow, burns tokens, and misses things. When this week’s CVE landed, we pointed an agent at B.O.R.I.S and asked: give me all the Node.js containers across all accounts. Then it checked the code and the live configuration for exposure. That process isn’t fully automated yet. Still, the question became a query against an inventory that already existed, not a rebuild of one. That rebuild is the orientation cost we described in episode #17.

Threat Intelligence Can’t Wait for the CVE

An inventory tells you what you run. You still have to hear about the threat in time.

Is watching CVE feeds enough to know when you’re exposed?

Not on its own. Exploitation can start before public disclosure.

Look at the week we recorded in. On 21 October PHP shipped fixes for PHP2Shell, two critical unauthenticated remote code execution bugs, and said updating is the only safe choice. Node.js shipped its own security release the same day, including a high-severity out-of-bounds write in its bundled Brotli decoder. Browsers had already started blocking compromised eMudhra intermediate certificates. At Webflow, some of these didn’t apply because the affected technology wasn’t in use. Others hit internal systems but not customer-facing ones. All of them still needed people to drop what they were doing and triage.

Mohit’s warning: “the vulnerability disclosure is faster than the CVE disclosure nowadays.” PHP2Shell is one instance. Amazon’s threat intelligence team found an exploitation attempt in its MadPot honeypot telemetry dated 17 October, four days before public disclosure. Proof-of-concept exploits then appeared hours before the embargo lifted. A team waiting on the CVE feed was already behind.

The informal version of our own process: someone sees something trending on X, it looks big, and we ask whether we’re affected. That’s not as silly as it sounds. Something hot everywhere on the internet is very likely being targeted. But parsing X yourself is a bad job. What’s missing is threat intelligence an agent can consume and that pushes you the notification, ideally over MCP. Some pieces exist. Search engines built for agents, such as Kagi, work better in an investigation flow than plain Google. Mohit points to OpenSourceMalware, a community-reviewed database of malicious packages, repositories and domains with a free feed and API. He is clear that it is one vendor and that he doesn’t know how broad its investigations are. He expects this space to evolve.

The practical setup is a pipeline: an early signal in, your inventory as the filter, and an agent deciding whether a human needs to look. Each piece exists today. The joins between them mostly don’t.

Shadow Infra Just Needs a Prompt

Matching a threat against your inventory works only when the inventory is the real attack surface. Sprawl breaks that.

Why does AI-assisted development grow your attack surface even when nothing ships?

Because proofs of concept are now nearly free to create, and they rarely get deleted.

“shadow IT needs a credit card, but shadow infra basically, just needs a prompt. So if you think about it, a developer can just write a prompt on a Friday, create a POC, present it on Monday.”Mohit Bansal

The POC doesn’t go well, and the resources stay. They never get patched. The cost repeats at every layer. There’s a GitHub repository, because it’s code. There are CI minutes. There’s CNAPP coverage, because security tooling usually bills per asset scanned.

Abandoned repositories make it worse. Each one has a pom.xml, a requirements.txt or a go.mod, so Dependabot and the scanners keep filing CVEs against code nobody runs. With enough microservices and staff turnover, many repos end up with no owner, and someone in infrastructure or security keeps patching them without knowing whether they’re live.

Then there’s the paradox we like to joke about. Security tooling scans main, and Dependabot scans the default branch. If production ships from a release branch, you’re very secure in development. Even without release branches, patches often reach the dev environment automatically and then stall there. A patched main doesn’t mean a patched production.

Cleanup is the expensive part. Creating is easy and deleting is hard. Before Mohit deletes a stale resource in GitHub, AWS or GCP, he has ten questions to ask and people to chase. Time-to-live helps where it exists, but most resources have no such concept.

Years ago we wrote a Lambda function that swept accounts for anything not tagged as managed by Terraform. On the first pass it tagged the resource and posted to Slack: I found this, I’ll delete it next time, save it if you need it. On the next pass it deleted. A script only checks what you thought to describe. An agent is less reliable, but it can pivot and look at places you didn’t write down. Combining them looks promising: the script does the deterministic sweep, and the agent explores around its edges.

Repository Labels as a Production Gate

Sprawl is hard to prevent. You can at least decide which part of it security has to care about.

How do you stop scanners drowning in experimental repos without letting experiments reach production?

Label repositories by maturity. Let production vulnerability remediation skip the experimental ones, keep secret and malicious-package checks running on every repository, and make the pipeline refuse to deploy anything that hasn’t graduated.

We’ve considered this pattern for consulting clients. A new repository would get an incubating label. Someone is playing around, so its vulnerability findings don’t need to land in the production remediation queue. That exemption has limits. Given the laptop threat model above, secret scanning and malicious-package checks should keep running on incubating repos. An experimental dependency can execute on a developer laptop or a CI runner long before anything ships, for example through npm install scripts. Pipeline files would be deployed into the repository automatically, so it can mature. If the project proves useful and the developer wants production, they would go through a short review with the people responsible, SRE and security, and the label would become graduated. The release pipeline would check the label and refuse to deploy anything without it.

That would give two benefits at once. Vulnerability remediation would focus on what actually runs, and the incubating long tail would stop generating patch noise. The gate would also stop the other failure, where a promising POC goes straight to production with no testing and no security analysis. Mohit’s view is that this is the hygiene production needs: anything that goes into production has to pass through it, which is what gives you full coverage of production.

It isn’t free. It takes convention, discipline and some automation, and somebody has to own the review. As an industry we still need to work this out. Still, a label check in a pipeline is cheap compared with patching repositories nobody uses.

Contain the Agents You Deploy

The label gate is one form of containment. Agents need the rest.

What’s the minimum containment before you let AI agents loose on security tasks?

Separate accounts by blast radius, require IaC and tags in production, expire stale work, and log everything the agents do.

Mohit’s list starts with the basics. Production and development live in different AWS accounts, because the development side is where all the agent experiments happen. AWS’s multi-account whitepaper states the property you’re buying: production and non-production accounts stay isolated “unless you specifically enable communication.” POCs go in a developer account. Production is limited to people with specific access and gets stronger controls. Nothing goes in without IaC, and nothing goes in without a tag in the agreed format. Otherwise you get public S3 buckets created by hand. One caveat when you build this: AWS Organizations tag policies standardise tags but don’t evaluate untagged resources. Requiring a tag at creation is a separate control, typically a service control policy with an aws:RequestTag condition.

Two less obvious items stand out. First, automatically close stale pull requests after a defined period, and require fresh checks and review before merging revived work. Otherwise someone will review an old PR and merge it when they shouldn’t. If you automate this, note that closing a pull request and deleting its branch are separate steps. Second, separate accounts by role, not only by environment. Everyone is a builder now. When someone in marketing or sales wants to build something, they get their own AWS account with fewer permissions than developers have.

Then logging: every session, every tool call, so you can see what the agents did. Nikita Kabardin made the traceability case in episode #22.

The reason is simple. Agents are a sword that cuts both ways. If an agent holds real AWS keys, nothing stops it from posting them somewhere public, whether a malicious instruction told it to or it was simply misguided. Containment is what limits the damage when that happens. For AWS we’d go further than Mohit’s list: a multi-account strategy is a must-have, and there are many reasons not to put everything in one account.

What This Means for Teams

Attackers are getting faster, and the defence is to stop people being the step every alert queues behind. That works only on a base the agent can trust: an inventory it can query, an estate clean enough that the inventory means something, and accounts that limit what a wrong decision can reach.

Four things you can do this week:

• Check one developer laptop’s MCP config. Count the plaintext keys and move them behind op run or your password manager’s equivalent. Revoke or rotate any credential that has ended up in an agent transcript, then remove the plaintext copies from transcripts and prompt history.
• Add endpoints to your supply chain runbook. When the next malicious npm package lands, can you say within minutes which laptops installed it? If not, find out what your endpoint management tooling already collects.
• Find out which branch your scanners watch. If production ships from a release branch, compare its dependency versions with main today.
• Label five repositories incubating or graduated. Then add the label check to one release pipeline, so the gate exists before the next Friday-afternoon POC goes looking for production.

Common Questions, Answered

Resources

• Mohit Bansal, on LinkedIn and Sessionize: his talks and articles, including the Blue Team Con 2026 session on detecting and responding to npm supply chain intrusions. The Webflow security engineering case study covers install-time blocking of malicious packages and a reported reduction of more than 90% in container vulnerabilities across the fleet.
• Alert Fatigue Was the Old Problem. Decision Latency Is the New One (SecureWorld): the written version of the triage argument. It covers shadow mode, autonomy granted per alert type once accuracy crosses a threshold, and reversible actions automated before irreversible ones.
• Trusted by Default: The npm Attack Pattern Security Teams Miss (SC Media) and Why MCP Security Is About Permissions Overhaul (Webflow Blog): Mohit on supply chain trust and on MCP permissions, the two threads behind the laptop sections above.
• PHP security advisory, 21 October 2026 and Amazon threat intelligence on PHP2Shell exploitation before disclosure: the primary sources for PHP2Shell. PHP says updating is the only safe choice. Amazon dates an exploitation attempt four days before disclosure, which is why CVE feeds alone can come too late.
• Node.js October 2026 security releases and Mozilla, Google and Apple block compromised eMudhra CA certificates (BleepingComputer): the rest of the week’s incidents. The Node.js page gives the severity of each fix. Software with its own certificate store may keep trusting the affected eMudhra intermediates until it is updated.
• Load secrets into the environment with op run (1Password): the syntax for the MCP wrapper above, plus 1Password’s own warning that other processes run by the same user may be able to read the injected variables.
• OpenSourceMalware: a community-reviewed database of malicious packages, repositories and domains with a free feed and API. It’s one possible source for threat intelligence that agents can consume. Judge its coverage yourself, as Mohit suggests.
• Organizing Your AWS Environment Using Multiple Accounts (AWS) and AWS Organizations tag policies: the basis for account-level containment. Read the tag policy page before relying on it, because it states that untagged resources aren’t evaluated.