We're in a vulnerability apocalypse. With attackers running agents around the clock testing every weakness they can reach, new findings are arriving faster than teams can triage. Defenders need a force multiplier to meet the moment. There’s no question AI can find vulnerabilities. The harder questions are whether it consistently finds them across every application that matters to you, and whether the riskiest ones rise to the top so your team knows what to fix first.
Semgrep Agentic Workflows address many of the common pitfalls our AppSec customers face in building detection and remediation harnesses around frontier models: AI agents that go astray hunting in the wrong parts of the codebase, start from scratch every run, and ignore organizational guidelines.
Agentic Workflows leverage Semgrep’s Context Layer, a persistent understanding of your code architecture and of your organization. With the Context Layer, agents hit the ground running with deep code analysis Semgrep has already prepared, alongside the organizational knowledge you’ve built over time.
The Context Layer keeps what is expensive to rediscover and what isn’t in the code at all: a map of your code, your priorities, and your past decisions. Agents still read the code on every run, but they all start from the same context.
Finding All the Vulnerabilities That Matter
To get the best output from your model, you need to give it the best input. Agents tend to travel along the path of least resistance. When a framework wires up routes on your behalf, nothing in the code calls them directly, so an agent that just follows calls or greps for them can miss them entirely. To combat this, Semgrep runs discovery workflows with our agent-first program analysis tool, Mandoline so the Context Layer offers every run an accurate map to work from.
What your team knows | Where it lives in the Context Layer |
|---|
The architecture: services, entrypoints, where auth happens, what outbound requests exist | What we've discovered: code context from Semgrep's discovery workflows and Mandoline |
The requirements: threat models, security policies, architecture decisions | What you've documented: context documents |
The history: organizational conventions, accepted risks from past investigations | What you've told us: memories and triage notes |
When Agentic Workflows use data from the Context Layer, we see the same models find dramatically more real vulnerabilities. The chart below shows internal benchmarks where we test detection on open-source projects with XSS and SQL injection advisories published this year.
Same model, same projects. But with Agentic Workflows and the Context Layer, Opus 5.5 found 19 real SQL injections to Claude Code’s 7, and 34 XSS vulnerabilities to 5. Haiku 5.5 with context found more than Opus 5.5 without it on both.
Entrypoints and Recall: Every route, handler and API endpoint is a way in for an attacker. Most agents start by running grep and often follow the first path they find, leaving only a partial picture. One customer sent us 14 vulnerabilities that their LLM harness had missed. We dug into the logs and saw 9 of them sat behind endpoints the harness never discovered. Inventorying every endpoint up front lets our workflows ground the agent in the full attack surface.
New vulnerabilities in open-source code: Knowing where authorization happens also changes what an agent can recognize as serious vulnerabilities. Running against open-source projects, an experimental Semgrep Agentic Workflow used the Context Layer’s inventory of entrypoints and authorization checks to trace input across privilege boundaries, and surfaced previously unknown vulnerabilities, including a stored XSS in a widely used open-source media server. One of our Security Researchers reproduced each one, wrote a fix, and reported it to the maintainers. They’re now in coordinated disclosure, and we’ll publish technical details once the advisories are public.
Across vulnerability types. The gain isn’t limited to XSS. On SQL injection, the workflow with entrypoints found 19 real vulnerabilities to Claude Code’s 7. We saw a similar pattern with server-side request forgery (SSRF), where the workflow starts from the outbound calls the Context Layer has already mapped and traces each URL back to its source and found more true positives than a frontier model scanning on its own.
Surfacing the Risks That Matter Most
Detecting vulnerabilities is only half the battle. Agents need organization-specific conventions only your security team understands to do proper triage: which services are internet-facing, how your organization defines a critical finding, and which risks you've already accepted. Without that, agents burn tokens flagging the same intentional behavior.
The Context Layer reduces false positives by persisting what’s relevant. Memories record your team's decisions, such as "the support-admin role may read any account." Context docs like threat models and architecture docs tell workflows which systems and data matter most.
When one Semgrep customer added two memories about how their internal services handle requests, they were able to close 47% of their SSRF backlog. Every out-of-the-box Agentic Workflow now reads memories, so a decision you record once applies everywhere.
Why a Context Layer?
Not everything belongs in persistent context. Agents still read the code itself on every run. The Context Layer holds two kinds of things worth keeping: knowledge that’s expensive to rediscover, like a complete inventory of entrypoints and authorization checks across hundreds of repos, and knowledge that isn’t in the code at all, like accepted risks, threat models and why an endpoint is open on purpose. Keeping that in one shared place gives you three things a per-run approach can’t:
Consistency. Every workflow starts from the same map of your code and the same notes from your team. Results stop drifting with whichever path an agent happened to take.
Compounding. When you add a memory or a threat model, every workflow benefits at once, not just the one you were using. The same context can apply wherever code security happens: as code is generated, at PR time, and in scheduled jobs afterward.
Extensibility. Build your own flows on the Context Layer. Through Semgrep MCP the agent in your editor or terminal can use discovered code context and your team’s memories, and trigger Agentic Workflows as part of the process your team already runs.
The earlier you catch a vulnerability, the cheaper it is to fix. The Context Layer powers Guardian, CI, and Agentic Workflows to fix more risks in the early stages. When you learn from pentests or incidents, these can feed memory to the Context Layer for better prevention.
Join the Context Layer Private Beta
AI models will keep getting better. What makes them effective for AppSec is what surrounds them: a harness built for security work, a map of how your code actually connects, and the context only your organization knows. The Context Layer is in private beta, ask your account team about joining.
