Detectify’s MCP Server Is the AppSec Version of Letting the Agent Run the Test
Detectify’s new MCP Server is easy to file under “security vendor ships integration.” That would miss the point. The more interesting story is that application security is being forced into the agent loop, because the old workflow — scanner finds bug, dashboard waits, human reads report, ticket appears, developer eventually patches — is too slow for a world where Claude Code, Cursor, Codex, Copilot-style agents, and internal coding bots can generate and modify software at sprint-compression speed.
The launch exposes Detectify’s application-security scanning engines through the Model Context Protocol, the open standard now used to connect AI applications to external tools, data sources, files, databases, and workflows. SiliconANGLE reports that the server lets agents query security findings, create structured remediation tasks, generate patches, trigger validation scans, and return results for human review. Detectify is calling the headline workflow “Find & Fix,” and the company is also adding a conversational interface for asking about scan results, asset status, and high-severity findings.
That sounds incremental until you map it onto how engineering teams actually work. The unit of modern development is no longer only a human developer reading a Jira ticket and pushing a branch. Increasingly, it is a human asking an agent to investigate, change code, run tests, open a diff, and explain the result. If AppSec stays outside that loop, the security review becomes a lagging signal attached to a faster machine. Good luck governing that with quarterly dashboard hygiene.
The scanner should be evidence, not vibes
Detectify CEO Rickard Carlsson gave SiliconANGLE the useful frame: “We aren’t competing with the AI’s reasoning, we are providing the professional-grade tools that reasoning requires.” That sentence is doing real work. LLMs are good at reading messy code, proposing plausible fixes, and stitching together context from files, tickets, docs, and prior output. They are not good enough to be the final judge of whether an application vulnerability is actually gone.
This is the deterministic-versus-probabilistic boundary AppSec teams should care about. A model can explain why it believes a cross-site scripting issue is fixed. A scanner can rerun the relevant check against the changed application and provide independent evidence. A model can patch an authentication bypass in a route handler. A scanner, test harness, or exploit validation path can tell you whether the exposed runtime behavior changed. The agent is a useful repair mechanism; it should not be its own certificate authority.
That distinction matters because security bugs rarely live entirely in the line the model edits. They depend on deployed routes, headers, authentication state, input encoding, asset inventory, framework behavior, API exposure, infrastructure drift, and sometimes the deeply cursed edge cases between them. The agent may have the repository. It may not have the production topology, the scanner’s payload corpus, or the history of why the finding exists. Giving it a callable scanner closes part of that evidence gap.
Detectify’s pitch also reflects a broader shift among AppSec vendors. SiliconANGLE notes similar MCP moves from Legit Security, JFrog, and TrojAI. The market is converging on the same answer: if agents are going to do development work, security tools need to become machine-callable inside that workflow. Tools that only produce human-readable reports will become after-action paperwork. Tools that return structured findings, affected assets, severity, reproduction hints, remediation context, and validation results can become part of the development control loop.
MCP makes this useful, which is exactly why it is risky
MCP is the right shape for this problem because it gives agents a common way to call external systems. The official docs describe it as an open-source standard for connecting AI applications to external systems such as local files, databases, tools, and workflows, with support across Claude, ChatGPT, VS Code, Cursor, MCPJam, and others. In practice, MCP is becoming the context and authority layer for coding agents: the place where the model learns what it can see and what it can do.
That is also the danger. A security scanner connected to an agent is not “just another plugin.” It may expose vulnerability details, asset inventories, internal URLs, remediation context, scan-triggering permissions, and information about the most valuable places to attack the company. If that context enters a poisoned agent session, it becomes very useful to the wrong instruction.
The adjacent MCP security research is ugly enough that teams should not treat this as hypothetical. Invariant Labs demonstrated tool-poisoning attacks where malicious MCP tool descriptions can contain hidden instructions visible to the model but not to the user, leading agents to read sensitive files and exfiltrate them through tool parameters. The Cloud Security Alliance’s May 2026 research note calls MCP one of the most rapidly weaponized attack surfaces in agentic AI deployments and recommends treating every MCP server as an untrusted third party with zero-trust controls at the integration layer. That is not anti-MCP panic. It is the cost of making external systems callable by probabilistic software with a large context window and a helpful personality.
Remote hosting helps with some local-stdio execution risks, and Detectify says its MCP Server is remotely hosted with lightweight configuration. But remote does not mean harmless. The question changes from “can this local command execute on my workstation?” to “what authority does this networked tool expose, what data comes back, who can trigger it, what gets logged, and which other tools can influence the same session?” Those are governance questions, not install prompts.
For Claude Code users, this belongs in the same bucket as MCP permissions, sandboxing, audit logs, usage attribution, and managed settings. Before connecting a security MCP server, inventory it like infrastructure: owner, transport, credential source, tool list, read/write capability, data sensitivity, output volume, and expected call patterns. Separate read-only access to findings from actions that trigger scans, mutate tickets, create patches, or touch deployment workflows. Use the narrowest token that keeps the workflow useful. Log tool calls. Put vulnerability details behind need-to-know access, not inside broad chat transcripts that every helper agent can read.
The useful workflow is patch, prove, review
The best version of this is not “agent fixes vulnerabilities in real time” as a magic trick. It is a boring, auditable workflow: fetch the finding, identify the affected code path, propose the smallest patch, run the relevant tests, trigger a validation scan, attach the scanner result to the PR, and ask a human to review the diff with evidence in hand. That is not slower than today’s AppSec process. It is just honest about where automation should stop.
Teams should start with read-only query access before enabling any scan-triggering or remediation actions. Let the agent summarize high-severity findings and locate likely code paths, but require approval before it triggers expensive scans against shared environments or creates tickets at scale. Keep scanner output bounded so the agent does not drown the context window in noisy reports. If a finding includes secrets, customer data, internal hosts, or exploit payloads, make sure that data is not casually copied into prompts, transcripts, or external issue comments.
There is also a practical product-selection angle here. The AppSec tools that win in agentic workflows will not merely have logos on an MCP marketplace page. They will expose findings in formats agents can reason over without losing precision: stable IDs, affected assets, severity rationale, exploitability notes, reproduction steps, fix guidance, timestamps, ownership metadata, and validation status. They will support least-privilege credentials, scoped environments, good logs, and clear separation between read and action tools. The dashboard still matters, but the API contract becomes the product.
The uncomfortable truth is that AI-assisted coding does not remove AppSec work. It changes where that work has to live. If agents accelerate the creation and modification of software, verification has to become closer to the commit, closer to the PR, and closer to the agent session itself. Detectify’s MCP Server is one implementation of that shift. The broader lesson is the one security teams should write on the wall: let agents propose fixes, but make independent tools prove them.
That is the version worth shipping. Not an agent confidently saying “fixed,” not a scanner dashboard nobody checks until Friday, but a development loop where the patch and the evidence arrive together. LGTM, with a condition: wire the scanner in as a witness, not a rubber stamp.
Sources: SiliconANGLE, Detectify, Model Context Protocol docs, Invariant Labs, Cloud Security Alliance