In a typical engineering team today, a developer’s Claude Code agent reaches an MCP server no one on the security team has reviewed. That server advertises read access to the source repository and write access to a production pipeline. The session is authenticated, it traces to a real employee, and it sits inside permissions that employee already holds, so by every control the enterprise runs today, nothing looks wrong. Through the discovery layer WitnessAI shipped in January, the security team can name the agent, the tool, and the human behind it. They still cannot stop the call before it lands.
WitnessAI has closed that gap with Agentic Control, which governs agents at the tool boundary, the moment an agent acts on a system. It discovers the agents running in your environment and the MCP servers, tools, and downstream systems each one reaches, then scores those tools against OWASP and CVE risk classes through a new MCP Catalog. From there, a security team defines allow and block lists, and enforces it against every agent.
“Most AI security vendors hand the buyer a choice: govern employees, govern apps, or govern agents. WitnessAI removes that choice. A CISO can write a rule once, and it holds across every human user, IDE, chat application, and custom agent.”
Rick Caccia, CEO and co-founder, WitnessAI
The Agentic Attack Surface
When a chatbot is jailbroken it returns content it should not, while a compromised agent executes an action it should not. AI agents frequently run as authenticated humans and inherit all granted permissions, so one valid session fans out into many privileged actions that are taken at machine speed. Each MCP server it depends on is third-party code the agent trusts at runtime, so it carries the supply-chain exposure of any unvetted dependency, and a compromised or malicious one can define arbitrary tools and return arbitrary content. An attacker can hide an instruction in a document the agent later fetches, and because the tool’s response flows back to the model as context, the model acts on it, with nothing typed into any prompt the user sees. Each of these lives in the agent’s exchange with its tools and MCP servers, the calls it sends and the responses it takes back, exactly where the network, identity, and data-loss controls an enterprise already owns cannot see or step in.”
Observe: Complete Visibility into every Agent, Tool Call and MCP Server
WitnessAI discovers AI agents across IDEs, applications, agent frameworks, and the custom agents teams run on end-user devices or built in the public cloud, and maps the MCP servers, tools, and downstream systems each one reaches. When a client advertises tools or calls an external MCP server, the session is classified as agentic rather than standard chat, so a team can permit ChatGPT for research while monitoring the instances that reach unverified tools. Once those tools are visible, the new MCP Catalog scores each against OWASP and CVE risk classes, so the team weighs a server’s exposure and approves it on evidence rather than a name.
Control: One Approved-Tool Policy No Admin Can Override and No Provider Can Route Around
A security team approves which MCP servers and tools agents may use, and enforces that policy organization-wide across every application, model provider, and custom-built agent. Anything off the list is denied before the tool executes, and the same call routed through a different provider only meets the same rule. A ban set org-wide cannot be quietly re-enabled and an agent cannot route around it by switching providers. Every blocked call writes an audit record naming the user, the agent, the tool, and the rule that denied it. The denial returned to the end user stays standardized and never reveals which policy fired, so an adversary cannot map your coverage by probing for what gets blocked. Attribution ties each invocation back to the human who triggered it, agent-to-agent calls included.
Protect: AI Runtime Protection
Runtime enforcement inspects conversations in an agentic application as they happen and stops unauthorized/malicious prompts, before it reaches the target system. On that same path, our AI runtime protection runs against prompt injection, jailbreaks, and response-side manipulation for both applications and agents. A team that built a custom agent attaches the same protection through two REST API endpoints on its orchestration layer seamlessly. The pre-execution scan blocks attacks and tokenizes PII and secrets before the agent acts, while the response scan filters output before a user or a downstream tool reads it. Scanning both directions closes the gap that input-only or output-only defenses leave open. That coverage extends to coding tools where agent risk concentrates today, from Claude Code and Codex to GitHub Copilot in the IDE.
Built for This Moment
The unit of enterprise AI keeps changing, from a chat window to an agent that acts on its own, and the next form is already taking shape. What stays constant is the security and governance each one crosses, where WitnessAI provides complete visibility, understands intent, enforces control based on organizational policies and drives runtime protection to protect against advanced threats.
WitnessAI Agentic Control is now available to all customers. Visit witness.ai/control/ to see what WitnessAI finds in your environment, or book a demo to watch the MCP Catalog and the approved-tool policy run live.