# Agentic Security: Permissions, Provenance, and the Agent Supply Chain Steve Yegge, Gas Town | AI Engineer World's Fair 2026 | 22:32 Source: https://www.youtube.com/watch?v=yWS0udrIOc8 Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/agentic-security-permissions-provenance-and-the-agent-supply-chain Published: 2026-07-20 Tags: agents, coding-agents, guardrails, security, tool-use ## TL;DR - AI-assisted development can increase the amount of vulnerable code faster than security teams can review it. - Security needs its own pass, with agents using tools such as Snyk and Chainguard to inspect code, dependencies, and inputs. - Teams need to plan now for agents that act continuously, because poorly scoped permissions and prompt injection create new risks. ## Summary Steve Yegge argues that AI coding makes security defects more dangerous because code production is speeding up while defect rates are unlikely to stay constant. He gives slop squatting as an example of a new attack: a model invents a package name, an attacker registers it with the expected behavior plus a backdoor, and the build passes. Yegge's practical answer is to make security a separate pass. Models are good at handling one task at a time, so correctness and security should not be requested together. He recommends giving agents security tools such as Snyk and Chainguard, then having them check the results. He also warns about autonomous agents with excessive permissions, prompt injection, and convincing AI-assisted scams against individuals. The talk is deliberately alarmed, and Yegge is honest that his recommendations are only a partial answer. ## Key ideas ### AI coding speed can multiply the vulnerable surface [01:38](https://www.youtube.com/watch?v=yWS0udrIOc8&t=98s) A chief security architect at a large bank asked Yegge what happens if everyone ships code ten times faster while the vulnerability rate stays the same. The vulnerable surface would grow tenfold. Yegge says the assumption about the rate is too generous because models writing code will probably make it worse. This means the problem is not only that existing bugs such as cross-site scripting continue to appear. More code will arrive faster, and the code will also introduce attack surfaces that developers have not learned to recognize. Yegge presents fear as the appropriate starting point because he does not yet have a complete answer. ### Slop squatting turns a model's hallucination into a supply-chain attack [03:08](https://www.youtube.com/watch?v=yWS0udrIOc8&t=188s) Yegge uses slop squatting to show how an attack can pass ordinary development checks. A model might invent a package name such as graphy123 while trying to add a graph database. An attacker can notice that models produce this name, upload a package under it, and make the package perform the expected task while adding a backdoor. The build succeeds, the tests pass, and the result can look correct. This is different from simply asking a model to avoid familiar bugs. It attacks the inputs and dependencies that the model chooses, so every generated dependency needs more scrutiny than it previously received. ### Security warnings lose urgency for humans, so they must reach the coding tool [04:51](https://www.youtube.com/watch?v=yWS0udrIOc8&t=291s) At Google, Yegge worked closely with the Test Automation Platform team, which ran unit and integration tests across a large fleet. He says the team learned that ordinary bugs have a half-life of urgency. A warning found while someone is typing is likely to be fixed, while the same warning raised during code review may be dismissed. Google moved bug reports closer to the developer's fingertips for that reason. Security is different because a vulnerability does not become less serious when users have not noticed it. Its harm can compound over time. The warning therefore needs to appear directly to the model or developer while the code is being produced. ### A security hardening pass found 241 problems that the coding agent missed [06:46](https://www.youtube.com/watch?v=yWS0udrIOc8&t=406s) Yegge asked Fable to perform a security hardening pass on a game he has worked on for 30 years. Fable handled cloud hardening and found credentials and other issues, which made the result seem reassuring. Yegge then ran Snyk against the same codebase and found 241 vulnerabilities that Fable had not considered. He connects this gap to his rule of five, which says that work done with an LLM often needs four or five reviews before it is ready to ship. Models improve when they get separate passes for separate tasks. A single request for correctness and security produces a partial job of both. ### Security should be a separate pass from correctness [08:08](https://www.youtube.com/watch?v=yWS0udrIOc8&t=488s) Yegge says strong models are good at doing one thing at a time. Their work moves through a draft, revision, polish, and editing process, much like painting a wall in several passes. Asking for correctness and security at the same time makes the model do a half job of each. His recommendation is to make security its own pass, then run it again at the end. He applies the same logic to performance, elegance, and company coding standards. These properties should not be assumed to appear automatically in generated code. Security gets extra attention because the cost of leaving a vulnerability in place increases over time. ### Security tools can extend an agent's limited attention [09:32](https://www.youtube.com/watch?v=yWS0udrIOc8&t=572s) In his Software Survival 3.0 essay, Yegge argued that language models are lazy in a useful sense. They avoid spending tokens when a tool can do part of the work, because tokens cost money and power. That behavior gives teams a way to add security checks to an agent's process. Yegge recommends putting Snyk and Chainguard into the workflow as explicit passes. Chainguard provides pre-vetted images and updates them, while Snyk checks the code, generated code, and dependencies. He also suggests using open-source and commercial tools together and having them check one another's work. His answer remains partial, but it is actionable. ### Autonomous agents need supervisors and narrowly scoped permissions [19:13](https://www.youtube.com/watch?v=yWS0udrIOc8&t=1153s) During questions, Yegge describes a new problem that goes beyond vulnerabilities in generated code: agents taking actions continuously. Companies are beginning to run agents around the clock to process queues and respond to events. He recommends thinking adversarially and using groups of agents to supervise other agents, because one agent will eventually make a serious mistake. Supervisors can inspect whether a service account really needs every credential it has and separate permissions by action. Yegge says teams need to design this in-house now, before engineers and non-engineers deploy agents with excessive access. He calls this a brand-new frontier with very little mature tooling. ### Prompt injection requires company-wide awareness before mature answers exist [20:58](https://www.youtube.com/watch?v=yWS0udrIOc8&t=1258s) Yegge describes prompt injection as an attack on training or inference. In a simple example, a user supplies text and an attacker adds instructions such as, "disregard everything and do the following." More sophisticated versions follow from there. He does not offer a finished technical solution. His immediate advice is to educate everyone who uses or deploys agents and to create security roles that cover agents as part of existing security work. The problem is still developing, which makes awareness and careful deployment necessary even while better controls are being built. ## Notable quotes - "The real title of my talk is "Be Scared"." (00:56) - "You can't give them security at the same time as you give them correctness." (09:13) - "Security should be your first one and your last one." (13:28) - "It is now months, not years, until it starts happening." (12:16) - "One agent will always eventually screw it up." (19:44) ## Tools & references mentioned - Fable - Snyk - Chainguard - Google Test Automation Platform - Five Eyes - Mythos - Claude - Gas Town - Beads - Boris Cherny - Software Survival 3.0 ## Who should watch - You are using coding agents and want a concrete way to add security checks to their workflow. - Your team is bringing in packages, container images, or generated dependencies without a separate supply-chain review. - You are deploying agents that run continuously or hold service credentials and need to think through supervision and permission scope. ## Related talks - [Agentic Development Security](https://aietalks.com/talks/agentic-development-security) (Ezra Tanzer, Snyk, 27:33) - [Securing Code-Executing AI Agents](https://aietalks.com/talks/securing-code-executing-ai-agents) (Fouad Matin, OpenAI, 14:00) - [Security Track Intro](https://aietalks.com/talks/security-track-intro) (Randall Degges, Snyk, 04:16) - [AI + Security & Safety](https://aietalks.com/talks/ai-security-safety) (Don Bosco Durai, Privacera, 18:13) - [IT Admin for the AI Workforce](https://aietalks.com/talks/it-admin-for-the-ai-workforce) (Sarthak Aggarwal, Decawork, 16:17)