Margin of Safety #58: Developer Workflow Security: Beyond the Endpoint Hype

Agentic Endpoint Security or Developer Workflow Security…?

Over the past few weeks, more than ten startups have emerged to claiming territory in a newly labeled security category. Palo Alto Networks labeled the space “Agentic Endpoint Security” as part of their $400M acquisition of Koi, a startup founded in 2024 that raised roughly $48M and exited in just about eighteen months.

That underlying customer problem is real, but we think Palo Alto’s category name is somewhat misleading: they’re calling it “Agentic Endpoint Security,” but the problem is developer workflows. More specifically, it’s the increasingly dynamic, AI-assisted process by which developers write and ship code. We think a better name for this category is ‘Developer Workflow Security’.

The Central Hypothesis

The core of our thesis is simple: developer workflows are rapidly changing with automation and AI coding tools. Historically these workflows were relatively static, and slower change with more meticulous human review meant less exposure — even though risks like dependency confusion and untrusted suppliers were always present. AI scrambles this. Coding agents now invoke complex tools, propose extensive dependency decisions, and generate high volumes of minimally reviewed code, stressing existing risks and creating new gaps that legacy tooling wasn’t built to fill.

Why the Old Model Breaks

Modern developer endpoints are the most diverse environments that many IT teams encounter. They have a complex mix of coding agents, open-source packages (and associated package managers), browser extensions, and Model Context Protocol (MCP) servers. In many companies, none of this software passes through IT or corporate procurement on its way into the environment.

This visibility gap persists through to usage, because Endpoint Detection and Response (EDR) tools were largely built to catch malicious activity inside compiled binaries using signatures and heuristics. This leaves them with blind spots for increasingly popular (and AI-forward) scripting languages like python or typescript, along with their associated package managers.

The AI Twist and the Shai-Hulud Worm

When developers delegate dependency choices to models, new attack vectors open – in particular, slopsquatting. This is when attackers identify commonly hallucinated packages in popular languages and then register the package themselves, converting what would have been a build or runtime error (no package found) into an attack on the developer environment. Even when humans are verifying an agentic proposal to use a package, the agent is definitionally proposing a plausible looking package name. Only vigilant engineers catch and prevent the attack.

Another vector emerges from the fact that agentic coding systems don’t pin versions — a practice that buys time for the community to audit new releases before widespread adoption. Attackers exploited this gap with the Shai-Hulud worm, using a small number of stolen FOSS credentials to compromise hundreds of npm packages, including some owned by CrowdStrike and Mistral, with subsequent waves hitting employee devices at SAP, OpenAI, and RedHat.

Four Ways to Defend

The market is currently testing solutions that address these problems at very different points:

• End-point level detect-and-enforce: Companies like Koi and Socket continuously scan the endpoint, enforcing policy to block unsafe components at the moment of install or during runtime. This is powerful but complex – after all, how do you know which data is being sent as legitimate stats collection versus as part of an attack? Modern AI can help with that reasoning, but it’ll take smart engineering to fully harden it.
• Clean-by-construction: Vendors like Chainguard and RapidFort focus on replacing standard packages and container images with hardened, minimal, known-good equivalents. This approach shrinks the attack surface rather than trying to police an unmanaged one, but has historically faced challenges keeping up with all of the packages an engineer (or agent) might want to use.
• Least-privilege identity: Dev environments and workflows evolved to run under the developer’s human identity, and agentic coding has bolted onto those primitives. The poor fit – agents inherit all the developer’s access and get logged under the same user – underpins many security problems. Identity-focused vendors are trying to close this, either re-engineering permission surfaces or by using protocols like MCP to inject additional permission semantics (with the caveat that many coding agents have the ability to bypass MCP with direct command line tool use).
• Agent-to-desktop containment: In addition to bolting onto pre-existing identity primitives, agentic coding is often running in desktop OSes that were designed for a single user experience. In practice though, the agent is a separate entity operating in the user’s space, and with access to a very user-centric filesystem that holds everything from SSH keys to browser cookies. We see players trying to both isolate agents through local sandboxes as well as move core pieces of the workflow to remote containers; the latter provides stronger security guarantees, but at the cost of increased tooling complexity and potentially latency.

Regardless of which avenue they’re pushing on, winners in the space will need to balance their ROI, figuring out how to prevent FOSS worms from taking hold without negatively impacting engineering velocities.

Moving Beyond the Endpoint

Limiting the category to the endpoint also obscures where this security layer must logically expand next: CI/CD pipelines and actions. Pipelines are an extension of the same developer workflow, and they are becoming just as dynamic and opaque to legacy enterprise tools. GitHub actions are already being weaponized as part of the attacks: they’re consistently surfacing as a preferred vector for TeamPCP and a propagation method for Shai-Hulud.

We have already spoken with at least one vendor in this space who explicitly considers GitHub Actions within their core scope. And as we envision an agentic coding future, the development process will only grow more expressive and extensible — more code in more places, and a continued expansion of the risk surface. Developer Workflow Security must naturally cover the end-to-end workflow to be fully effective.

Feature or Category?

The ultimate venture capital question is whether this remains an independent category or collapses into an incumbent feature set. Palo Alto Networks is already assembling a full stack, combining Koi for detection, Prisma AIRS for AI runtime protection, and CyberArk for identity and least-privilege management, and more. Their clear bet is that these layers will collapse into a single control plane.

The detect-and-enforce layer is the most crowded: incumbents already own endpoint agents and the distribution channels needed to bolt on basic package scanning. Standalone positions look more durable in the other buckets. Clean-by-construction creates switching costs once engineering teams embed hardened repositories into their core build processes. Desktop containment and least privilege identity address paradigms that binary-era EDR tools will find hardest to retrofit — that is where independent companies are most likely to persist.

For practitioners currently shipping autonomous agents into regulated or production environments, where are you focusing your defense today? Drop a comment or hit reply to share your perspective.

If you’re building in this space, we’d like to hear from you.

Feel free to reach out to jpark@forgepointcap.com and kshih@forgepointcap.com.

This blog is also published on Margin of Safety, Jimmy and Kathryn’s Substack, as they research the practical sides of security + AI so you don’t have to.