This framing hits the core insight: source map leaks aren't the exploit—they're the context amplifier.

The three-layer mental model (Exposure → Authorization → Execution) maps directly to how production agent systems fail in practice:

1. Exposure layer: MCP endpoints and tool schemas are the new .env files—everyone commits them somewhere.
2. Authorization layer: The "which agent can call which tool" question becomes unmanageable when agents can spawn subagents or call MCP servers indirectly.
3. Execution monitoring: Most teams have HTTP metrics but zero visibility into agent task chains.

What I keep seeing: teams instrument the middle box (identity, roles, approvals) and ignore the top and bottom. That's where incidents compound.

The agent-audit approach is smart—scan for exposure before deploy rather than hoping monitoring catches it in production. The blast radius question is underrated: a leaked API key is bad, but a leaked API key plus a tool schema that shows exactly what that key can do is an order of magnitude worse.

One gap worth addressing: auditability in under 10 minutes is table stakes for incident response, but most agent frameworks make this harder than it should be. The execution logs exist somewhere (API traces, MCP server logs, model provider dashboards)—the work is correlating them back to a single task ID.

Would be curious how you handle recursive agent chains in monitoring. If agent A spawns agent B which calls tool C—do you trace the full lineage, or just the immediate invocation?