This is one of the best public internal AI stories we've seen, built by just a few engineers. Derek Meegan, a software engineer at Browserbase and the lead behind their internal AI agent, bb, joins us to explain how bb took feature-request coverage to 100% with zero human effort, got 99% of support first responses under 24 hours, and turned 30 to 60 minutes of manual log-diving into a single Slack message.

Then we get into the part most teams skip: the security model that lets you actually trust an agent with that much reach.

Derek covers code mode, the sandbox that never touches a secret, credentials brokered just-in-time through an integration proxy, least-privilege tools on every event-driven trajectory, and permissions computed per invocation instead of written into a static config.

His thesis: use the agent to take the repetitive, well-understood work off people's plates, and make the harness verifiably secure, because security is what lets you scale it.

David Cramer, CPO and co-founder of Sentry, joins us to cut through the agent hype with a working engineer's skepticism: the model is rarely what holds agents back. The harness you build around it is. We get into the Railway incident, where a coding agent found a stray CLI token and deleted a production database (and every backup) in nine seconds, and why the enforcement layer has to live below the agent, not in an advisory system prompt.

David explains Seer, Sentry's AI debugger, as the counter-example: an agent doing real work because it was given the right context, not more autonomy. He also walks through Warden, the code-review harness he built that found 100+ previously unknown vulnerabilities across Sentry and open-source projects, including full auth bypasses, for roughly $1K of compute.

We also get his contrarian-but-consistent take on why MCP is not just a shim on your API, why CLIs are harder to secure than people think, and why verification, not code generation, is still the unsolved problem.

Herman Errico, Product Manager for Technical Research at Vanta, joins us to discuss AARM (Autonomous Action Runtime Management), the spec he created to define a brand-new security category for agents that take real actions, not just generate text. We get into why the action boundary is the security boundary, why securing the model, prompt, or orchestration layer is the wrong place to enforce, and why a runtime needs five authorization decisions (allow, deny, modify, step-up, and defer) instead of a binary yes or no. Herman also explains why he didn't ship a product but a spec, then donated it from Vanta to the Cloud Security Alliance so the industry can compete on execution instead of marketing, how to reason about which context an agent can trust, and why you must block the action from occurring before it takes place.