{"slug": "immunity-agent-the-control-plane-for-ai-agents-intercept-policy-audit", "title": "immunity-agent: the control plane for AI agents — intercept, policy, audit", "summary": "PrismorSec released immunity-agent, an open-source control plane for AI agents that intercepts tool calls to enforce policies, audit actions, and prevent six common failure modes including overpermissive defaults and prompt injection. The agent-agnostic layer works with OpenAI Agents SDK, MCP-native agents, LangChain, and other frameworks without requiring code changes.", "body_md": "Every cloud engineer knows IAM. Not because it's fun, but because you learned the hard way what happens without it. Someone gets a key. Blast radius is bad. You add policies, audit logs, least-privilege rules, and a lot of regret.\n\nWe're at that same moment with AI agents. Except most teams haven't had the incident yet.\n\nWhen an agent runs in production with access to tools — your file system, your APIs, your databases — what stops it from doing something it shouldn't? Usually the answer is: nothing. There's no interception layer. No per-user policy. No audit log that security can read. Just vibes and hope.\n\nThat's what [immunity-agent](https://github.com/PrismorSec/immunity-agent) is built to fix.\n\nIt sits between an agent's reasoning layer and the tools it executes. Every tool call passes through it before anything runs. The agent doesn't need to be rewritten. The tools don't change. immunity-agent is the enforcement layer in the middle.\n\nYou can trace most production agent incidents to one of six failure modes. I know because I spent a long time staring at them.\n\n**1. Agents are overpermissive by default.** A coding agent that needs read access to one repo gets write access to all of them because nobody scoped it down. It works fine until it doesn't.\n\n**2. External attacks land through the agent.** Prompt injection from a malicious webpage. A typosquatted package that runs on install. The agent is the attack surface, and the attack surface is huge.\n\n**3. Nobody can see what the agent touched.** Security asks \"what did the agent do on Tuesday?\" and the answer is shrug. No tamper-evident log. No audit trail at all.\n\n**4. Agent actions aren't tied to a human.** The agent acts. Something breaks. Who authorized that? In cloud infrastructure, every action is attributed to a principal. In most agent stacks, it's attributed to nobody.\n\n**5. Developers approve everything.** The agent asks \"should I deploy this?\" and the developer clicks yes without reading it because they've clicked yes forty times today. Approval theater isn't access control.\n\n**6. Too much autonomy inside a single tool.** You gave the agent access to `run_query`\n\n. That doesn't mean it should be able to run `DROP TABLE`\n\n. Parameter-level scoping exists for cloud resources. Almost nobody's doing it for agent tools.\n\nimmunity-agent addresses all six. Not by wrapping your agent in a new framework — by intercepting at the execution layer and applying policy before anything runs.\n\nA control plane governs behavior across a system. The data plane is where work happens. The control plane is where you decide what work is allowed, by whom, under what conditions.\n\nIAM is the control plane for cloud infrastructure. Firewalls are the control plane for network traffic. immunity-agent is the control plane for agent actions.\n\nThe analogy isn't decorative. The architecture follows the same pattern: centralized policy, distributed enforcement, real-time audit, per-principal scoping. Org-wide defaults, team-level overrides, per-user exemptions. Pull policy from version control, apply it without touching agent code.\n\nWorks with OpenAI Agents SDK, MCP-native agents like Claude Code and Cursor, LangChain, CrewAI, LlamaIndex, and anything else that dispatches tool calls.\n\nThe six failure modes don't stop at code agents. A robot arm that runs arbitrary motion commands without policy enforcement has the same problem as a coding agent with unchecked file access. The consequences are just physical.\n\nimmunity-agent's architecture extends to physical agents through a policy evaluation API. Same six dimensions, same control plane model, different runtime.\n\nAs agents get more capable, this matters more. Not less.\n\nThe repo is at [github.com/PrismorSec/immunity-agent](https://github.com/PrismorSec/immunity-agent).\n\nIf you're running agents in production and you can't answer \"what did my agent do, on whose behalf, and what would have stopped it from doing something worse\" — that's the gap immunity-agent closes.", "url": "https://wpnews.pro/news/immunity-agent-the-control-plane-for-ai-agents-intercept-policy-audit", "canonical_source": "https://gist.github.com/solar-flare99/07df64019219a686a6a051fc031f05a4", "published_at": "2026-06-29 03:56:56+00:00", "updated_at": "2026-06-29 04:26:56.925466+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "developer-tools", "ai-policy"], "entities": ["PrismorSec", "immunity-agent", "OpenAI Agents SDK", "Claude Code", "Cursor", "LangChain", "CrewAI", "LlamaIndex"], "alternates": {"html": "https://wpnews.pro/news/immunity-agent-the-control-plane-for-ai-agents-intercept-policy-audit", "markdown": "https://wpnews.pro/news/immunity-agent-the-control-plane-for-ai-agents-intercept-policy-audit.md", "text": "https://wpnews.pro/news/immunity-agent-the-control-plane-for-ai-agents-intercept-policy-audit.txt", "jsonld": "https://wpnews.pro/news/immunity-agent-the-control-plane-for-ai-agents-intercept-policy-audit.jsonld"}}