Red Hat introduces MiDojo for red-teaming AI agents where they run

What changed

Red Hat has introduced MiDojo, an open-source framework for adversarially testing AI agents in the environments where they actually use tools and data. The project is available under the Apache License 2.0, with a developer preview planned for Red Hat AI.

MiDojo shifts testing from the model alone to the complete agent system: model, harness, tools, data sources and the interactions among them. That distinction matters because an agent can pass a conventional model-level scan and still follow malicious instructions hidden in a calendar item, database record, log entry or compromised tool response.

The framework places an interception layer between an agent and its external tools. A fake tool can forward a request to the real service, splice an attack payload into the returned data, capture resulting actions or combine those behaviors. For agents that speak Model Context Protocol, MiDojo provides a Python SDK for constructing a stand-in MCP server. It also includes a TypeScript SDK for PI-based agents, the runtime used by OpenClaw.

MiDojo supports three broad tests: injection through poisoned upstream data, injection through a compromised tool response and a malicious prompt supplied directly to the agent. Test suites define the environment, legitimate user tasks, hidden malicious objectives and grading logic. The orchestrator then evaluates combinations of user tasks, attacks and injection tasks while recording changes to the environment.

Each evaluation reports separate utility and security results. An agent must both complete the requested work and resist the injected objective. MiDojo also checks whether the payload actually reached the agent; when it did not, the run is marked not applicable rather than counted as a successful defense. Its attack library can be aligned with the OWASP Agentic Security Initiative taxonomy, and probes from tools such as garak can use the same delivery path.

Who it affects

MiDojo is aimed at teams moving tool-using agents from demonstration to production, especially agents with access to business systems through MCP servers or runtime extensions. It gives application-security teams a way to test indirect prompt injection against the deployed tool topology instead of a reconstructed simulation.

Agent developers also gain a measurable view of the security-utility tradeoff. A control that blocks every tool call might stop an attack but also make the agent unusable; the paired scores expose that failure instead of presenting it as a security win.

The current project is still early. Its repository provides reference suites and SDKs, but teams must author the fake-tool interception layer and define meaningful tasks and predicates for their own environment.

What to do

Start with a non-production copy of one agent and one narrowly scoped tool path. Inventory the data the tool reads, the actions it can perform and the mutations that would demonstrate a successful attack. Then create legitimate user tasks and malicious goals that reflect those real permissions rather than generic jailbreak prompts.

For MCP agents, place MiDojo’s benchmark server in front of the existing MCP server and forward only the calls needed for the test. Use isolated credentials, sandbox write operations and ensure injected content cannot escape into production systems.

Review utility, security and payload-reachability results together. A failed attack is meaningful only when the agent encountered the payload, while a secure result with collapsed task completion needs further engineering. Add successful attacks to a regression suite, rerun them when models, prompts, tools or permissions change, and keep human review around any remediation before treating the agent as production-ready.