Connect Intruder to AI Agents: Orchestrate Scans & Issue Remediation
Give your AI agent Intruder tools.
This technical guide explains how to connect Intruder to AI agents using Truto's auto-generated tools. We cover bypassing Intruder's unique API quirks, handling rate limits correctly, and building multi-step autonomous security workflows.
In this guide
- 01Fetch Intruder Tools
- 02Bind Tools to the LLM
- 03Implement Rate Limit Handling
- 04Execute Multi-Step Scans
The guide
Learn how to connect Intruder to AI agents using Truto's /tools endpoint. Build autonomous workflows for vulnerability scanning and issue remediation in LangChain, CrewAI, and more.
You want to connect Intruder to an AI agent so your security operations system can independently orchestrate vulnerability scans, add newly discovered targets, track CVEs, and verify issue remediation. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to write and maintain a custom REST integration from scratch.
Giving a Large Language Model (LLM) read and write access to your vulnerability management platform is high-stakes engineering. If your team uses ChatGPT, check out our guide on connecting Intruder to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting Intruder to Claude. For developers building custom autonomous workflows, you need a programmatic, type-safe way to fetch these tools and bind them to your agent framework.
This guide breaks down exactly how to fetch AI-ready tools for Intruder, bind them natively to an LLM using frameworks like LangChain, LangGraph, CrewAI, or the Vercel AI SDK, and execute complex security operations. This approach works completely framework-agnostic and is not limited to MCP environments. For a broader look at this design pattern, read our research on architecting AI agents and the SaaS integration bottleneck.
The Engineering Reality of the Intruder API
Building an AI agent is fundamentally an exercise in prompt design and state management. Giving that agent reliable access to external systems is where projects stall. If you hardcode API interactions into your agent, you will spend your sprints writing defensive integration code instead of improving your model's reasoning.
The Intruder API presents several specific architectural challenges that break standard REST assumptions. If you expect a flat, simple CRUD model, your agent will hallucinate state and fail to track vulnerabilities over time.
The Issue vs. Occurrence Identity Crisis
The most dangerous trap in the Intruder API is how it handles identifiers for vulnerabilities. An agent naturally expects that if it finds an issue with ID 12345, it can check ID 12345 a week later to see if it was fixed. In Intruder, the standard id of an issue occurrence can actually change between different scan runs.
Instead, developers - and AI agents - must rely on the occurrence_id. This is the stable identifier that persists across multiple scans for a specific vulnerability on a specific target. If you do not explicitly force your agent to track the occurrence_id, it will hallucinate that a vulnerability disappeared, simply because the ephemeral id changed.
Scan State Machines and Asynchrony
Security scans take time. They are not synchronous API calls. When an agent calls the endpoint to create a scan, it receives a scan record with a status (e.g., running, scheduled, completed).
Naive agents will kick off a scan and immediately attempt to read the issues, resulting in zero findings and a false sense of security. The agent framework must be given explicit tools to poll the get_single_intruder_scan_by_id endpoint, check the state machine, and yield its execution thread until the scan is actually complete. Furthermore, scans have specific subtypes - such as web_ports_only or throttled runs - which require the LLM to understand deeply nested configuration payloads.
Complex Target Topologies
Adding a target to Intruder is rarely a single string IP address. Targets in the real world require target_authentication objects to allow the scanner past firewalls or login screens. They require API schemas if you are scanning a web service. When an agent attempts to bulk create targets using CIDR blocks, it must parse complex license tiering (license_type) constraints to avoid blowing through your commercial allocations.
Factual Note on Rate Limits
Before giving an autonomous agent a loop that polls a security scanner, you must handle rate limiting.
Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Intruder API returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification.
The caller - your agent or agent framework - is entirely responsible for implementing retry and exponential backoff logic using these headers.
sequenceDiagram
participant Agent as AI Agent Framework
participant Truto as Truto Proxy
participant Intruder as Intruder API
Agent->>Truto: Call Intruder Tool (e.g., list_scans)
Truto->>Intruder: Forward Request
Intruder-->>Truto: HTTP 429 (Rate Limited)
Truto-->>Agent: HTTP 429 + IETF ratelimit headers
Note over Agent: Agent parses ratelimit-reset<br>and suspends execution
Agent->>Truto: Retry after delay
Truto->>Intruder: Forward Request
Intruder-->>Truto: HTTP 200 OK
Truto-->>Agent: Scan DataIntruder AI Agents Integration: Hero Tools
Instead of exposing the raw Intruder API to your LLM, Truto provides proxy APIs that map external resources into deterministic, strict JSON schemas. Your agent interacts with these abstracted tools via the /tools endpoint.
Here are the highest-leverage operations your agent can perform.
List All Intruder Issues
This tool allows the agent to query the current active vulnerabilities across the infrastructure. It supports heavy filtering by severity, tags, snoozed status, or target addresses. This is the primary discovery tool for an agent hunting for critical risks.
"Review our current Intruder issues. Filter for 'Critical' and 'High' severity vulnerabilities that are not currently snoozed, and list the affected target addresses."
List All Intruder Issue Occurrences
Because the overarching issue is just a vulnerability type (like a specific CVE), the agent needs this tool to find exactly where it exists. Crucially, this returns the occurrence_id (the stable identifier) and context like the exact port, protocol, and target last scanned date.
"I need the specific occurrence details for the Apache Struts issue we found. Get all occurrences for issue_id '9876' and note their stable occurrence_ids so we can track remediation."
Create an Intruder Scan
This tool allows the agent to initiate an active vulnerability scan. The agent can optionally pass specific target addresses or tag names to narrow the scope. If the agent omits the body entirely, it triggers a global scan across all targets.
"We just deployed a new cluster to the 'prod-k8s' tag. Trigger an immediate Intruder scan isolated to targets with that tag to ensure no new ports were accidentally exposed."
Get Single Intruder Scan by ID
Because scans are asynchronous, this tool is the polling mechanism. The agent uses it to read the status, completed_time, and configuration (web_ports_only, throttled) of a scan it previously initiated.
"Check the status of scan 'scan_55abc'. If it is completed, tell me the exact completed_time. If it is still running, let me know it requires more time."
Create an Intruder Target
This tool enables the agent to dynamically expand the attack surface monitoring. When an agent discovers a new unmanaged asset in an AWS log or ticketing system, it can immediately add it to Intruder. It requires an address and can accept authentication URLs if needed.
"We have a new staging server at 10.5.22.14. Add this as a new target in Intruder so it is included in the nightly schedules."
List All Intruder Fixed Occurrences
Tracking what is broken is only half the job. This tool allows the agent to verify that vulnerabilities have actually been resolved. It returns historical data, including the cvss_score, the affected host, and exactly when it was remediated.
"The DevOps team claims they patched all OpenSSL vulnerabilities yesterday. Cross-reference their claims by listing all fixed occurrences in Intruder from the last 24 hours."
Create an Intruder Scan Schedule
For continuous monitoring, an agent can use this tool to set up recurring scan rules. It requires a schedule frequency (monthly, daily, weekly, or quarterly) and a future start time locked to the top of the hour.
"Set up a new weekly scan schedule named 'PCI Compliance Run'. Configure the first scan to start next Monday at exactly 02:00 AM."
To view the complete inventory of available methods and their exact JSON schemas, visit the Intruder integration page.
Workflows in Action
Agentic workflows move beyond single-turn chat. By combining the tools above, AI agents can execute complex, multi-stage security operations.
Scenario 1: Automated Patch Verification
Security teams waste hours re-scanning environments to verify that DevOps actually applied a requested patch. An autonomous agent can handle this validation loop entirely on its own.
"DevOps reported that they patched the critical Redis vulnerability on target 10.0.50.12. Trigger a scan on that specific target, wait for it to finish, and confirm if the issue occurrence is now listed as fixed."
- create_a_intruder_scan: The agent kicks off a targeted scan using
target_addresses: ["10.0.50.12"]. - get_single_intruder_scan_by_id: The agent enters a loop, polling the scan ID until the status reads
completed. - list_all_intruder_fixed_occurrences: The agent checks if the specific Redis vulnerability's
occurrence_idnow appears in the fixed ledger.
The user receives a definitive confirmation: either a success message indicating the vulnerability is remediated, or an alert that the patch failed and the target remains vulnerable.
Scenario 2: Shadow IT Discovery and Onboarding
When a new, undocumented server is detected by internal networking monitors, an AI agent can automatically bring it under the security umbrella without waiting for a human to file a ticket.
"A network monitor detected an unknown web server responding at 192.168.100.45. Add it to our Intruder targets, tag it as 'Shadow IT', and kick off a web-ports-only scan immediately."
- create_a_intruder_target: The agent adds
192.168.100.45to the platform. - create_a_intruder_target_tag: The agent applies the 'Shadow IT' tag to the newly generated
target_id. - create_a_intruder_scan: The agent initiates a scan explicitly scoped to the new target, passing the
web_ports_onlyflag to prioritize web vulnerabilities.
The user receives a brief summary stating the asset is now actively monitored, tagged for audit, and currently undergoing its initial baseline scan.
Building Multi-Step Workflows
Giving an agent tools is only the first step; binding those tools to a resilient execution loop is the engineering challenge. Because Truto normalizes the Intruder API into framework-agnostic JSON schemas via the /tools endpoint, you can bind these tools to any framework.
Below is a conceptual architecture using standard TypeScript and a framework like LangChain. Notice how we explicitly handle the 429 rate limit exceptions, respecting the ratelimit-reset headers that Truto passes through from Intruder.
import { ChatOpenAI } from "@langchain/openai";
import { AgentExecutor, createToolCallingAgent } from "langchain/agents";
import { ChatPromptTemplate } from "@langchain/core/prompts";
import { TrutoToolManager } from "truto-langchainjs-toolset";
async function runSecurityAgent() {
// 1. Initialize the Truto Tool Manager with your Intruder Integrated Account ID
const truto = new TrutoToolManager({
apiKey: process.env.TRUTO_API_KEY,
});
// Fetch all tools associated with the Intruder account
const tools = await truto.getTools("intruder_account_12345");
// 2. Initialize the LLM
const llm = new ChatOpenAI({
modelName: "gpt-4o",
temperature: 0,
});
// 3. Define the Agent Prompt
const prompt = ChatPromptTemplate.fromMessages([
["system", `You are an elite Security Operations Agent.
You have access to Intruder vulnerability scanning tools.
CRITICAL INSTRUCTIONS:
- Always track 'occurrence_id' for stable vulnerability tracking, not 'id'.
- If you initiate a scan, you MUST poll get_single_intruder_scan_by_id until status is 'completed'.
- If a tool fails with an HTTP 429 Too Many Requests, parse the ratelimit-reset header, wait, and try again.`],
["human", "{input}"],
["placeholder", "{agent_scratchpad}"],
]);
// 4. Create the Agent and Executor
const agent = createToolCallingAgent({ llm, tools, prompt });
const executor = new AgentExecutor({
agent,
tools,
maxIterations: 15, // Allow enough iterations for polling scans
});
// 5. Execute the Workflow with Rate Limit Handling
try {
const result = await executor.invoke({
input: "Add 10.1.1.50 as a target and run a scan on it.",
});
console.log(result.output);
} catch (error) {
if (error.response && error.response.status === 429) {
// Truto passes the IETF standard headers directly from Intruder
const resetTime = error.response.headers['ratelimit-reset'];
console.warn(`Rate limit hit. Agent framework must back off until ${resetTime}.`);
// Implement your framework-specific sleep/retry logic here
} else {
console.error("Agent execution failed:", error);
}
}
}This execution loop ensures that your agent does not blindly charge forward when Intruder pushes back. By handling the control flow in your application layer, the LLM remains focused on security reasoning rather than HTTP mechanics.
Strategic Wrap-Up
Giving AI agents autonomous control over your vulnerability scanning pipeline transforms security operations from reactive ticketing to proactive remediation. However, pointing an LLM directly at the raw Intruder API invites hallucinations around dynamic IDs, scan polling states, and complex authentication schemas.
By routing your agent through Truto's /tools endpoint, you collapse the complexity of the Intruder API into strict, deterministic JSON schemas. Your agent gets safe, bounded functions to execute scans, while your infrastructure layer properly handles the 429 rate limit errors and normalizes the payload.
Stop spending sprints maintaining integration boilerplate. Give your AI agents the tools they actually need to secure your infrastructure.
FAQ
- How do AI agents handle Intruder API rate limits through Truto?
- Truto does not absorb or automatically retry rate-limited requests. When Intruder returns an HTTP 429 error, Truto passes it directly to the AI agent, normalizing the headers into the IETF standard (ratelimit-limit, ratelimit-remaining, ratelimit-reset). Your agent framework is responsible for implementing the backoff and retry logic.
- Can I use Truto's Intruder tools with LangGraph or CrewAI?
- Yes. Truto's /tools endpoint returns standard JSON schemas that can be ingested by any major agent framework, including LangChain, LangGraph, CrewAI, and the Vercel AI SDK, without being limited to the Model Context Protocol (MCP).
- Why is the Intruder occurrence_id important for AI agents?
- In Intruder's API, the standard 'id' for an issue can change between scans. The 'occurrence_id' is the stable identifier that persists across multiple scans, making it critical for AI agents to use when tracking the state of a vulnerability over time.