An agent can return a reassuring answer after it has already leaked a credential, crossed into another user's data or deleted something real. The threat model becomes concrete in Casco's security test of 16 public YC agents. The controls follow the paths those attacks used. Sandboxes isolate execution; default-deny capabilities limit what code can reach; credential and network gateways keep secrets outside the agent while enforcing policy on its traffic. OAuth and production MCP design add identity and scoped authorization once the runtime boundary is sound. Another risk arrives before execution: coding agents can invent dependencies, while shared skills can carry dangerous instructions or permissions. Generated code and agent components therefore need a separate security review before anyone runs them.
Why start here: Meijer gives the pack its threat model: tool calls give a model claws, while private data and untrusted input complete the lethal trifecta. Brandel follows with what those abstract ingredients look like in systems people had already shipped.
Why here: Meijer warns that unsafe actions can hide behind a safe-looking answer. Brandel finds the ordinary routes to those actions: cross-user ID traversal and an SSRF request that leaks repository credentials. Matin comes next because both attacks get worse when the agent can execute code or reach the network freely.
Why here: Brandel shows custom execution environments exposing the infrastructure around them. Matin answers with an agent's own isolated computer and strict network access, then Agrawal makes those two controls concrete by asking exactly which capabilities the code needs.
Why here: Matin establishes the sandbox and network restriction as system-level controls. Agrawal supplies the operating rule: enumerate what to allow and keep every real secret outside the sandbox. Guercio then shows how a network gateway can provide the missing access without handing the credential back to the agent.
Why here: Agrawal keeps secrets in the host and proxies the calls that need them. Guercio moves that idea to an identity-aware network gateway, where every request can be seen and limited. Dahl follows because HTTP and model traffic are not the only routes out of an agent.
Why here: Guercio controls credentials and observes requests at an LLM gateway. Dahl drops the policy below HTTP, where it can catch a psql subprocess trying to delete a table on the wire. Hanson comes next to explain how legitimate access should be issued and carried once the dangerous routes are blocked.
Why here: Dahl keeps credentials outside the agent and enforces what each connection may do. Hanson supplies the authorization model behind that boundary, replacing static keys with scoped tokens that follow a chain of services. Shwe and Frenay then apply the same problem to an MCP server headed for production.
Why here: Hanson explains the OAuth roles and the chain of authorization between agents and services. Shwe and Frenay show why that is necessary but insufficient for MCP: every exposed tool is another door, and long-lived keys can turn the server into a confused deputy. Yegge widens the security review from services to generated code and its dependencies.
Why here: Shwe and Frenay reduce what an MCP server exposes and control who may call it. Yegge turns to what the coding agent pulls in, including invented package names that attackers can register, and argues that security needs its own pass. Palma ends the pack with a working review gate for one fast-growing class of dependencies.
Why end here: Yegge asks teams to give security a separate pass over generated code and dependencies. Palma shows the institutional version: treat shared skills as dependencies, scan them deterministically and in context, then stop serious findings before they reach the marketplace. The pack ends with a gate a real organization has already put into use.