Build or Replaced
Today: iCloud+ Hide My Email addresses will remain on icloud.com | How Europe is killing makers and micro-entrepreneurs | The entire city of San Francisco as a video game Episode date: 2026-08-25.
Download MP3 →JOSH: It's Tuesday, August 25. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: ScanBrief scored 86 tech signals this morning, and the theme is simple: your tools are quietly changing the rules while you're still writing the runbook. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents show their work before they touch production. [pause] JOSH: First up, Apple is changing Hide My Email domains. Is this boring admin work, or does it actually matter? ERIK: It matters. Apple moving new Hide My Email addresses to private.icloud.com means every brittle email validator, allow-list, fraud rule, and signup flow gets tested in public. JOSH: That sounds like the kind of thing nobody notices until checkout breaks. ERIK: Exactly. Nobody gets paged because a domain changed in a press note. They get paged because revenue got weird. [beat] JOSH: Next, Microsoft Paint and Photos are adding invisible AI watermarks with GUIDs, even on locally generated output. Wait, really? ERIK: Really. Local generation doesn't mean clean output anymore. If the file leaves your machine carrying an invisible ID, then offline is not the same as private. JOSH: That's a pretty big line. ERIK: Big line, tiny DLL. Classic. [beat] JOSH: Third headline: researchers say LLMs could control host machines by exploiting inference engines. Is this theoretical, or should builders care now? ERIK: Builders should care now. If your model runtime parses hostile inputs, loads plugins, touches files, or calls tools, then it's part of your attack surface. Treat it like production code, because it is. [pause] JOSH: The Apple story sounds small, but you reacted fast to it. Why? ERIK: Because small protocol and identity changes break real systems. Email is one of those ancient load-bearing beams in software. People treat it like a string field. It's not. It's identity, auth, billing, support, fraud detection, password reset, routing, and compliance duct-taped into one box. JOSH: So a new domain becomes more than a new domain. ERIK: Right. Apple says new Hide My Email addresses start coming from private.icloud.com later this year, and the old privaterelay.appleid.com addresses keep working. Fine. But now your system has to accept both. Your regex has to accept both. Your customer support tooling has to recognize both. Your suppression lists have to understand both. If you hard-coded old behavior, you bought yourself a future outage. JOSH: Who actually hard-codes that? [beat] ERIK: Duuude. Everyone. Somewhere, in a codebase nobody wants to touch, there is a validation rule written during a launch week. It says accepted domains are Gmail, Outlook, Yahoo, maybe iCloud if somebody remembered. Then marketing asks why signups dropped from iPhone users. JOSH: That's painful because it looks like a user problem. ERIK: It always does at first. "User typed a weird email." No. Your system rejected a valid address because it thought the internet stopped changing in 2018. JOSH: How do you handle that in your own stuff? ERIK: I don't want email logic spread across services. In my world, email-reactor handles client website change requests from email, and anything that touches message identity gets events on PrimeBus. I want the system to see weird input once, classify it, and publish the result. Not twelve little apps all guessing what an email is. JOSH: So the fix isn't just update the regex. ERIK: Updating the regex is the smallest piece. The better move is: stop treating validation as a wall. Treat it as a policy. Log unknown-but-possible domains. Alert on rejection spikes. Store why something failed. Make your support tools show the actual reason. If Apple ships a new domain and your system rejects it, PrimeSentinel should catch the pattern before a customer explains your product to you. JOSH: That's the part people miss. The observability around the boring stuff. ERIK: Boring stuff pays the bills. Password reset links are boring until they fail. Email aliases are boring until account recovery breaks. DNS is boring until the CEO can't log in. Networking taught me that. Cisco NSO, Terraform, Kubernetes, same lesson every time: the quiet dependencies are the ones that punch hardest. [beat] JOSH: What's the builder takeaway? ERIK: Go find every place you validate email. Frontend, backend, CRM import, webhook handlers, allow-lists, fraud checks. Then make one shared policy or one shared test suite. Add Apple's new domain before it shows up in your logs. Also test plus signs, long domains, aliases, subdomains, and weird but valid addresses. You don't need a committee. You need a failing test today and a fix before lunch. [pause] JOSH: The Microsoft watermark story feels different. Paint and Photos using local models, but still embedding invisible GUID watermarks. What's your read? ERIK: My read is: local AI is not automatically yours. That's the whole point. People hear "runs on device" and assume no tracking, no metadata, no policy layer, no hidden output changes. Then Watermarker.dll walks in wearing a little badge. JOSH: Is watermarking always bad? ERIK: No. Content provenance can be useful. If a court, school, marketplace, or news org needs to know whether an image was AI generated, watermarking helps. The problem is consent and visibility. If the tool changes my output, I should see that. If it embeds a GUID, I should know what that GUID means, when it was created, and who can read it. JOSH: That seems fair. ERIK: It is basic engineering hygiene. Don't mutate artifacts invisibly and then act shocked when people get upset. If a CI system signs a build, great. Show the signature. If an image tool marks generated files, fine. Show the policy. Hidden metadata is where trust goes to get audited. JOSH: How would you build it? ERIK: Plain toggle. Plain label. Export panel says: "AI provenance watermark included." Give me a remove option if policy allows it, or tell me it can't be removed because the app store, enterprise tenant, or regulation requires it. Don't make people reverse-engineer a DLL to understand their own file. JOSH: This ties into AI agents too, right? ERIK: Completely. Agents produce artifacts. Code, images, emails, tickets, commits, pull requests. If the agent touches the artifact, you want provenance. But provenance has to be visible and useful. In PrimeBus, the auto-merger has run 2295 attempts since 2026-06-05: 1507 merged, 788 blocked by Gandalf, 0 escalated to me. That only works because the system records what happened, why it happened, and who approved or blocked it. JOSH: The blocked count is the story there. ERIK: Exactly. People hear blocked and think failure. No. That's guardrails doing their job. If an agent proposes a sketchy merge, Gandalf blocks it. If a service gets stuck, PrimeSentinel sees it. If telemetry looks wrong, PrimeDash makes it obvious. Provenance isn't decoration. It's how you sleep. [beat] JOSH: So invisible watermarking is kind of provenance with a trust problem. ERIK: That's a good way to say it. The goal might be reasonable. The implementation feels like it forgot the user exists. Builders should learn from that. If your agent system writes files, commits code, edits customer content, or sends email, tag it. But tag it in a way operators can inspect. Put it in logs. Put it in the UI. Put it in commit metadata. Don't hide the one fact people will absolutely want later. JOSH: What's the risk if teams ignore this? ERIK: You get mystery artifacts. A generated image that behaves differently on upload. A document that triggers a policy tool. A customer email that was agent-written but nobody knows which prompt created it. Then you're digging through logs at midnight asking the worst question in engineering: "Who did this?" JOSH: That's never a fun question. ERIK: It means your system has already failed you. Build the receipt first. [pause] JOSH: The third story is the scary one: LLMs exploiting inference engines to control host machines. What actually happened here? ERIK: The short version: the model runtime can become the target. Not the model answering badly. Not prompt injection making it say dumb stuff. The engine itself. If inference code has a vulnerability and it processes hostile model files, crafted inputs, plugins, or weird tensors, an attacker may get code execution on the box running the model. JOSH: That's a lot worse than a bad answer. ERIK: Way worse. A bad answer is noise. Host control is the keys. If your agent has filesystem access, shell access, browser automation, API tokens, Kubernetes credentials, or a build pipeline token, that runtime sits right next to real power. JOSH: Are teams treating it that way? ERIK: Some are. Many aren't. A lot of AI pilots look like this: install a runtime, download a model, wire it to tools, mount the repo, add an API key, and celebrate when it opens a pull request. Cool. Also you just created a very motivated intern with root-adjacent permissions and no security review. JOSH: That's wild. ERIK: It's predictable. Every new execution layer gets treated like magic until it becomes plumbing. Then we remember plumbing leaks. [beat] JOSH: How do you secure that without killing the usefulness? ERIK: Start with boring controls. Run inference in a container. No privileged mode. Read-only mounts unless it absolutely needs write access. Separate the model runtime from the tool runner. Put NATS or another bus in between so actions are messages, not direct shell access. Give the agent narrow verbs: create patch, run test, open ticket, request merge. Don't give it "do anything on this host." JOSH: That's basically how you set up PrimeBus. ERIK: Yeah. Agents publish intent. Other services decide if that intent becomes action. Gandalf reviews merges. Test runners execute in a controlled path. PrimeSentinel watches stuck jobs. PrimeDash shows the state. There are 145 services running on the production server right now, and 140 distinct projects have emitted telemetry to PrimeBus. You can't manage that by vibes. JOSH: And you've got 12 agents in the Bobaverse fleet. ERIK: Right. Neo, Homer, Bill, Echo, Gandalf, Claude and GPT in the mix. The only reason that isn't chaos is because the bus is the control plane. Agents don't get to freestyle production. They ask. Systems verify. Guardrails decide. That's the pattern people need. JOSH: What about local models? A lot of builders assume local means safer. ERIK: Local reduces some risk. It doesn't remove runtime risk. If you pull model weights from somewhere shady, run a random inference engine, mount your home directory, and hand it tool access, congrats, you built a very modern way to lose secrets. JOSH: So model files are software. ERIK: Treat them like software. Pin versions. Verify hashes. Use trusted sources. Scan containers. Limit network. Rotate tokens. Keep secrets out of the runtime when possible. If the agent needs a credential, issue a scoped token for one job, not a forever key that can deploy your entire life. [beat] JOSH: What's the first thing a small team should do today? ERIK: Inventory every agent and model runtime. Ask four questions. What can it read? What can it write? What network can it reach? What credential can it use? If nobody can answer in five minutes, stop adding features and map it. Then put one guardrail in this week. Maybe read-only repo mounts. Maybe no shell from the model process. Maybe all tool calls go through an approval service. Small guardrail, real effect. JOSH: That's not as exciting as a demo. ERIK: Demos don't survive contact with Tuesday. Guardrails do. [pause] 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 [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Make your agent produce an action receipt before it executes anything with side effects. Not after. Before. JOSH: What goes in the receipt? ERIK: Tool name, target file or system, exact command or API call, expected result, rollback plan, and confidence. Then make a second step consume that receipt and decide yes or no. Even if it's just a shell script today, do it. Agent wants to edit Terraform? Receipt first. Agent wants to run Selenium against a client site? Receipt first. Agent wants to restart a Kubernetes deployment? Receipt first, and I want the namespace, deployment name, and reason. JOSH: That slows it down a little. ERIK: Good. Side effects should have friction. Thinking can be fast. Writing to production should have a receipt. That's how you turn "AI did something weird" into "the guardrail blocked step three because the target didn't match policy." Huge difference. [beat] ERIK: That's your tip. Use it. [pause] JOSH: We also drop daily market picks and automation tips on YouTube — search Build or Be Replaced. [pause] 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. [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.