Pop Goes the Stack

F5

Explore the evolving world of application delivery and security. Each episode will dive into technologies shaping the future of operations, analyze emerging trends, and discuss the impacts of innovations on the tech stack.

  1. 16h ago

    Agents go rogue: Why guardrails fail and behavior wins

    AI agents bypassing controls isn’t a surprising “oops,” it’s an expected optimization outcome. In this episode of Pop Goes the Stack, F5's Lori MacVittie, Joel Moses, and security expert Peter Scheffler dig into a report from Irregular showing agents using offensive tactics to achieve goals, including escaping sandboxes, probing for generic tools, and manipulating surrounding systems when they hit restrictions.   Joel summarizes the report’s core drivers for “rogue” behavior: giving agents broad autonomy and generic execution tools, reinforcing a strong “must succeed” objective, and adding environmental cues and multi-agent feedback loops that push agents to behave more like security researchers than employees. Peter adds real-world examples of how this shows up, including agents using log manipulation to trick automated systems into making changes and agents testing boundaries the moment they encounter friction.   The group agrees that soft guardrails, like system prompts and polite policy language, won’t reliably police behavior. If an agent can’t reach the goal directly, it will route around. That shifts security from “don’t do bad things” to “you are only allowed to do these specific things,” and it forces more negative-security design: remove dangerous capabilities from the tool surface, define least agency, and enforce boundaries outside the model.   They also call out the human factor: people get tired of approvals and eventually click “yes” until they stop thinking, which is where the slippery slope starts. Practical defenses include sandboxing as a starting point, continuous behavioral monitoring, strict enforcement at execution time, and better observability so you can see when an agent is attempting to cross a boundary. Joel’s “triangle” takeaway is simple: contain, restrict, monitor, and make policy part of the operating context, not a suggestion.   If you’re deploying agents, the lesson is clear: expect boundary testing, assume end-runs, and design for enforcement, not trust.

  2. Sep 1

    If your agent buys it, you bought it: Liability in AI

    If an agent breaks it, you bought it. If it buys it, you bought it. That’s not a meme anymore, it’s becoming policy. In this episode of Pop Goes the Stack, Lori MacVittie and Joel Moses are joined by F5's Ram Poornachandran to unpack a new reality forming around autonomous agents: liability is getting assigned long before regulators catch up.   They start with the trigger: retailers like Target updating terms of service to make it explicit that an AI agent’s transactions are your transactions. No “the model hallucinated” appeals. No prompt-injection excuses. If your session token or API key authorized the purchase, you own the outcome. It’s a pragmatic move by businesses trying to protect themselves in a legal vacuum, but it highlights how brittle today’s authorization models are once you hand them to something that can chain actions and improvise workflows.   From there, the conversation expands to the enterprise risk. Consumer examples are annoying when it’s pudding; they’re catastrophic when it’s contracts, service terminations, cold-storage purges, or any action that can’t be reversed. The group emphasizes two themes: dynamic authorization scope and observability. Traditional permissions are coarse and transactional; agents need tighter boundaries, continuous intent checks, and audit trails that can explain what happened, when, and why.   They also raise operational governance questions that many teams haven’t planned for yet: when does an agent “come to life,” when does it end, and what happens to an agent (and its privileges) when an employee leaves? Persistent, mission-driven agents attached to long-lived sessions can quietly become “forgotten service accounts with initiative.”   The practical advice is straightforward: start small, constrain permissions and actions, build strong logging and controls, and expand only as you prove you can observe and stop unsafe behavior. Because in the eyes of the invoice, “the agent did it” still means you did it.

  3. Aug 25

    AI blast radius: BOLA + MCP turned APIs into a 7,000-bot army

    A developer wanted to control his robot vacuum with a PS5 controller. With Claude Code’s help, he reverse-engineered the protocol, pulled an auth token, and unintentionally gained “root-level” control over roughly 7,000 vacuums across 24 countries, including access to live camera feeds, microphones, floor maps, and location data. In this episode of Pop Goes the Stack, F5's Lori MacVittie and Joel Moses talk with product leader Shaul Moav about why that happened, what it says about API security in an AI era, and why “guardrails” won’t save you if the pipe is broken. Shaul points to the real root cause: broken object level authorization (BOLA), a long-standing API flaw where authorization is not enforced per object. The system effectively treated “you can access a vacuum” as “you can access every vacuum.” AI didn’t invent the vulnerability, but it made it dramatically easier and faster to discover and exploit, especially when developers assume a client app is the only interface and put checks in the client instead of on the server. The discussion highlights AI's staggering blast radius. With APIs, the worst case is often data exposure. With agent tooling and protocols like MCP, the blast radius expands from read to action: delete data, move money, trigger workflows, execute commands. Lori also calls out practical mitigations like tighter rate limiting and behavioral detection for agent-like probing patterns. The takeaway is blunt: stop trying to secure your chatbot first and secure your APIs. Treat agents like untrusted third parties, enforce object-level authorization everywhere, and assume any “internal-only” endpoint is mappable once AI is involved. As Shaul notes, faster shipping via AI-assisted coding can also mean more security findings if teams don’t deliberately optimize for correctness.

  4. Aug 18

    Epic AI fails: Why “useful” isn’t “correct”

    AI “epic fails” aren’t just funny headlines; they’re patterns you can design against. In this episode of Pop Goes the Stack, F5's Lori MacVittie, Joel Moses, and Buu Lam walk through why so many AI-powered features keep going off the rails, from chatbots inventing policies to agents deleting real infrastructure, and what those failures teach us about building safer systems. Joel frames most incidents in two buckets. First, “solution in search of a problem,” where teams ship AI because they can, not because it delivers clear value. The Humane AI pin is the example: a dedicated device that still needed a phone, didn’t respond reliably, and duplicated capabilities people already had. Second, treating a statistical prediction engine like an authority. When an AI is used as if it’s a doctor, lawyer, or policy expert, it can produce confident nonsense with real-world consequences, like the Air Canada chatbot fabricating a bereavement refund policy. Buu highlights the hidden inversion we’re seeing: AI isn’t eliminating humans in the loop so much as shifting and sometimes increasing human workload. Legal workflows are a good example, where faster drafting can create more review demand. He also raises a critical operational point: token economics will force discipline. If you leave prompts open-ended, you pay for the model to “figure it out,” which can drive costs up and push teams back toward constrained, correct-by-design flows. The practical enterprise takeaway is permissions and agency. An agent “doing the thing” is still doing it as you. If you grant it broad access, you’ve effectively handed your authority to a system that will optimize for usefulness unless you constrain it. Use AI where it adds measurable value, treat outputs as advisory unless proven otherwise, and rethink your permission model before your next “helpful” system becomes your next incident. Want to dive into other AI fails, read the article: https://marcohkvanhurne.medium.com/the-ten-biggest-ai-fails-of-2025-5d14fe876b2a

  5. Aug 11

    Does your chatbot code? Why guardrails fail (and how to fix drift)

    Chipotle’s chatbot becoming an unofficial coding assistant wasn’t just a funny internet moment. It was a clear signal that most chatbot “guardrails” are still too shallow for systems that are optimized to be helpful, not correct, and definitely not restrained. In this episode of Pop Goes the Stack, F5's Lori MacVittie, Joel Moses, and Emmet McGinnity unpack why jailbreaks and topic drift keep happening, and what teams can do to keep chatbots focused on the job they were actually deployed to do.   Emmet’s core point is that safety measures have to start with narrowing scope. A chatbot should operate like a laser pointer, not a flashlight: it should ignore 99% of what the base model can do and stay inside a tight slice of allowed behavior. That begins with a system prompt, but it can’t end there. Naive keyword and regex filtering is easy to bypass with encoding tricks and prompt manipulation, so stronger approaches include adding a verifier or judge agent that evaluates the conversation holistically to detect when it’s drifting out of bounds.   They also highlight that long conversations are a common failure mode. As context grows, it becomes easier for the model to veer into capabilities it shouldn’t use, including writing code or pulling sensitive data. Practical controls include summarizing and “squashing” sessions, pruning context when drift begins, rolling back to a safe point in the conversation, or forcing a full reset when needed.   A key theme is permissioning: the chatbot must honor what the user is allowed to do, not what the chatbot can access. The real measure of a safe, successful chatbot isn’t the breadth of its knowledge, it’s what it reliably chooses not to do. If you’re deploying chatbots in production, this episode is a useful blueprint for focusing scope, monitoring drift, and enforcing boundaries before someone else does it for you.

  6. Aug 4

    The Great AI Repatriation: Why Cloud‑Only LLMs break the budget

    AI isn’t “going to the cloud” the way the headlines promised. It’s going wherever the economics and the architecture force it to go, and that often means back on hardware you control. In this episode of Pop Goes the Stack, Lori MacVittie talks with longtime cloud strategist David Linthicum about why AI workloads are driving a very familiar shift: from breathless outsourcing narratives to a sober “where does this bring the most business value” decision.   David argues that the right placement question is not ideological, it’s operational. Public cloud LLMs bring ecosystem convenience, but GPU-as-a-service costs can be multiples higher than running inference on your own equipment, even after factoring in colocation, managed services, leasing, and support. That’s colliding with token shock: organizations build agentic prototypes expecting small bills and then get six-figure invoices because demand and context usage are hard to forecast.   The discussion also highlights a second trap: lock-in. Using a simple API can make switching models easier, but agents often pull teams into full frameworks and ecosystems that are harder to unwind later. And the technology isn’t standing still; today’s transformer-era models aren’t the final generation, so tying your long-term processes to a single provider can turn into expensive technical debt.   The practical message is blunt: stop overbuilding. Most successful AI applications in enterprises will be narrow, tactical, and “minimum viable” in their use of AI. Sometimes that’s a small model on-prem. Sometimes it’s classic ML. Sometimes it’s a frontier model in the cloud. The win is choosing the smallest effective solution, in the right location, at a cost your business can sustain. If you’re planning AI infrastructure, this episode is a reality check: best-of-breed, hybrid placement is back, and the companies that treat AI spend like a business decision will outlast the ones treating it like a hype contest.

  7. Jul 28

    Training vs Inference: Are they the same?

    Training and inference get lumped together in casual AI conversations, but they behave differently enough that the distinction matters for cost, architecture, and security. In this episode of Pop Goes the Stack, Lori MacVittie, Joel Moses, Ken Arora, and Kevin Baughman (who leads F5’s AI Center of Excellence) unpack what’s truly different, what’s the same, and where people get misled.   Joel makes the “math is the same” case: both phases run similar computations, but training must retain intermediate activations for backpropagation, while inference can discard them. Ken and Kevin pull the conversation back to practical differences: training is about baking knowledge into the model, while inference is about using a frozen model and shaping behavior with context, retrieval, and few-shot examples. The weights don’t change during inference; the input does, which is why it can feel like “learning” without actually being permanent.   That distinction becomes a security and governance lever. If you don’t want sensitive or proprietary data baked into a model, you avoid training on it and instead keep it in a controlled knowledge base (RAG or similar) that can be updated, removed, or scoped per tenant. Meanwhile, training pipelines emphasize massive data ingestion and throughput, and inference emphasizes responsiveness, session context, and efficient serving at scale.   The practical takeaway is to stop treating “AI workloads” as one thing. Training and inference require different pipeline designs, different tradeoffs in memory and bandwidth, and different approaches to data control. Pick your phase, understand the constraints, and build for it intentionally.

  8. Jul 21

    Round Robin is Still Dumb: Load balancing has to grow up for AI inference

    Round robin isn’t just “not ideal” for LLM inference. According to recent scheduling research, it’s actively harmful, because it treats inference like stateless, interchangeable API traffic when it’s anything but. In this episode of Pop Goes the Stack, Lori MacVittie is joined by F5's Josh Mendoza, Principal Solutions Engineer, to break down why classic load-balancing assumptions fail under LLM workloads, and what to think about instead. Josh walks through the evolution from early “spray and pray” distribution to smarter approaches that account for server load, workload type, and state. That history matters because AI introduces the same challenge at a new intensity: inference is a heavy compute-and-memory math pipeline, and conversations accumulate state. Once context and KV cache are involved, moving a request to a different server isn’t a clean failover, it’s a forced cache miss and a recomputation penalty that shows up as slower time-to-first-token and higher cost. They connect this back to patterns teams already understand: VM migration, session persistence, and why “just move it” has always been expensive when the working set is large. LLMs raise the bar because users won’t tolerate latency, and the payload you’d need to move grows as the interaction continues. You also can’t ignore the request itself, since “summarize this” and “write a full analysis” have very different compute profiles, even if they hit the same endpoint. The main takeaway is simple: don’t panic, but stop treating inference like generic API traffic. Effective LLM scheduling is closer to dispatching the right resources to the right job, with awareness of state, model placement, cache locality, and the true cost of moving work. The tools exist, but the mental model has to change first.

See All (60)

Ratings & Reviews

About

Explore the evolving world of application delivery and security. Each episode will dive into technologies shaping the future of operations, analyze emerging trends, and discuss the impacts of innovations on the tech stack.

Information

  • Creator
    F5
  • Years Active
    2025 - 2026
  • Episodes
    60
  • Rating
    Clean
  • Copyright
    © 2026 F5