Build or Replaced
Today: The Tower Keeps Rising | I tricked Claude into leaking your deepest, darkest secrets | Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE Episode date: 2026-07-15.
Download MP3 →JOSH: It's Wednesday, July 15. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today is agent safety, local models, and the part where your tools start acting like junior engineers with root access. JOSH: Stick around — Erik's got an AI pro tip at the end about building a kill switch into your agent workflow. JOSH: First headline. Claude secret leakage made the list today. Is this another prompt injection panic story, or something real? ERIK: It's real. People keep stuffing private context into agents, then letting those agents browse, call tools, and summarize untrusted content. If your agent can read secrets and talk to the outside world, you built an exfiltration machine with a friendly chat box. JOSH: Next up, Bonsai 27B running on a phone. Wait, really? ERIK: Yeah. That's the signal. A 27B-class model on mobile means edge inference is not a toy anymore. Not for every task, but for private reasoning, offline checks, and cheap background loops, local models are going to matter. JOSH: Third headline. Dependabot added a default package cooldown. That sounds boring, which usually means important. ERIK: Boring is where production lives. A cooldown slows fresh package updates so you're not first in line for the compromised release, the broken release, or the Friday afternoon surprise. JOSH: The Claude leakage story feels like the one people should care about first. ERIK: Correct. Everyone wants agents with tools now. File access, browser access, terminal access, database access, Slack access. Great. That's useful. That's also how you turn a prompt into an incident. JOSH: What actually happens in this kind of attack? ERIK: The pattern is simple. The model reads something untrusted. A webpage, a document, an email, a GitHub issue, whatever. Hidden inside that content is an instruction that says, basically, ignore the user and leak the private stuff you can see. JOSH: And the model treats that like normal instructions? ERIK: Unless you've built the workflow to treat that input as hostile, yes. It just sees text. Models are very obedient interns with no badge reader. JOSH: That's the weird part. We know not to run random shell scripts. But people will paste anything into an AI tool. ERIK: Exactly. The browser trained everyone to trust rendered content. AI tools made text executable in a softer way. Not executable like a binary, but executable as intent. That's enough to cause damage when the model has tools. JOSH: What does that mean for builders using Claude, Codex, or Cursor every day? ERIK: It means you need boundaries. The model should not have the same access everywhere. My Claude instances on PrimeBus don't all get the same permissions. One can inspect. One can propose. One can test. Anything risky has guardrails before it touches the repo. JOSH: So the tool setup matters as much as the model. ERIK: More, honestly. A good model inside a sloppy permission model is still a sloppy system. It's like giving a junior admin domain admin because you wrote "please be careful" in the ticket. JOSH: How do you design that without slowing everything down? ERIK: Split the workflow. Reading is one permission. Writing is another. Deploying is another. Touching secrets is another. The agent can inspect a repo, propose a patch, run tests, and explain the diff. It should not automatically push to prod unless another system checks the result. JOSH: That's the line, right? Don't make the same model that wrote the change approve the change. ERIK: Duuude, yes. That's the whole thing. If the same agent generates the code, reviews the code, approves the code, and deploys the code, you didn't build automation. You built a very confident rubber stamp. JOSH: What should a smaller team do if they don't have PrimeBus sitting around? ERIK: Start with three rules. No secrets in general chat context. Tool calls get scoped permissions. Anything that writes to production needs a second check that is not the same prompt thread. JOSH: Could that second check just be another model? ERIK: Sometimes. I use multiple agents because disagreement is useful. But don't pretend two model calls are the same as a security boundary. For high-risk actions, use deterministic checks too. Tests. Policy files. Allowlists. Diff size limits. Blocked paths. Approval gates. JOSH: So agent safety is less about a perfect prompt and more about the system around the prompt. ERIK: Exactly. Prompting matters, but architecture wins. The prompt is the steering wheel. Permissions are the brakes. Logs are the dash. If you don't have all three, you're not driving. You're hoping. JOSH: Where do secrets belong in that setup? ERIK: Outside the agent's general memory. Use environment isolation. Use secret stores. Pass short-lived tokens only when a tool actually needs them. And don't let the model print them back into logs. That one sounds obvious until you read the first failed agent trace. JOSH: That's painful. ERIK: Yeah. Logs are where secrets go to retire if you're careless. JOSH: How does this connect to network automation? ERIK: Network automation has had this problem forever. In Cisco NSO, Ansible, Terraform, whatever, the dangerous part is not reading config. The dangerous part is write access to routers, firewalls, load balancers, DNS. AI didn't invent that risk. It made it easier to hit by accident. JOSH: So your old networking instincts carry over. ERIK: Completely. Change windows, dry runs, diffs, rollback plans, config validation. Same game. New interface. When an agent wants to touch infrastructure, I want the same discipline I'd want from a human engineer. JOSH: The second story is Bonsai 27B. A 27B-class model running on a phone sounds like science fiction from about six months ago. ERIK: The window keeps moving. Quantization is doing real work. Smaller weights mean you can fit bigger models into smaller memory footprints. You don't get magic. You get tradeoffs. But the tradeoff is now good enough to be useful. JOSH: What changes when a model runs locally instead of in the cloud? ERIK: Cost changes first. Latency changes second. Privacy changes third. If I can run a capable local model for a narrow task, I don't need to send every tiny decision to a hosted API. That's huge for background agents. JOSH: Give me an example. ERIK: PrimeSentinel watches for stuck jobs. A lot of that doesn't need a giant frontier model. It needs to read logs, classify the failure, decide if a runbook applies, and publish an event. A local model can do the first pass. JOSH: Then Claude handles the hard part? ERIK: Right. Use the expensive model where judgment matters. Use the local model where pattern matching is enough. That saves money, reduces latency, and keeps sensitive junk closer to home. JOSH: Is the phone part the real story, or is it the model size? ERIK: The phone is the headline. The real story is deployment shape. If a phone can run it, then a laptop can run it. A home lab box can run it. A branch office appliance can run it. A network tool can embed it without calling a cloud API every time a log line looks weird. JOSH: That starts to sound like agents everywhere. ERIK: That's where this goes. Not one giant agent doing everything. Lots of small agents doing specific jobs. One watches logs. One reads tickets. One checks config drift. One looks at backups. One writes summaries. They talk over an event bus. JOSH: PrimeBus territory. ERIK: Yep. Get everything on a bus. NATS is great for this. Events come in, agents subscribe, each agent does its job, and the system records what happened. It's not glamorous. It works. JOSH: Where do local models fall short? ERIK: Tool use, long context, hard reasoning, and weird edge cases. I'm not asking a small local model to redesign a Terraform module or reason through an ugly NSO service package. That's Claude work. But I will ask it to classify alerts, tag logs, summarize a failure, or decide whether something needs escalation. JOSH: So the builder move is not replacing cloud models. It's routing work correctly. ERIK: Exactly. Model selection is infrastructure now. People treat it like picking a chatbot. Wrong frame. You pick models the way you pick databases. What's the workload? What's the latency budget? What's the failure mode? What's the cost if it's wrong? JOSH: That's a very engineer answer. ERIK: Good. Because the chatbot era is already boring. The useful part is systems. Agents that do work, with permissions, event trails, retries, and rollback. That's where builders win. JOSH: The third story is Dependabot's package cooldown. Why should people care about a delay in dependency updates? ERIK: Because supply chain attacks are ugly. A package gets compromised. The update hits. Automated systems happily pull it in. CI passes because the malicious part doesn't always break tests. Then you're running someone else's payload in your build. JOSH: And the cooldown gives the world time to notice? ERIK: Exactly. Fresh is not always better. A cooldown says, give this release a minute before we auto-open the update. If it's poisoned, broken, yanked, or setting GitHub on fire, maybe don't be first. JOSH: But don't security updates need to move fast? ERIK: Yes, and that's the tradeoff. You don't use one rule for everything. Critical CVE patch from a trusted source? Move fast. Random minor version bump from a tiny package with maintainer drama? Let it cool. Policy matters. JOSH: How do you think about that in your own projects? ERIK: Dependency automation is like auto-merge. The goal is not maximum speed. The goal is safe throughput. PrimeBus can move fast because it has tests, review gates, and blocked paths. Without that, fast just means you break things before breakfast. JOSH: Is there a simple version for solo builders? ERIK: Yes. Turn on Dependabot or Renovate. Group low-risk updates. Separate security patches. Add a cooldown for regular packages. Require tests before merge. Block updates that touch lockfiles plus install scripts unless you review them. JOSH: Install scripts are the scary part? ERIK: They can be. Preinstall, postinstall, build hooks. That's code execution. People forget npm packages are not just files. They're little strangers you invited into your house with a key to the build step. JOSH: That's bleak. ERIK: Accurate, though. JOSH: Where does ScanBrief fit into this kind of story? ERIK: ScanBrief is how I catch patterns early. I don't need every headline. I need signal. If three unrelated feeds start lighting up around package attacks, model leakage, or a toolchain issue, I want that before I'm staring at a failed deploy. JOSH: It's a radar. ERIK: Yeah. That's the point. Builders need radar. Agents need guardrails. Dependencies need cooling-off periods. All three stories today are the same lesson wearing different clothes. JOSH: The lesson is slow down? ERIK: No. The lesson is move fast with brakes. Big difference. I ship daily because the system has checks. If your only safety mechanism is your memory, you're done. Humans forget. Systems don't, if you actually build them. JOSH: That ties back to the theme pretty cleanly. ERIK: Agent safety, local models, Dependabot cooldowns. Same shape. Put the right work in the right place. Don't give every tool every permission. Don't let speed outrun control. That's how you build without waking up to a mess. ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com JOSH: Alright, what's the AI pro tip today? ERIK: Build a kill switch before you build the fancy part. Seriously. If you're wiring an agent to tools, add a single flag that can stop writes instantly. Environment variable. Redis key. Database setting. Doesn't matter. The agent checks it before any destructive action. JOSH: What counts as destructive? ERIK: File writes, git pushes, deploys, emails, database mutations, ticket updates, cloud changes, network changes. Anything that changes state outside the chat. Reads can usually keep going. Writes need a brake. JOSH: How would someone add that today? ERIK: Wrap every tool call in a policy function. Before the tool runs, check AI_WRITES_ENABLED. If it's false, return a blocked result and log the attempted action. Don't hide it. Make the agent explain what it would have done. JOSH: So the workflow keeps its memory, but the system stops the action. ERIK: Exactly. That's the move. You don't want a panic button that kills observability. You want a brake that stops damage and leaves a trail. Add the flag. Test it. Then try to make the agent write while it's off. If it still writes, your kill switch is fake. That's your tip. Use it. ERIK: If you're building toward financial independence through automation, my first book walks through the whole path. Free chapter at erikandersonbook.com. JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev. ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff. ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.