The human envelope and eval sets from git
The guest is Evgeny Kakuykin: he runs the agentic systems initiative at OWASP and founded a startup that monitors and protects GenAI applications (the captions garble its name). The host widens the frame: code, architectures and pipelines have changed, while security is mentioned last, when it is too late to change anything. Evgeny starts with what surprised him: the first real agents grew up not in support but in development. Website chatbots promised savings on the first support line, but ran into inaccurate answers, ethics and the risk of volunteering something about competitors, while payback was eaten by GPUs, fine-tuning and token prices. By spring 2026 the best systems are strongest at code: in 2022 you could ask for a bubble sort, and now an agent rewrites a front end from React JS to Vue, if not on the first attempt.
Alexander explains this through the human envelope: as long as a person reviews the answer, that person is the guarantee the output is not nonsense; autonomously the envelope disappears and something else has to check the result. Development already has layers of control — compiler, linter, tests — and eval sets, assembled by hand in other domains, are here collected semi-automatically, because git works as a time machine. You take a bug from the tracker, find the commit where it reproduces, hand the agent that initial state, fast-forward to see which tests the human wrote afterwards, and run the agent's solution through them. Evgeny returns to what business expects: 97% accuracy means thirty failures per thousand cases, in a chain of two agents the error accumulates, and the sponsor asks for his living people back. In development, he adds, the same numbers are tolerable: the errors are spotted by eye and fixed. Alexander takes it further: the agent gets feedback that tests failed and a retry is configured, whereas an external customer cannot be told to try again.
Track economics and the price of a zero-day
Economics gets its own block: costing it precisely is one of this year's goals for the track, Alexander says. Costs hold hardware, support teams, sandboxes for workloads, model serving, an LLM proxy and gateway with authentication and quotas, and platforms such as RAG. Benefits are harder: "how much money the project might bring" is low confidence, "the team got 15% faster" is medium, and an honest answer comes only from per-job telemetry against a baseline that usually does not exist. A colleague, Anya Gromova, will cover the company's metrics in her own talk; Alexander bets heavily on migrations, where the transformation scenario is repeatable, and reminds that generating code is not the most labour-intensive part of the process. Evgeny adds a caveat: tokens for the best models are subsidised, the real cost of running them is still hard to compute, and loud claims that development will be solved by year's end sit next to generously paid developer vacancies.
Then, how cheap an attack is becoming. Evgeny brings up a case surrounded by myths: a model analysed the OpenBSD source and found a vulnerability that had lived there for more than twenty years; by the published figures the find cost around 20,000 dollars, but nobody knows at what token price, subsidised or not, and the bug may well be niche. Alexander answers that the point is not money but reachability: the number of specialists practising red teaming is finite, and they spread focus over projects they found promising, while a model widens the funnel: you can attack every important project at once and chain the problems into combinations a human would never enumerate. Token prices have fallen two orders of magnitude in two years; at 200 dollars per attack, a zero-day in the most trusted system gets found by a kid paying with a parent's card. Alexander's conclusion: survival is the ability to patch fast, and agents that apply the changes are needed at large companies within months.
Non-human identity and the supply chain
On governance Evgeny is blunt: the most cited OWASP guide, the top ten vulnerabilities of large language models, came out in 2024 and is already dated, while the top ten for agentic systems was written ahead of the curve, and some of its recommendations, sandboxing among them, are unverified and short on detail. The practical pain is credentials. This used to be called a service account: rights wired into cron, the person leaves, and it cannot be deactivated without breaking something. Now a thousand programmers have several assistants each, vendors claim up to 500 such accounts per person, and the problem has a marketing name, NHI, non-human identity. Alexander describes the present state: an agent is spawned on behalf of a user, so you want to limit its scope and hand it delegated tokens, folded into ordinary IAM. In the world where an agent is an employee in its own right that granularity does not exist yet, and he now reads about IETF agent protocols that move traceability and intent below the HTTP layer.
Evgeny reads the 2025 incidents as a supply chain story. In the Amazon Q coding assistant, by his account, a pull request landed in the summer that replaced the system prompt — with a typo, since the author only wanted to show it was possible. In the Postmark MCP server for email, a pull request was accepted that added a blind copy to an attacker's address: the functionality worked, tests passed, mail was delivered — just also somewhere else. And through a compromised dependency of a popular LLM gateway, 300 GB of credentials leaked in three hours, by the group's own claims, from machines that had merely updated their dependencies. Alexander sums up: exotic attacks on the model are not needed, basic engineering practices in the pipelines matter more. Evgeny finishes the thought: if the coding agent deploys to both dev and production from one machine, a compromised dependency takes the production secrets too, so the environments are worth separating. The finale is the dark factory, a shop floor that needs no lighting. The transition, Alexander thinks, will be uneven: startups take the risk, large companies pilot on small projects, lab adoption is a matter of this year and broad adoption a matter of years.
What to take away
- 01Agentic scenarios took off in development because code already sits inside a compiler, a linter and tests, and an eval set can be assembled from git history: a bug from the tracker, the commit where it reproduces, and the tests a human wrote afterwards.
- 02The economics of AI tooling is only honestly counted through per-job telemetry against a baseline; "the team got 15% faster" is a medium-confidence estimate, and generating code is not the most labour-intensive part of development.
- 03Zero-days get cheaper as tokens do, so the defence is no longer perimeter control through tooling but being able to patch your own legacy quickly and automatically.
- 04The big incidents around AI tooling are supply chain ones: a replaced assistant system prompt, a hidden copy of every email in an MCP server, a compromised gateway dependency; meanwhile non-human identities have to be brought into IAM with delegated tokens.