Inside Vend’s product security team: A year of AI agents on our production systems

At Vend, we have thousands of code repositories, built and maintained by hundreds of developers across our marketplaces. Securing them has meant pairing automated security scanners with manual investigation. Emil Vaagland and his team wanted to find out whether an AI agent could carry out more of that investigative work.

Not simply scan some code and point out something suspicious, but follow a potential vulnerability across systems, inspect the relevant source code, understand where an application is running, query logs, test whether an attack actually works, and connect what it finds to the team responsible for fixing it.

From automating tasks to automating reasoning

Standard security scanners pick up static code patterns, but confirming a real risk requires manual work. An engineer usually has to trace how services interact, find the right repositories, verify authentication, check production settings, and test what an attacker could achieve. Emil sees a significant shift here.

“We used to automate with code. Now we automate with reasoning,” he says.

General-purpose AI models know standard vulnerability types, but they do not know Vend. They lack context on how our internal systems connect, where applications run, who owns them, or where logs sit. So the team gave Claude the skills to look all of that up itself.

Using skills, they teach the agent to navigate our infrastructure and retrieve data on source code, cloud settings, service ownership, network exposure and logs. A relatively simple question such as “Who owns this service?” might require one skill. A more complex investigation can involve several, with the agent deciding which ones it needs and chaining them together.

Following a vulnerability through the real system

One of Emil’s turning points came from a vulnerability that he had previously been unable to exploit. The initial code finding looked limited. Emil’s own attempt hadn't produced a working exploit, and early runs with Claude hit the same dead end.

With access to more of Vend’s internal context, however, Claude was able to investigate further. It traced the request through related applications, mapped the running services back to their source code, and found an authentication gap in a separate service.

The agent then started testing. The first requests failed. Claude read the load-balancer and application logs, adjusted the payload and tried again. Emil supplied authentication, valid test data and a nudge when the agent stopped too early. Eventually, it reached another user's data.

“That was my ‘LLMs are now really good’ moment,” Emil says.

Using agents to investigate real incidents

The team used the same approach during security incidents. In one case, they found a vulnerable deployment but initially believed it was protected by Appgate. They checked the Kubernetes ingress and cluster configuration, and requests through the normal route returned a 403. The patch therefore wasn't treated as urgent. 

A later security report revealed what the initial investigation had missed: a wildcard rule in the GCP load balancer provided another route to the application. The team had inspected Kubernetes, while the load-balancer configuration had been outside the scope of their investigation.

The team used Claude to verify the report end-to-end. The model converted the reported exploit into scripts, ran them, fixed script errors, and checked runtime sensors to see which actions triggered alerts.

"I could have done every step manually," Emil says. "Claude made the verification much faster."

The experience illustrates why context matters. Security information doesn't live neatly in one place. Code, infrastructure, network paths, logs and ownership information form a connected picture, and investigating a vulnerability often means moving between all of them.

When the AI gets it wrong

The trials also exposed clear failure modes. In one test, an agent correctly identified a vulnerability. Adding a second agent to review its work actually made the result worse: the reviewer dismissed the valid finding because it assumed an unseen backend would repeat an authorisation check.

In another experiment, Claude appeared to use Vend’s internal tools to identify the team responsible for a service. There was just one problem: it hadn't used the tools at all. Across 96 turns, it invented the tool calls and their results, including a team that didn't exist and people who weren't on it.

Another experiment asked Claude to review a file, and it concluded no critical issues existed, without mentioning that it had evaluated only 2,000 of the 5,000 lines provided.

The problem isn't only that an AI agent can be wrong. It can also produce an answer that looks complete while missing evidence or making assumptions along the way.

For security work, being able to verify what the agent has actually done is therefore essential.

At Sikkerhetsfestivalen 2026, Head of Product Security Emil Vaagland shared how Vend’s Product Security team has been experimenting with AI agents in cybersecurity.

How you organise the work matters too

There is another constraint: how much information an AI model can effectively work with at once.

The team tested different approaches on a large application of around 333,000 lines of code, asking each to identify its protected routes. Using the same prompt, model and reasoning effort, vanilla Claude found none of the 49 routes.

An approach that kept the input outside the model’s context window and inspected it programmatically found 44. Claude Dynamic Workflows, which planned the work and divided it between parallel agents, found all 49.

The difference wasn't a smarter underlying model. It was how the work and context were organised.

Testing what actually makes agents better

To separate genuine improvements from impressive-looking complexity, the team has started building evaluations from real, verified security cases.

Beginning with vulnerabilities where they already know the correct answer, they move forward by changing one part of the setup, such as the model, tools, skills or reasoning effort, and run the investigation again. Did it find the vulnerability? How long did it take? And how much did it cost? Some of the results have been counterintuitive.

In one test, increasing the model's reasoning effort still failed to find a vulnerability. Giving the same model tools to explore the repository changed what it inspected, and it found the issue in all three runs. In another, a large specialised security workflow found exactly the same vulnerability as a much simpler setup, while taking almost six times as long and processing 35 times more input.

More elaborate, in other words, doesn't automatically mean better.

A year of learning by building

Over the past year, the team has gradually expanded what they use AI agents for, learning from each new task and investigation along the way.

When an agent lacked information, they gave it a new skill. When it made a mistake, that case became something they could test against. When a more elaborate setup performed worse than a simple one, they stripped it back. And when something worked, they looked at what had actually made the difference.

That process has also changed the team's view of where the capabilities come from. A newer or more powerful model can help, but some of their biggest improvements have come from elsewhere: giving an agent access to the repository instead of pasting code into a prompt, connecting it to Vend's internal context, or changing how a large investigation is divided up.

The result today is a growing set of tools and workflows that can take on parts of investigations that previously required much more manual work, with real cases providing a way to see where they work and where they don't. And the experiments are continuing.

“Agents make us better security engineers,” Emil says.

And after a year, the team is still finding new tasks to give them, new ways they can fail, and new ways to make them more useful.