Boost CEO: AppSec needs to get back in the room

Developer drift & disaggregation

Let’s say a developer types a quick prompt into Cursor. The AI agent fetches a specific helper library from npm to get the job done, then writes it to disk. The package’s post-install script executes, reads the local .env  file, and ships an AWS key to a server they don’t own.

The ability to move around and enjoy system and platform freedom is great, apart from when it means the company has just become the next breach victim.

In these scenarios, the expensive, high-maintenance AppSec stack saw absolutely nothing.

According to Zaid Al Hamami, founder and CEO of Boost Security, an organisation’s Static Application Security Testing (SAST) scanner, SCA tools, and rigid pipeline guardrails are all sitting around waiting for a pull request that hasn’t happened yet.

The meaningful engineering decisions (like package selection, network connections, and code generation) are increasingly made autonomously on localhost (a network term meaning “this computer” – the loopback IP address)  – and so this means that the pipeline has essentially been locked out of the room where the actual work happens,”

EDR is out of focus

“When I bring this up with security teams, the immediate reaction is usually, ‘No problem, doesn’t my EDR catch this?’ EDR isn’t blind to what’s happening, but it is solving a different problem. To keep developers from rioting, security teams almost always “de-tune” EDR on dev boxes. Allowing that leniency keeps legitimate work flowing without impeding development, but it creates deliberate blind spots exactly where the modern AI toolchain operates,” said Al Hamami.

Even if  EDR wasn’t de-tuned, there is a massive time gap. When a fresh piece of open source malware drops (like we saw during the active shai-hulud worm campaigns) the EDR won’t flag it instantly. It takes hours or even days for that telemetry to be queried, analyzed  and recognized as a definitive attack pattern.

But no team has days.

“By the time the EDR catches up, or a pipeline scanner finally flags a malicious import in a pull request, you’re into ‘incident response and postmortem’ territory, well beyond the reach of AppSec. The actual damage occurred the millisecond that package hit the developer’s local disk,” said said Al Hamami.

The work has already moved

If we look at what’s happening on developer laptops right now. They used to just be for code writing. Now those same laptops have MCP servers forming uninventoried connections to local data, or context windows happily slurping up hardcoded SSH keys and shipping them to unvetted third-party models. Hallucinated packages execute locally before anyone has even glanced at the code.

None of this touches a centralised repository.

“It’s a total nonstarter to ban AI agents or try to throttle developer velocity. Engineering has already moved to this new compute paradigm, and the productivity gains are too massive to ignore. The answer is simply that our security controls have to follow the work. We have to instrument the developer endpoint itself,” said Al Hamami.

Visibility comes before control

Al Hamami: When a developer’s machine gets popped, the goal is to know instantaneously which specific credentials, tokens and repositories that developer had exposed on that exact machine at that exact moment.

The Boost CEO says that getting back in the room starts with real-time visibility at the exact layer where the agent operates. Teams need an AI Bill of Materials (AI BOM): an inventory of exactly which agents, extensions, and MCP servers are running across the fleet, including the ones developers installed themselves yesterday.

From there, they can actually start governing the workflow. They can identify classified malware in the moment, intercepting malicious downloads the instant they hit the machine, long before a post-install script fires and well before an EDR recognises a pattern.

Then there’s the context problem.

“AI agents need context to be useful, but they don’t need your production secrets. If an agent is about to send an API key or a credential out to a third-party model, the security layer needs to mask it in-flight, right at the perimeter of the workspace. The developer gets to keep working naturally, but the secrets never leave the machine,” said Al Hamami.

Security back in the room?

But the reality here is that compromises will (obviously) still happen.

Al Hamami argues that the response has to evolve. He says that when a developer’s machine does get popped, the goal is to know instantaneously which specific credentials, tokens, and repositories that developer had exposed on that exact machine at that exact moment.

When we know the blast radius, we can rotate what matters before the attacker has time to pivot.

For the last decade, the suggestion here is that AppSec has built an incredibly sophisticated fortress around the developer’s commit. But the factory floor just moved. Security needs the right tooling to get back inside the room where the code is actually being made.