Two things happened to security tooling when large language models became capable enough to use tools. The first is the one everyone talks about: AI agents that can perform security testing, reasoning about an application the way a researcher does rather than pattern-matching like a scanner. The second gets less attention but may matter more day to day: AI systems themselves became an attack surface, and it is a badly exposed one. Teams raced to self-host models, and in doing so put thousands of inference servers, MCP endpoints, and vector databases on the public internet with no authentication at all.
This guide covers both halves of that shift through two tools from the July 2026 open-source wave. Strix represents the offensive-agent side: an AI penetration tester that validates its findings with working proof-of-concept exploits. AIMap represents the defensive-inventory side: a scanner that finds exposed AI infrastructure at internet scale and scores how dangerous the exposure is. Together they sketch what security work looks like when both the tooling and the targets are AI.
The false-positive problem agents actually solve
To understand why agentic security tools caught on, you have to understand the specific pain they address. Static analysis tools are cheap to run and catch real bugs, but they generate findings by matching patterns in code, and a pattern match is a hypothesis, not a confirmed vulnerability. The tool says "this database query concatenates a variable, which might be SQL injection." Whether it actually is depends on whether that variable is attacker-controlled, whether a sanitizer runs upstream, whether the code path is reachable at all. Answering that requires a human to trace the logic — and at a few hundred findings per scan, that triage cost is what makes security tooling expensive and what causes teams to eventually stop reading the reports.
The agentic approach inverts this. Instead of reporting a suspicious pattern, an agent like Strix runs the application, sends real payloads, and confirms exploitability with a working PoC. If it cannot produce a PoC, the finding does not surface. That flips triage from "investigate whether this is real" to "verify this reproduction," which is dramatically cheaper. It also catches an entire class of issue that static analysis structurally cannot: business logic flaws. A scanner has no model of what your application is supposed to do, so it cannot notice that a user can apply a discount code twice or skip a payment step. An agent that reasons about intent can.
The tradeoff is cost and speed. Agentic testing runs the application, iterates, and burns model tokens, making it far slower and more expensive per run than a static scan that finishes in seconds. That economics dictates how to use it: keep fast SAST like Semgrep or Opengrep running on every commit for breadth, and reserve agentic testing for depth — pre-release assessments, high-value services, or areas where logic flaws are the real risk. Framing these as competitors is the mistake; they answer different questions at different price points.
The exposure nobody planned for
The second half of the story is less about clever tooling and more about a predictable operational failure at scale. Running a model locally became genuinely easy — Ollama and similar tools made it a one-command affair — and easy tools get deployed by people who are not thinking about network exposure. The default configuration binds to a local port; the moment someone sets OLLAMA_HOST=0.0.0.0 to reach it from another machine, and that machine has a public IP, an unauthenticated inference API is on the internet.
What can an attacker do with one? More than the "it's just a chatbot" instinct suggests. They can enumerate your models, which reveals what you are working on and sometimes leaks proprietary fine-tunes. They can use your GPU for free, running their own inference on your electricity and hardware — resource theft that shows up as a mysterious utilization spike. Where the endpoint fronts an application, they may reach system prompts and the instructions that constrain the model. And with MCP endpoints the stakes rise sharply, because MCP servers expose tools — an unauthenticated MCP endpoint may let an attacker invoke real actions against real systems, not just generate text. Exposed vector databases are worse still: they contain the embedded contents of whatever documents you indexed, which for a RAG system is often the crown jewels.
This is the surface AIMap is built to inventory. It discovers AI services across a range, fingerprints what is running, and scores exposure based on factors like missing authentication, enabled model listing, and reachable tool inventories. Used defensively — pointed at your own address space — it answers a question most organizations cannot currently answer: do we have AI infrastructure exposed to the internet, and how bad is it? Given how quickly self-hosted AI spread through teams without a security review, the honest answer for many is "we don't know," and that is precisely why this category of tool appeared.
Using offensive tools without causing harm
Both tools carry real risk of misuse, and being clear-eyed about that is part of using them competently. Strix generates working exploits. AIMap performs internet-scale discovery and protocol-level attack tests. Running either against systems you do not own or lack written permission to test is illegal in most jurisdictions, regardless of intent, and "I was just checking" is not a defense.
The practical safeguards are unglamorous but non-negotiable. Scope explicitly: declare exactly which hosts or ranges are in play and configure the tool to refuse anything else, so a misconfiguration cannot wander. Prefer staging over production: an agent probing a live system can create records, trigger workflows, or exhaust resources — the same actions that make the testing valuable make it disruptive. Sandbox the agent: run it in a container with constrained network egress, both to limit blast radius and because an agent that writes and executes exploit code is, structurally, executing untrusted code. Review generated PoCs before storing or rerunning them. And get authorization in writing before any engagement, including internal ones.
There is a governance dimension too. These tools lower the expertise required to conduct competent offensive testing, which is good for defenders with small teams and equally good for attackers. That symmetry is not a reason to avoid the tools — defenders benefit from testing their own systems the way an attacker would — but it does mean the baseline level of probing every internet-facing asset receives is rising. Fundamentals matter more, not less.
A concrete exposure, start to finish
To make the AI attack surface tangible, walk through how a realistic exposure happens and what an attacker does with it. A data scientist wants to test a model from their laptop against a server in the office, so they set OLLAMA_HOST=0.0.0.0 and restart the service. The host happens to sit on a cloud VM with a public IP and a permissive security group left over from an earlier experiment. Nothing about this feels like a security decision — it is a two-minute convenience change — and no ticket is filed.
Within days, automated scanners find port 11434 answering. An attacker queries /api/tags and gets the full list of models on the box, including an internally fine-tuned model whose name alone reveals the project it supports. They then use the server for their own inference: it is an unmetered GPU with no authentication, so they run workloads on it for free, which the team eventually notices as unexplained utilization and a confusing cloud bill. If that same host also fronts a RAG application, the exposure deepens — an attacker who can reach the vector database can retrieve embedded chunks of whatever corpus was indexed, which may be internal documentation, support tickets, or customer records.
The worst variant involves MCP. If the host exposes an MCP server, its tools are invokable, and those tools exist precisely because they do something useful — query a database, call an internal API, write a file. An unauthenticated MCP endpoint is not a chat toy; it is an unauthenticated remote procedure call interface into whatever the tools reach.
Every step of that chain is prevented by controls the industry has understood for twenty years: bind to localhost, require authentication, restrict the security group, monitor for anomalous traffic. What makes the AI case distinctive is not the sophistication of the attack but the speed and informality of the deployment — these services get stood up by people solving an immediate problem, outside the review process that would catch an exposed database. That is why a discovery tool pointed at your own ranges is worth an afternoon: the failure mode is not clever attackers, it is invisible infrastructure.
Where agentic testing still falls short
It would be a disservice to present agentic security tools as further along than they are, because overestimating them leads to exactly the wrong decision — treating an agent run as a substitute for a real assessment. Several limitations are worth naming plainly.
Coverage is uneven and hard to characterize. A scanner tells you which rules it ran; an agent explores based on its own judgment, which means two runs against the same target may probe different things. That non-determinism makes it difficult to answer "what did we actually test?" — an uncomfortable question during an audit. Treat agent findings as evidence of what is broken, not as evidence that everything else is fine.
Depth in unfamiliar territory is limited. Agents perform well on well-documented vulnerability classes with abundant training data — injection, XSS, access control. They perform much worse on genuinely novel logic, obscure protocols, or the creative chaining of several individually-benign findings into a serious exploit. That chaining is precisely the skill that distinguishes an expert human tester, and it remains the clearest gap.
Cost scales with thoroughness. Every additional probe is model tokens and wall-clock time. Teams that set an agent loose on a large application without scoping discover this in their bill. Scoping to the services and flows that actually matter is not just a safety control; it is a cost control.
And the output still needs judgment. A validated PoC proves exploitability in the test environment, not that the finding is a business priority. Severity, reachability from the real internet, and what an attacker would gain are still human calls. The honest framing is that agents compress the tedious part of testing — enumeration, probing, first-pass validation — while leaving the parts that require context and creativity where they were.
What this means for defenders
Pulling the threads together, a few concrete implications follow for anyone running systems in 2026.
Inventory your AI infrastructure the way you inventory everything else. The pattern of shadow deployment — a data scientist stands up an inference server for an experiment, a team spins up a vector DB for a prototype — means the AI attack surface is frequently undocumented. Scanning your own ranges with a tool like AIMap is a one-afternoon exercise that often surfaces genuine surprises. Make it recurring, not one-time, because the next unreviewed deployment is always a week away.
Apply ordinary controls to extraordinary-seeming systems. The fixes for exposed AI infrastructure are not exotic: bind services to localhost, put an authenticating reverse proxy in front of anything that must be reachable, enforce network policy so port 11434 is never publicly routable, rate-limit, and monitor for unexpected inference traffic. This is the same hygiene that applies to a database — the failure has been treating AI services as toys exempt from it.
Treat MCP endpoints as privileged. Because MCP servers expose tools that take actions, an exposed one is closer to an unauthenticated RPC endpoint than to a chat API. Inventory which tools each server exposes, require authentication, and apply least privilege to what those tools can reach.
Layer your testing by cost. Fast static analysis on every commit (Semgrep, Bearer for data-flow risk), dependency and SBOM analysis continuously (Dependency-Track), crawling DAST on a schedule (ZAP), and agentic validated testing where depth justifies the expense. Each layer covers what the others structurally miss, and no single tool — however clever — is comprehensive.
The bottom line
AI reshaped security tooling from both directions at once. On offense, agents like Strix attack the false-positive problem by validating findings with working exploits and by reasoning about business logic that pattern matchers cannot model — powerful, but slow and expensive enough that it belongs alongside fast SAST rather than replacing it. On defense, the rush to self-host models created a sprawling, largely uninventoried attack surface of exposed inference servers, MCP endpoints, and vector databases, which tools like AIMap exist to find. Inventory your AI infrastructure, apply the boring controls that already work, treat tool-exposing MCP endpoints as privileged, layer your testing by cost, and get authorization in writing before you point any of this at anything. The tooling is genuinely better than it was; the discipline required to use it well has not changed.
References and Resources
Tools
Background and analysis
- 20 open-source cybersecurity tools to keep your team ready — Help Net Security
- Best Open Source AppSec Tools for 2026 — Orca Security
- Top Cybersecurity Open-Source Tools — News4Hackers
Related 1337skills cheatsheets