DEV Community: Neethu E V

Securing the AI Agent Era: Why We Just Open-Sourced Agent OPFOR 🚀

Neethu E V — Tue, 07 Jul 2026 11:10:30 +0000

As Product Managers and developers, we’re all racing to build the future with AI agents, LLM-powered apps, and Model Context Protocol (MCP) servers. It’s an incredibly exciting time to build. But as we give agents more autonomy—allowing them to call tools, read databases, and execute code—we face a massive, looming question:

How do we actually ensure they are safe, reliable, and production-ready?

Traditional application security testing doesn't quite cut it when dealing with the unpredictable nature of LLMs. Prompt injections, data exfiltration through tool calls, and biased decision-making require a completely different approach.

That’s why my team at Netra built Agent OPFOR—and today, we are officially open-sourcing it for the entire developer community!

What is Agent OPFOR?

Agent OPFOR is an open-source adversary emulation and red-teaming toolkit purpose-built for AI agents, LLM applications, and MCP servers.

Think of it as your automated, terminal-driven chaos monkey for AI security. It acts like a real attacker: it automatically generates sophisticated, adversarial attack prompts mapped to industry risk frameworks, fires them at your target agent or MCP server, and uses an LLM judge to grade the response.

Instead of guessing where your AI might break, you get an actionable HTML report for your team to browse and a JSON report to plug right into your CI/CD pipeline.

How It Protects Your AI Infrastructure

When designing the product roadmap for Agent OPFOR, we focused on three core pillars to make security testing seamless for engineering teams:

1. Automated Red-Teaming & LLM Judging

Manually thinking up prompt injections is exhausting and hard to scale. Agent OPFOR automates the entire offensive pipeline.

For Agents: It targets HTTP endpoints or local chat scripts, dynamically writing adversarial prompts to see if your agent misbehaves.
For MCP Servers: It connects to your server, enumerates your tools, crafts malicious tool-call payloads, and tests if your backend logic handles them safely.

2. Guardrails Mapped to Industry Standards

We didn't just throw random prompts at a wall. Agent OPFOR ships with curated test suites that map directly to critical compliance and security benchmarks:

OWASP Top 10 (covering LLM Apps, Agentic AI, MCP, and API Security)
EU AI Act bias and fairness frameworks

3. Built for the Entire Team (5 Ways to Run It)

Security shouldn't just be a developer's job. We built five distinct entry points so everyone on a product team can use it:

💻 CLI: opfor setup ➔ opfor run. Built for engineers and automated CI workflows.
🌐 Browser Extension: A code-free way for QA, PMs, and security analysts to run attacks directly from any chat UI.
🔌 MCP Server: Run Opfor as an MCP server so AI coding tools like Cursor or Claude Desktop can drive your security testing natively.
🤖 Skills: Slash commands (/opfor-setup) right inside your AI coding agents.
📦 SDK: A flexible Node/TypeScript SDK (@keyvaluesystems/agent-opfor-sdk) to run scans programmatically in your code.

Why Open Source?

At Netra, we firmly believe that the future of reliable AI infrastructure depends on transparency and collaboration. Security cannot happen in a silo. By opening up Agent OPFOR, we want to give developers the tools they need to build securely from day one, while collaborating with the global security community to keep our attack libraries cutting-edge.

Get Started & Support the Launch! ⭐

Whether you are scaling internal developer workflows, building custom RAG apps, or launching customer-facing agents, trust begins with security. We’d love for you to try it out, give us feedback, and break some agents!

📂 Check out the code: github.com/KeyValueSoftwareSystems/agent-opfor
📖 Read the docs: docs.agentopfor.ai

If you love what we're building, please drop a star ⭐ on our GitHub repo! It takes 30 seconds and helps our open-source launch reach more developers who need to secure their AI.

Let me know in the comments: How are you currently testing your AI agents for security vulnerabilities? Let's discuss!

I have talked to dozens of AI teams about production. The same things keep breaking.

Neethu E V — Wed, 13 May 2026 09:26:35 +0000

I have been a PM at NETRA long enough to have had the same conversation about 40 times.
An AI team reaches out. They're building something serious in the agent space, a customer-facing agent. Things are moving fast. Shipping is happening.
And somewhere in the first ten minutes, they describe the same problem in different words.
"We got to know that the quality had dropped from a user complaint."
"Our costs spiked and we saw it in the monthly finance review."
"We changed the prompt three weeks ago and we're not sure if that's what caused this."
Every time. Different team. Different product. Same pattern.

What's actually happening?
These aren't careless teams. Most of them have logging. A few have dashboards they check regularly.
But there's a consistent gap between what their tools tell them and what they actually need to know.
Their tools answer: is the system running? Did something break? What happened on this specific request?

What they actually need to know: is the agent's performance getting better? Are users getting a worse experience than last week post release? If the agent performance is drifting from its expected behaviour, would we catch it before a user does?
Those are different questions. And most of the tooling AI teams have right now was built for the first set, not the second.
The gap isn't a monitoring gap. It's a visibility gap. Most AI teams can tell you if their AI system is healthy. Very few can tell you if its improving.

The three failure modes I keep seeing:

After enough of these conversations, the patterns get predictable.
The prompt change nobody could validate A developer updates the system prompt. Runs a few manual checks, looks good, ships it. Three weeks later I get to know that- a user is saying the agent's been giving weird answers lately through a complaint raised. The developer goes looking. No baseline. No before and after. No way to connect the complaint to the release. Just logs from a period when everything appeared to be working fine.
The cost spike that showed up in a meeting A new model version gets deployed. More capable, slightly more expensive per call. Usage patterns shift in ways nobody anticipated. The cost delta doesn't show up in anyone's dashboard. It shows up two weeks later when finance flags it. The engineering team gets a message asking to explain the increase.
The quality drop nobody noticed Gradually, imperceptibly, the agent starts giving slightly worse answers. No exceptions thrown. No error rates spiking. The system is technically healthy by every measure the team has. Users just slowly have a worse experience. Someone on customer success eventually notices a pattern in support conversations. By then it's been weeks.

Every single team I've talked to have a version of at least one of these stories.

What changes when evals, simulation and alerts are in place
I'm not going to pretend this is a magic fix. It takes defining what good looks like for your specific product. That part is on you.
But here's what I've seen consistently on the other side of that work.
Teams stop finding out about quality drops from users. They catch them first, sometimes weeks before a user would have noticed. Prompt changes go from "we think this is better" to "we can show this is better." In Netra, scored comparisons against real user queries, before and after each change, tied to the exact version shipped. The shift from gut feel to actual data changes how confident teams are going into releases.
And cost spikes stop being surprises. Alert rules tuned to AI-specific signals mean the team finds out first, not accounting.
The shift isn't just operational. It changes how teams make decisions. "We think it's better" becomes "we can show it's better." That's a different kind of confidence going into every release.

Why I keep bringing this up to developers?
Honestly? Because most developers I talk to are building AI products right now with an observability layer that was designed for something else, still doing manual testing- which is the age-old approach.
Infrastructure monitoring was built for deterministic systems. Up or down. Pass or fail. AI products aren't deterministic. They drift. They degrade. They change in ways that don't look like outages but matter just as much to users.
Evals and alerts are the layer built specifically for that problem. Not a workaround. Not a repurposed tool. Built for the non-deterministic, probabilistic nature of AI agents in production.
You can't catch probabilistic drift with deterministic monitoring. That's not a team problem. That's a tooling problem.
If you're shipping AI changes right now and your quality signal is "seems fine," that's the gap. Not because you're not paying attention. Because the tools you have weren't built for this question.

40 conversations. Different teams, different products, different industries. The same gap in every single one.
The tools most AI teams are using were built for a different problem. Infrastructure monitoring tells you when things break. It was never designed to tell you when things drift, degrade, or quietly get worse in ways that don't look like failures.

Evaluations, Simulations and alerts were built for that problem specifically. Not as an add-on. As the foundation for shipping AI with actual confidence rather than hope.

That's the pattern. That's why I keep talking about it. That's what we built Netra to solve. If you want to see what it looks like in practice, try out:getnetra.ai