---
title: "Connect Intruder to AI Agents: Orchestrate Scans & Issue Remediation"
slug: connect-intruder-to-ai-agents-orchestrate-scans-issue-remediation
date: 2026-10-07
author: Uday Gajavalli
categories: ["AI & Agents"]
excerpt: "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."
tldr: "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."
canonical: https://truto.one/blog/connect-intruder-to-ai-agents-orchestrate-scans-issue-remediation/
---

# Connect Intruder to AI Agents: Orchestrate Scans & Issue Remediation


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](https://truto.one/connect-intruder-to-chatgpt-automate-vulnerability-scans-audits/), or if you are building on Anthropic's models, read our guide on [connecting Intruder to Claude](https://truto.one/connect-intruder-to-claude-monitor-targets-manage-security-issues/). 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](https://truto.one/the-hands-on-guide-to-building-mcp-servers-for-ai-agents-2026/). For a broader look at this design pattern, read our research on [architecting AI agents and the SaaS integration bottleneck](https://truto.one/architecting-ai-agents-langgraph-langchain-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](https://truto.one/zero-data-retention-for-ai-agents-why-pass-through-architecture-wins/). 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.

```mermaid
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 Data
```

## Intruder 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](https://truto.one/best-unified-api-for-llm-function-calling-ai-agent-tools-2026/). 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](https://truto.one/integrations/detail/intruder).

## 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."

1.  **create_a_intruder_scan:** The agent kicks off a targeted scan using `target_addresses: ["10.0.50.12"]`.
2.  **get_single_intruder_scan_by_id:** The agent enters a loop, polling the scan ID until the status reads `completed`.
3.  **list_all_intruder_fixed_occurrences:** The agent checks if the specific Redis vulnerability's `occurrence_id` now 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."

1.  **create_a_intruder_target:** The agent adds `192.168.100.45` to the platform.
2.  **create_a_intruder_target_tag:** The agent applies the 'Shadow IT' tag to the newly generated `target_id`.
3.  **create_a_intruder_scan:** The agent initiates a scan explicitly scoped to the new target, passing the `web_ports_only` flag 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.

```typescript
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.

> Ready to give your AI agents deterministic access to Intruder and 200+ other SaaS APIs? Book a demo with our engineering team today.
>
> [Talk to us](https://truto.one/book-a-demo/)