u/OReilly_Learning

AI in pilot and AI in production are completely different. Traffic is unpredictable, data is scattered across separate systems, and things that worked fine in testing start to break under real concurrency and scale. 📉

Our new O'Reilly report, 'Why Distributed SQL Is the Modern Foundation for AI,' breaks down the architectural decisions required to keep AI systems consistent and scalable once they're live.

https://info.yugabyte.com/report-why-distributed-sql-is-the-modern-foundation-for-ai-oreilly

Walk away with an action plan for keeping transactional data, vector embeddings, and unstructured content working from one consistent, current source of truth.💡

Download your complimentary copy today! 🙌

Now is your chance to build your Linux Learning Library at a good price.

You can choose the size of package you want or get all 15 books in PDF for 25 dollars and support charity.

I wrote a piece for O'Reilly Radar about the agent failure that never makes the post-mortem, because nothing visibly fails: https://www.oreilly.com/radar/prompt-injection-to-data-exfil-in-3-hops/

Disclosure up front: I work at Aviatrix, which sells one of the products in the category the article describes. The piece is deliberately layer-neutral: Cilium FQDN policy, service meshes, and cloud-native firewalls all enforce the same control, and the article covers this. The argument is about the category, not any product.

The chain is three hops of everything working as designed. Prompt injection hidden in a support ticket -> legitimate MCP tool call -> HTTPS egress to an attacker domain: no CVE, no stolen token, no compromised process. The agent did exactly what it was permitted to do.

Why NetworkPolicy doesn't help: it operates at L3/L4 and cannot tell api.github.com from attacker.example.com when both resolve into the same rotating CDN range. Allow 0.0.0.0/0 on 443, and the agent reaches everything. Deny it and the agent cannot reach its own model API.

The CIDR allowlist most teams settle on is the worst of both: it holds the legitimate API, plus every other tenant of that CDN, including the attacker. A firewall rule that permits both your API and your adversary is not a security boundary. It's a formality.

Guardrail models don't rescue this either. One that catches 95% of injections still loses, because the attacker controls the input, retries for free, and needs only one success against an action that cannot be undone. Answering a probabilistic attack with a probabilistic defense is like teaching a guard dog not to eat steak.

What works: deterministic egress containment. Per-pod identity, domain-aware policy read from SNI, default-deny on everything undeclared. What this does not close: exfil via permitted destinations, and DNS tunneling. What it does is shrink the reachable set to the handful of domains you declared, and force attackers onto slow, noisy channels you can actually watch.

The questions for you:
For every MCP server in your cluster, can you name the external domains it must reach and must never reach?
Has anyone shipped default-deny FQDN egress for agent workloads, and what broke first?

If you're interested in trying it out, we have a 30-day code to share. https://www.oreilly.com/online-learning/verifiable-skills.html

I'm excited to announce that the 3rd edition of "Learning Go" is now available in Early Release!

The full book is scheduled for 2027. This edition is updated to cover the most recent Go releases. It also adds:

• More code review advice
• New exercises
• A brand-new chapter on monitoring and observability

If you have an O'Reilly Online subscription, you can read the preface and the first two revised chapters now: https://learning.oreilly.com/library/view/learning-go-3rd/0642572348533/

#golang #programming #softwareengineering