AI Engineer World's Fair 2026
Agentic Security: Permissions, Provenance, and the Agent Supply Chain
Read the talk
Agentic Security: Faster Code Needs Faster Security Feedback
Steve Yegge traces the risks from hallucinated dependencies to overprivileged agents, and explains why security tools, repeated review and explicit ownership must accompany autonomous work.
From a talk by Steve Yegge
Before you start: Familiarity with coding agents, software dependencies and service-account permissions will help; no specialized security background is required.
What happens when code ships ten times faster?
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A dependency can work perfectly and still be a backdoor
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:
- A developer asks an AI to use a graph database.
- The AI recommends
Graphy123, a package name it has hallucinated. - An attacker notices that models recommend that nonexistent name and publishes a package under it.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put findings where the code is being written
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A reassuring hardening pass still missed findings
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let agents offload security work to tools
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:
| Layer | Proposed support | Purpose |
|---|---|---|
| Container inputs | Chainguard images | Maintained images with low-to-zero known vulnerabilities |
| Application code and dependencies | Snyk | Security analysis of human-written and generated software |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Security belongs at the beginning and the end
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The attack surface includes your family
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Why the capability curve can look flat
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Gas Town: the missing tasks were already implemented
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Who watches an agent that can take action?
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Prompt injection needs an owner
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?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Yegge's essay on why agents choose existing tools and how software can remain useful by saving cognition and reducing friction.
A graph-based issue tracker for organizing coding-agent work.
A workspace manager for coordinating multiple coding agents.
An overview of the vulnerability intelligence and proprietary research behind Snyk's security tools.
Explains Chainguard's container-image directory and its visibility into known vulnerabilities and fixes.
The public warning that AI could transform offensive and defensive cybersecurity capabilities within months.
Further reading
A USENIX Security 2025 study of hallucinated package recommendations across 16 code-generating models.
Anthropic's account of cybersecurity evaluations and vulnerability research using Mythos Preview.
Read the complete timestamped transcript
- 0:00
[upbeat music] All right. Hey, everybody. Uh, yeah, yeah, yeah, yeah.
- 0:17
Okay. I have about 18 minutes. Um, I have a slide deck here that, that Claude put together for me, but Claude still can't do very good slide decks, so I apologize for that.
- 0:28
Just, just, just focus on me, right, right here.
- 0:33
This is like the most fun thing to do ever now. If I, if I start, like, running out of time, can, can you, like, call time for me? All right.
- 0:41
Perfect. So I'm Steve Yegge. I am here on behalf of Snyk today. I am not getting paid for this talk or anything like that. They were really nice enough to buy me a ticket to the conference, which is cool, but I'm mostly here because I wanted to hang out with all of you, and I don't bite, and
- 0:58
feel free to come and say hi afterwards. I, I wander the halls, amazed at all the brand logos. Um, I'm up here because [laughs]
- 1:08
like, the title of my talk is, like, Agentic Security, but the real title of my talk is Be Scared. [laughs]
- 1:18
Hey, I... Come on. Come on. Le- level with me. Who here is scared?
- 1:25
That's good, but you're all in the security talks. Of course you are. The problem is they aren't out there. [laughs]
- 1:31
Right? I s- I went to Commonwealth, uh, ugh, I went to so many places last year, but I w- one of these big banks I was at, I was talking to their chief security architect in December, and I was doing a Q&A and talking about vibe coding, and everyone was, like, asking me questions, and I was, you
- 1:47
know, knocking them out of the park, and he stands up real quiet at the end, and he goes, "Yeah, so..." [laughs]
- 1:54
He goes, "If everyone's shipping code at the same, sorry, at 10 times faster, and the defect rate stays the same, the security defect, right, the, the, the vulnerability rate,
- 2:10
then that, doesn't that mean that the defect surface goes up by 10X?"
- 2:16
And I [laughs] it hit me so hard, I, I sank down to my knees. I was just like, "What are we gonna do about this?" Because it's a really, really important point, 'cause the subtle implied question is not if the defect rate [laughs] stays the same.
- 2:31
The defect rate's gonna get worse, a lot worse, with AIs writing the code.
- 2:39
And so [laughs] y- I didn't have an answer for him. I actually have a partial answer for you today, and I'll share it with you, but it's only a partial answer.
- 2:49
The real answer is you have to be scared of what's coming. All right?
- 2:55
And it's bec- [laughs] it's bec- it's, it's, it's... Do I have a slide about this? Yeah. So it's not just that you're just, like, putting in more of the same defects, cross-site scripting and blah, blah, blah.
- 3:08
You're still putting those in. Fable wrote a cr- an XSS vulnerability during the short time that I had with it. Not its fault. We'll talk about it in a minute.
- 3:19
But those are the old ones. They, right, we all, we all know how to fix those. There's new vulnerability types and new attack surfaces coming, and they're here, and many of them are incredibly well-polished.
- 3:32
Like, what's an example? You guys know about slop squatting?
- 3:36
Right? Where the AI hallucinates, uh, a, a package name. Let's say that you want a graph database, and so you're like, "Okay, I'm gonna use this graph database," and the AI goes, "Oh, yeah, I know.
- 3:45
It's, you know, it's Graphy123," and it goes off to the package manager and downloads Graphy123, and it builds, and it runs, and the tests pass, and it looks right, but what it downloaded was a backdoor.
- 4:00
Because that Graphy123 wasn't a real package, but somebody noticed that the LLMs are hallucinating its name, and they uploaded one that does exactly the same thing as the one it thought it was getting, plus a vulnerability.
- 4:11
Bonus. Yeah? Is that scary? Yeah, it should be. It should be. How do you even detect that that's happening?
- 4:22
So, so [laughs] we're entering a world where everything you write, every bit of code that you generate, is gonna have to get far more security scrutiny than it's ever had before,
- 4:41
okay? It's just, it, you're not... It's hard for me to convey how scared I am, all right?
- 4:49
But let's start with where it gets generated. Now, when I worked at Google, I worked really close with the TAP team. They did tests, the Test Automation Platform, yeah?
- 4:58
And they, uh, so they ran all of the unit tests and integration tests at Google. They had a massive fleet, you know, and, and they learned stuff about how bugs work, and how bugs work is they have a li- they have, like, a life cycle where w- if you see the bug right away, you'll fix it, and
- 5:15
the longer the time goes for when you see a warning or some sort of issue, the longer that passes, okay, it's got this sort of half-life of urgency, and all of a sudden, eh, it ain't really biting anyone anymore, okay?
- 5:28
This is how we handle all of our bugs. At, at Google, they recognize that this is such a human nature phenomenon that they worked really hard to, to move the reporting of bugs as you were typing
- 5:43
because that's when you're most likely to fix it. If you make a bug and it goes, "By the way, there's a divide by zero here," or there's a backdoor or vulnerability or whatever, you'll, you'll fix it right there.
- 5:53
But if it gets to code review time, you're like, "Is it really worth it?" Right? And the problem, folks, is that that works for all classes of bugs except for security.
- 6:06
There's no half-life on it biting you. It's not like, oh, because users aren't getting bothered by this security vulnerability that it's not a problem over time. The problem compounds over time.
- 6:18
Yeah? So you have to treat this class of vulnerabilities the way that Google treated their top vulnerabilities at the time, which is to surface them at the developer's fingertips.
- 6:31
What if the developer doesn't have any fingers? I don't know, how, how many fingers do LLMs have? Um,
- 6:41
then you need to surface it to the LLMs. But wait, you say, wait, wait, wait, wait, wait, wait. Fable's really smart, or at least it seemed that way for the two days I got to use it.
- 6:52
Uh, can't Fable just write secure code, right? I mean, come on. Come on. You, you all know sec- I mean, you're all here in this room, right? You all know security is an arms race, one that never ends, one that's going up exponentially with Moore's Law, one that's gonna get real uncomfortable when quantum comes along.
- 7:09
Thank goodness that's like five to seven years away.
- 7:13
Uh, my buddy says 15, so maybe somewhere in between. But in the meantime, right, LLMs are a real problem. Yeah.
- 7:22
So how do you surface, how do you surface the vulnerabilities? Well, first I wanted to figure out how to do it myself. I have a game I've been working on for 30 years.
- 7:30
I just had Fable do a security hardening pass during the time I had it. Went through and it did all my cloud hardening, and it found a bunch of credentials, and did a, a bunch of stuff.
- 7:42
And it started giving me these vibes like, yep, yep, hardening pass, looking pretty good. So I ran Snyk, right? And I, I don't have the numbers here. Uh, yeah, I didn't, I didn't include the numbers 'cause, uh, I'm done.
- 7:54
But, um, uh, it found 241 vulnerabilities, right? Just a ton that Fable hadn't even thought to look for, right? Uh, and it's because, look...
- 8:07
So I, I th- I've told people about the rule of five. When you do things with LLMs, often you have to get them to do up to four to five reviews of the work that they did before it's like actually ready to ship.
- 8:17
And it's because their cognitive process is very similar to ours, and it goes through a draft, and then a revision, and then polish and editing until it's, you know, it's finally ready to go.
- 8:29
It's like painting a wall. Some things you don't just do all in one pass. You do them in multiple passes, right?
- 8:36
So, um, security is one of the... So w- what I found, I wrote a book on vibe coding last year. I d- did more vibe coding, I think, than anyone, you know, two, two years ago.
- 8:53
And, and what I found was, um, that they're really good at doing one thing at a time.
- 9:02
Even the really good models like Fable, right, just because of this multi-pass painting a wall phenomenon. You gotta give them one task at a time, which means you can't give them security at the same time as you give them correctness.
- 9:16
They'll do a half-ass job of both, and you don't want a half-ass job of either of those, it turns out. [laughs] So you do it in two passes, right? Now, uh, five, it's been five months now, but five months ago, I wrote an essay called Software Survival 3.0, where I talked about what software has to do to survive
- 9:33
when LLMs can synthesize it all. I don't know if any of you all saw that, but the basic, the basic gist of it is that LLMs can synthesize any software that they want, but they're very lazy in a good way, right?
- 9:46
Lazy in like they don't wanna spend tokens if they don't have to, because that's money and power and bad for the planet and bad for your wallet and so on, right?
- 9:54
And so they use tools to help them whenever it can save tokens, right?
- 10:01
So tying it all together, if the LLMs are doing the coding and they're happy to use tools to help them offload cognition, you see where this is going? Give them Snyk, give them Chainguard, and I still think there's a missing piece in this picture that I'll tell you about at the end.
- 10:19
Um, Chai- I don't know if you all know about Chainguard. Chainguard, uh,
- 10:25
Chainguard is a supply chain that you sign up for, and they give you images that have been pre-vetted to not have vulnerabilities, and they update them. So it's your inputs, okay?
- 10:36
And then Snyk handles everything else. The code that you write, the code that the LLM writes, the dependencies that you're pulling in from Slopsquatting, right, the innocent stuff. It can find...
- 10:49
My understanding is that Snyk can actually find vulnerabilities that are proprietary, that only they know about because they're ahead of the CVE registry. I've, I... Is there some truth to that?
- 10:59
When I ran them on my code base, it didn't find any vulnerabilities that weren't already public CVEs, but damn, it was easy to use, right?
- 11:09
I think that s- a tool like Snyk is gonna give your LLMs superpowers, okay? 'Cause what you do is you add it as a pass to the prompt that you give them for whatever they're doing, and say, "One last thing to look at," and have them run your security analysis, all of the tools, get the open source
- 11:31
ones, get the Snyk one, get the Chainguard one, get the, all of them, and have them
- 11:37
check each other's work too, right, if you wanna get really serious about this on launch time, right? But secure your supply chain, because Five Eyes is warning us, yeah.
- 11:47
My poor, my poor game. By the way, please, please, I just told you that my game has 241 vulnerabilities. Don't go hack my game. Give me a couple days to fix the bugs, yeah?
- 11:56
We all good here? Good. All right. But if you do hack it, you're gonna bother like five players, all right? [audience laughing] Okay. They're very loyal. Um, look, Five Eyes- Which is like a bunch of, right, governing...
- 12:10
It's, it's big countries that are, have, have their eye on, on the cybersecurity, you know, landscape. They just announced that it is now months, not years, until it starts happening.
- 12:18
It. You all know what it is, right? It is when
- 12:26
open source models catch up to Mythos. Does anybody here believe open source models are gonna catch up to Mythos?
- 12:35
Interesting that it's about 50/50. Anyone got a timeframe in mind?
- 12:40
Two months. Six months. December.
- 12:43
Who said December? That's pretty accurate.
- 12:45
Uh, there was a talk yesterday. He showed the line.
- 12:47
Cheater. [laughs] Yeah, it's about seven months, so... Actually, it's shrinking, so it's probably about six months now. Yeah. And Mythos is real, real good at hacking your systems. [sighs]
- 12:59
And, and just, just remember you can't trust it to automatically write good code any more than you can trust it to write elegant code by default. That's a separate concern.
- 13:12
It's a separate pass. You can't expect it to write performant code by default. That's another pass. You see what I'm saying? You can't expect it to necessarily write the code according to your company coding standards, okay?
- 13:24
These are all passes that go through your code, and I just want you to remember that security should be your first one and your last one, okay? Give it extra.
- 13:34
Okay, and the last thing I wanted to talk to you about, first of all, go do all this, and second of all, uh, the last thing is really tru- tru- truthfully, okay?
- 13:44
Dial it in here, folks. Go to your families offline, like, in person, and get your, your code words refreshed. 'Cause another kind of scam that's coming along is you get a call from a family member who's in distress, and they need money, and it's very convincing, and there's a video of them, and you're gonna need a way
- 14:04
to distinguish them from, from AI. Okay? It's months away, and some of your families are gonna be slow to catch on to this stuff, but bank accounts will be drained.
- 14:15
I heard that Congress was given secret demos of draining bank accounts. I've been scared of this for close to two years. I heard one talk from a security researcher almost two years ago at ETLS Las Vegas, and he stood up in front of the crowd and he said, "You're all not scared enough of what's coming.
- 14:34
It'll affect you personally, not just your company." Okay? So that's my message to you. It's not a message of hope and positivity today. [laughs]
- 14:43
But it is a, it is a message that, that's, that should be clear, crystal clear, is that there are tools, open source tools, free tools, commercial tools, okay? Techniques, practices, okay?
- 14:56
That you can use right now to get started on fighting in this arms race and protecting yourself, and that's all I've got today. Thank you. [audience applauding]
- 15:12
We do have time for a couple questions.
- 15:13
Questions? We ready to go?
- 15:30
Sweet. Um, just super simple. What has surprised you recently in the world of AI coding?
- 15:37
What has surprised me in the world of AI coding? Well, I'm not really super representative. I spend a lot of my time trying to predict the future by, like, hammering agents really, really hard.
- 15:49
Yeah. Um, so, um, uh, you know, one of the surprises, and I shouldn't have been surprised, but one of the surprises is that AI is moving faster than the world is moving.
- 16:02
Uh, tech is moving ses- faster than society can move, and the surprises show up when friends, smart friends, resist, uh, you know, the inevitability of AI and they call it psychosis or they, right, or they poo-poo it and they say, "Well, it'll never be actually smart," or whatever.
- 16:23
They, they can't see the curve, right? And, uh, and that surprises me. Uh, maybe it shouldn't. Um, it sh- shows a sort of tunnel vision. I think people have a tendency to look about three months back and about three months forward and be like, "Oh, it looks pretty flat."
- 16:39
Right? But, but... And so that, that surprises me, that people aren't, honestly, that people aren't more scared and that, and, and by the same, by the flip side, that people aren't more excited by it, right?
- 16:50
'Cause you know once you actually, you know, once, once you get it, I mean, you don't even wanna be here. How many of you are running Claude Code right now? [laughs]
- 16:59
Most of you, right? It's really fun. So, you know, I mean, like, that's a surprise too, that the world is pushing back so hard on that, right? We're in an awkward phase.
- 17:09
We'll get through it. Any other questions? Whoa. All right. Well, you pick.
- 17:19
Feel free to bail also. You don't have to stay.
- 17:22
I, big fan. Um, what's the, like, most impressive, uh, thing you've seen Gastown do, and, like, how much human intervention was involved or steering?
- 17:31
Oh, Gastown? Yeah. Gastown. Gastown was a lot of fun in January. Um,
- 17:38
yeah, Gastown is a Beads machine, and I still use Beads, and I'm working, I wanna... I was talking to Angie, I wanna donate Beads to the Agentic Foundation, you know.
- 17:48
We're gonna, we're gonna put multiple backends on it. Beads is a task tracker, right? Beads is how you do Boris Chainey loops. You know how Boris is like, "You shouldn't be prompting your agent"?
- 17:59
Has anybody here actually, like, successfully... How often do you get Claude to actually run all night for you?
- 18:06
Like, for real run all night. A few of you, right? Like, this is the next frontier, I think, of actually getting agents to run, like, for a long, long time unsupervised.
- 18:16
You can do it with Beads by queuing up enough, enough work and having them claim and all that, and there are some other, some other systems that'll do that.
- 18:24
It was really fun when Gas Town did this for me automatically once. I filed a whole bunch of Beads, and they disappeared, and I was like, "Oh no, another bug.
- 18:30
My Beads disappeared." And what had actually happened was that one of the agents just found them and just implemented everything, [chuckles] right? It was like, whoa. I really like swarms now.
- 18:39
Yeah. Fun times. Does anybody here regularly work with more than 10 coding agents at once?
- 18:48
You see, like, not many, right? The world is still in a-- We're still kinda, like, prompting and using a few here and there, right? It's gonna accelerate really fast next year.
- 18:58
Other questions. You. You just say it.
- 19:02
Yeah. Um, your talk focused a lot on vulnerabilities from agents writing code. And I'm curious, what are your thoughts about agents taking action? So having access to credentials or user-
- 19:13
Yeah. So that was the third dimension that I really wanted to talk about. It's just I don't really have time, but,
- 19:19
like, my friends over at Tessle, I'm advising them. They're actually doing this, right? There's just this whole space of who's looking up-- who's looking over your agent's shoulders? I had this conversation just now, like I tell everyone.
- 19:32
Everyone's just starting to stand up agents, like, twenty-four/seven,
- 19:36
like, processing queues, responding to events. Like, agents that actually do stuff, right, twenty-four/seven. And I, I, I, I encourage people to think adversarially. I th-- uh, think of adversarial groups of agents tasked with doing that queue management, 'cause one agent will always eventually screw it up, right?
- 19:57
So you gotta have those supervisors. And so there's whole systems emerging here, kinda c-- go out and go look at all of your things and say, and start to like, you know, do, do, do that hardening stuff.
- 20:07
Like, do they really need all those credentials on that service account? Really? Right? Only for this one action, maybe we can, like, separate this one out, that kind of thing, right?
- 20:15
This is a brand-new frontier, but it's one, ironically, that even though there's kind of almost nothing out there, there's some experimental stuff, you still have to be thinking about it right now and designing a solution in-house right now, right?
- 20:29
Because otherwise, your engineers are gonna spin up a, or your non-engineers are gonna spin up a bunch of agents with way too many permissions and then, right, as soon as a bear munches into the igloo, everyone's dead, right?
- 20:41
That's the old security analogy. I don't know if they still use that one anymore. [clears throat] Yes.
- 20:46
Hey, Steve. Nice to see you. Um, I'm curious in terms of, like, just the best practices that you've seen, uh, that you use personally or, or maybe you haven't tried, but, um, particularly with regards to prompt injection.
- 21:00
So-
- 21:01
Yeah. So I was supposed to talk that during my, right, during, during my speech here, right. I, I wanted to mention it. There are a whole bunch of s- attacks happening on the training and on the prompting side, right?
- 21:14
So on training and inference. And so the bad guys find ways to sneak in stuff, right? Um, and it's like, like, like the simplest version is the new XSRF where, like, the user puts in some, some text, and then some bad actor puts in some extra text saying, "Disregard everything and do the following," right?
- 21:33
And then they just get more sophisticated from there. Um, I mean, I don't have any good answers for you other than, like, this is real. It's kind of an education problem at this point.
- 21:45
You need to get everybody thinking about it, right? And then y- uh... I feel like there are, like, new security roles about ready to emerge inside of companies, agentic security, that it's kind of an extension of what they're already doing.
- 21:57
Who's already doing this? Right? Yeah. So you've, you've already got people that are going out and looking after the, the sort of security of your agents that are in-- that are deployed in the...
- 22:07
Yeah, so you're way ahead of everyone. I'd love to come talk to you later. [chuckles]
- 22:11
This is all brand-new stuff, yeah? Cool. [outro music]