Agentic Security: Permissions, Provenance, and the Agent Supply Chain

If a team ships code ten times faster while its vulnerability rate stays unchanged, what happens to the number of vulnerabilities it ships? That is the opening problem behind Steve Yegge’s warning. Speaking on behalf of Snyk, which bought his conference ticket but did not pay him for the talk, he gives his presentation an alternative title: “Be Scared.” At a bank Q&A about vibe coding, a security architect had asked him precisely this question. Under the architect’s assumptions, ten times the code shipped means ten times the vulnerabilities introduced. The calculation assumes an unchanged vulnerability rate per unit of code; it is not a measured productivity result.

Yegge’s concern goes beyond that arithmetic. He predicts that AI-written code will make the vulnerability rate worse, increasing both the volume of code and the frequency of defects within it. He does not establish that prediction with a comparative study here, and the response he offers is deliberately partial: make security scrutiny part of the machinery producing the code.

Familiar vulnerabilities remain part of the problem. Yegge reports that Fable introduced an XSS vulnerability during the short period he had access to it. But producing more instances of familiar bugs is only one risk. Dependency selection introduces another: slop squatting, in which an attacker turns a model’s invented package name into something installable.

His hypothetical graph-database package, Graphy123, shows how the attack works:

1. A developer asks an AI to use a graph database.
2. The AI recommends Graphy123, a package name it has hallucinated.
3. An attacker notices that models recommend that nonexistent name and publishes a package under it.
4. The agent downloads the package. It supplies the expected functionality, so the project builds, runs and passes its tests—but the package also contains a backdoor.

Functional success does not establish dependency trust. The malicious package is useful enough to satisfy the task; its additional behavior is what makes it dangerous. That is why Yegge calls for greater security scrutiny of generated code, even when the ordinary development feedback looks reassuring.

The intervention point matters. At Google, Yegge worked closely with the Test Automation Platform team, which ran unit and integration tests across a large fleet. He describes a recurring human pattern: a bug found immediately is likely to be fixed immediately, but the motivation to fix it fades as time passes. A warning becomes familiar; eventually, a developer can rationalize leaving it alone because nobody seems to be suffering.

Google’s response, in his account, was to move findings into the act of writing code. A divide-by-zero warning that appears while someone is typing arrives when the relevant context is still in mind and the change is easy to make. By code review, even a legitimate finding can encounter resistance.

Security exposes the danger in that fading urgency. A vulnerability does not become harmless because users have stopped mentioning it—or never noticed it. Exposure can compound while the motivation to act declines. The same reasoning that puts a warning at a developer’s fingertips therefore applies to an agent: send security findings to the model while it is working.

A more capable model does not remove the need for this feedback. Security remains an arms race, rather than a property intelligence automatically supplies. Yegge briefly extends that concern to quantum computing, offering an informal five-to-seven-year estimate before mentioning a friend’s estimate of fifteen years. The practical issue he returns to is already present: how to make current coding agents notice the vulnerabilities they miss.

Yegge tried the problem on a game he has worked on for thirty years. He asked Fable for a security-hardening pass. It addressed cloud configuration, found credentials and performed other cleanup, then gave him the impression that the project was looking healthy. Yegge reports that a subsequent Snyk scan found 241 vulnerabilities that Fable had not thought to look for. He provides no scan report or severity breakdown, so the count describes his experience rather than a controlled comparison between the model and scanner.

This fits his rule of five: a working heuristic that LLM output may need four or five reviews before it is ready to ship. He compares the process to drafting, revising and polishing a document—or painting a wall that needs several coats. A single pass does not reliably cover every concern.

From his experience with vibe coding, Yegge concludes that agents do better when each pass has one clear task. Asking for correctness and security simultaneously risks getting incomplete work on both. His proposed workflow separates implementation from a focused security pass, giving security its own objective and tools. He then connects that practice to Software Survival 3.0, an essay he says he wrote about five months earlier.

The essay’s relevant idea is that an agent’s ability to synthesize software does not eliminate its incentive to use existing tools. Tools can save cognition and tokens, reducing cost and energy use. If agents already use tools to avoid unnecessary work, security analysis can become another capability they invoke rather than attempt entirely from memory.

Yegge divides that work between the inputs a project consumes and the code and dependencies it assembles:

Yegge describes Chainguard’s images as pre-vetted and vulnerability-free; the useful operational interpretation is low-to-zero known vulnerabilities, not immunity to undiscovered flaws. He also wonders whether Snyk can identify vulnerabilities ahead of the CVE registry. Snyk describes proprietary research, but that does not establish a blanket pre-CVE capability. In Yegge’s own scan, the findings corresponded to public CVEs.

The integration he proposes is straightforward: explicitly ask the agent to run a final security-analysis pass. Use available open-source and commercial tools, and, for a launch that warrants extra scrutiny, have them check one another’s work. A task instruction can make that handoff explicit:

After completing the implementation, perform a separate security pass.
Run the available security-analysis tools on the code and dependencies.
Review their findings and address the issues they identify.
Before launch, cross-check the results with the other available tools.

This is a workflow instruction, not a new API integration demonstrated onstage. It moves security analysis into the agent’s assigned work instead of leaving it as an optional human follow-up. Yegge also flags a missing dimension beyond secure inputs and secure code, which returns in the questions about agents taking actions.

The game’s findings are still work to do: Yegge asks the audience to give him a few days to fix them, joking that an attack would inconvenience five loyal players. He then broadens the urgency, attributing a months-not-years warning to Five Eyes. The NCSC’s public warning supports that broad concern about changing cyber capabilities, although it does not establish the particular model catch-up schedule he discusses next.

Yegge asks when open-source models will catch up to Mythos, which he describes as highly capable at hacking systems. Audience suggestions include two months, six months and December. Yegge estimates a roughly seven-month lag, shrinking toward six months; that remains his forecast, not an established deadline. His concern is what happens when strong offensive capabilities become more widely available.

Offensive capability does not mean a model automatically writes secure software. Yegge treats elegance, performance and adherence to company coding standards as separate concerns that also need dedicated passes. His prescription gives security extra attention: make it the first review pass and the last one. The final check matters because intervening changes can create new problems even after an earlier review looked good.

The prepared talk closes with a security action outside software development: meet family members offline, in person, and refresh shared code words. The scenario is a convincing distress call from a relative who urgently needs money, potentially accompanied by fabricated video. Recognizing a voice or face may no longer be enough to establish who is asking.

Yegge warns that families slow to adapt could lose their savings, predicting a months-long horizon. He also relays an unverified story about secret congressional demonstrations of bank-account draining. His own concern dates back nearly two years to a security researcher’s warning at ETLS Las Vegas that the consequences would be personal, not merely corporate.

The response available now is practical even without a complete solution: use the free, open-source and commercial tools already available, and adopt defensive techniques and practices. That is where the prepared talk ends. The audience questions then extend the problem from generated code to autonomous work and responsibility for deployed agents.

Asked what has surprised him recently about AI coding, Yegge first qualifies his perspective: he pushes agents unusually hard to anticipate where they are going. From that vantage point, the surprise is how much more slowly society moves. He describes smart friends dismissing AI enthusiasm as psychosis or insisting the systems will never become intelligent.

His explanation is a narrow observation window. Looking only three months backward and three months forward can make a changing curve appear flat. He expects people who see the broader trajectory to feel both more fear and more excitement. When he asks who is running Claude Code during the conference, the audience response illustrates the enthusiasm inside this room—and the gap between that experience and resistance outside it.

The next question asks for the most impressive thing Gas Town has done and how much human steering it required. Yegge describes it as a machine built around Beads, his task tracker. He still uses Beads and describes plans to donate it to the Agentic Foundation and add multiple backends; these are plans in this account, not completed changes.

The mechanism is a queue of work that agents can claim without waiting for another prompt. Yegge connects it to Boris Cherny’s advice about moving beyond continual prompting: provide enough tasks, let agents claim them, and keep the work moving for long unsupervised runs. He presents reliably running all night as a frontier that relatively few people in the room have reached.

His memorable Gas Town example begins with what looked like a bug. He filed a batch of Beads, then noticed that they had disappeared. An agent had found the tasks and implemented them all. The anecdote shows work being discovered and consumed without a fresh prompt for each item, though he does not quantify the human review or steering involved. When he asks who regularly works with more than ten coding agents at once, few respond. He expects that pattern to change quickly in the following year.

An audience member draws the crucial distinction: securing code an agent writes is different from securing an agent that can use credentials and act on user resources. Yegge identifies this as the third dimension he had wanted to cover. He discloses that he advises Tessl and says it is working in the space of agent oversight.

For agents running around the clock, processing queues and responding to events, Yegge recommends thinking adversarially about supervision. A lone agent will eventually make a mistake, in his view; groups of agents and supervisors should inspect and challenge the work rather than simply assume the queue manager is behaving correctly.

Permissions need the same scrutiny. Does a service account really need every credential it holds? If one credential is needed only for a particular action, can that action be separated from the rest of the agent’s work? The purpose is to reduce what an agent can reach when it makes a mistake or is compromised.

Yegge describes the available oversight systems as sparse and experimental, but urges organizations to design their own controls now. Both engineers and non-engineers can stand up agents with excessive permissions before anyone has decided how to supervise them. His analogy is a bear breaking into an igloo: once the perimeter fails, everything inside is exposed. The architecture has to limit the consequences of entry, not merely hope entry never happens.

The final question asks for prompt-injection practices Yegge has used or seen work. He distinguishes attacks on training from attacks during prompting and inference, then gives the simplest inference-time example: an attacker adds text telling the model, “Disregard everything and do the following.” He calls this the new XSRF as an analogy; the mechanism he describes is attacker-controlled text attempting to redirect the model’s instructions.

He does not offer a technical mitigation recipe. Instead, he says the attacks become more sophisticated and emphasizes education: people building and deploying agents need to recognize the risk. That leads to an organizational requirement. Yegge expects agentic-security roles to emerge as an extension of existing security work, with explicit responsibility for protecting deployed agents. Some audience members indicate that their organizations already assign people to that responsibility. The closing question is therefore concrete: who is looking after the security of the agents already running inside the company?