AI Agentic Workflows

Overview

You can integrate your own AI models and agents with AttackForge.

This can help you with:

• Speed and scale. Agents can enumerate, fingerprint, and probe targets in parallel far faster than a human, compressing reconnaissance and initial discovery from hours into minutes. They also let a single tester effectively cover a much larger scope.

• Coverage and consistency. Humans get tired, skip steps, or follow personal preferences. Agents methodically work through checklists, attack paths, or playbooks the same way every time, reducing the chance that something obvious slips through.

• Lower-tier task automation. Repetitive work - credential spraying with safe thresholds, payload permutation, header analysis, certificate inspection, OSINT collection, evidence collection and screenshotting - can be handed off, freeing testers to focus on the creative, high-judgment parts of the engagement.

• Adaptive reasoning. Unlike traditional scanners, modern AI agents can chain findings together, pivot based on context, and reason about why something might be exploitable rather than just matching signatures. That narrows the gap between automated scanning and manual testing.

• Better reporting and evidence handling. Agents can draft findings, normalize evidence, map issues to frameworks (MITRE ATT&CK, OWASP, CWE), and suggest remediation language -turning hours of write-up into a review-and-edit pass.

• Continuous / on-demand testing. Agents enable testing models that aren't viable with humans alone: always-on assessment, retesting on every release, or rapid validation after a remediation push.

• Knowledge amplification for junior testers. An agent acting as a co-pilot can surface relevant techniques, suggest next steps, and explain unfamiliar tech, effectively giving less experienced testers a senior-level reference on tap.

• Triage and noise reduction. Agents can validate scanner output, deduplicate findings, and downgrade or discard false positives before a human ever sees them.

When integrating your AI with AttackForge - you can benefit from:

• Human-in-the-loop workflows

• Agentic workflows

Agents can be used with AttackForge in different ways to help you scale your testing processes, and to make your testing more efficient and effective.

Some of the examples of using agents with AttackForge:

• Enrichment of vulnerability data

• Triggering hackbots to perform testing and ingest their findings

Agentic Vulnerability Enrichment

You can use AI to enrich your vulnerability data in AttackForge.

This can help you with:

• Contextual enrichment from external sources. AI can pull in and synthesise data from CVE, NVD, EPSS, KEV, exploit-DB, vendor advisories, threat intel feeds, and GitHub PoCs, then attach a digestible summary, known exploit status, affected versions, and patch availability directly onto the finding in AttackForge. No more manual tab-hopping during write-up.

• Severity and risk scoring. Beyond a raw CVSS base score, AI can compute or recommend a contextual score by factoring in asset criticality, exposure (internet-facing vs. internal), compensating controls, data sensitivity, and active exploitation in the wild. EPSS probability and KEV presence can be layered in automatically.

• Smarter deduplication and clustering. AI can recognise that 200 findings across 40 hosts are the same root cause (e.g. one missing patch, one shared library), cluster them, and surface a single "fix once, resolve many" vulnerability in AttackForge - dramatically reducing reporting noise.

• Auto-generated descriptions, impact statements, and remediation guidance. AI can draft technically accurate, audience-appropriate language for each finding - one tone for the executive summary, another for the developer reading the ticket. It can also tailor remediation steps to the specific tech stack (e.g. give the fix for the actual NGINX version detected, not a generic line).

• Framework and standard mapping. Automatically map findings to MITRE ATT&CK techniques, CWE, OWASP Top 10, PCI-DSS, ISO 27001, NIST controls, or whatever framework the client cares about. This is high-effort manual work that AI handles well.

• Attack path and chain reasoning. Given a set of findings and asset relationships, AI can hypothesise how an attacker would chain them - e.g. "exposed admin panel + default creds + outdated Tomcat = RCE → lateral movement via reused SSH key." This turns a flat finding list into a narrative.

• Proof-of-concept and validation assistance. AI can suggest exploitation steps, generate safe PoC payloads, propose validation commands, or draft retest procedures - accelerating both initial testing and post-remediation verification.

• Translation and localisation. Findings, reports, and remediation guidance translated into the client's preferred language, with technical accuracy preserved.

• Business impact translation. Convert technical vulnerabilities into business-language impact: "this SQLi exposes the customer PII database" rather than "unsanitised input on /search.php." Useful for executive reporting and risk-acceptance conversations.

• Trend detection and program insights. Across an organisation's full vulnerability history, AI can identify recurring weaknesses, slow-fix categories, teams or apps that lag in remediation, and emerging patterns - feeding back into program improvement.

• Conversational query layer. Let users ask the library in natural language: "show me all critical findings on internet-facing assets without a fix in 30 days that map to ATT&CK Initial Access." This makes vulnerability data accessible to non-technical stakeholders.

• Quality assurance on testing output. AI can review writeups for completeness, flag missing evidence, check that severity matches the described impact, and catch inconsistencies before a report goes out - a "second pair of eyes" pass.

The example below utilizes the following components in order to enrich vulnerabilities in AttackForge using AI agents:

• AttackForge Actions

• AttackForge Flows

• Microsoft Copilot Studio Flows

• Microsoft Copilot Studio Agents

IMPORTANT: Although this example uses Microsoft Copilot Studio - you can tailor this example to use any AI agentic systems, including your own existing agents.

1. Creating an Agent

This example utilizes Microsoft Copilot Studio Agents. However you can use any AI agentic systems, including your own existing agents.

Start by opening Copilot Studio and click on Agents. Click on Create blank agent. Give the agent a name, then click Create.

Once your agent is ready, we recommend configuring Claude Opus 4.5 as the supporting Large Language Model (LLM).

Click on Tools. Follow this guide to configure your agent to the AttackForge MCP server.

The following MCP tools are required:

• Find Vulnerabilities

• Find Writeups

• Get Args Schema for Tool

• Get Field Structure

• Patch Writeup

Connect your agent to the internet so it can retrieve better sources of vulnerability context.

Click on Settings. Within Generative AI - scroll down to Use information from the Web and enable this setting.

Click Publish to publish your agent. Your agent is now ready 😊

2. Triggering an Agent

This example utilizes Microsoft Copilot Studio Flows to create an incoming webhook which triggers the agent. However you can use any HTTP trigger-based solutions, including your own existing HTTP triggers.

Start by opening Copilot Studio and click on Flows. Click on New agent flow.

Select Request. Select When an HTTP request is received.

Configure the following:

• Who can trigger the flow?

  • Select Anyone for testing purposes.

  • For Production - lock down this trigger based on your security requirements.

• Request Body JSON Schema

  • Enter the following:

{
    "type": "object",
    "properties": {
        "project_ids": {
            "type": "array",
            "items": {
                "type": "string"
            }
        },
        "vulnerability_ids": {
            "type": "array",
            "items": {
                "type": "string"
            }
        },
        "writeup_ids": {
            "type": "array",
            "items": {
                "type": "string"
            }
        }
    },
    "additionalProperties": false
}

Click on the + icon to add the next step in the flow.

Select Run an agent.

Select your agent created in the previous step.

For the Message - start by clicking on Trigger function. Enter in triggerBody() as the function. Click Add.

IMPORTANT: This step is essential to ensure the Body from your HTTP Request is injected into the agent prompt. The body is expected to include project_ids, vulnerability_ids or writeup_ids - depending from where the agent gets triggered in AttackForge.

After Body - enter the following prompt:

The goal is to improve the Writeups in AttackForge.

Improvements should focus on improving the following fields:
- Title
- Description
- Attack Scenario
- Remediation Recommendation
- Template Steps to Reproduce (POC)

You will recieve either of the following in the body:
- project_ids
- vulnerability_ids
- writeup_ids

If you receive a Project Id - improve the Writeups for every Vulnerability on the Project.

If you receive a Vulnerability Id - improve the Writeup associated to that Vulnerability.

To improve the Writeup, you first need to identify the type of vulnerability discovered, then work out the relevant MITRE CWEs and MITRE CAPECs.

Patch the AttackForge Writeup to update the Title, Description, Attack Scenario, Remediation Recommendation and Template Steps to Reproduce (POC) using the data from MITRE CWE and MITRE CAPEC. Dont ask for confirmation - just do it.

Template Steps to Reproduce (POC) is a custom field.

Disable the option Request human assistance when unsure.

Click Publish to publish your flow.

Click on the first step of your flow. Copy the HTTP URL and paste this somewhere (you will need it later).

Your HTTP Trigger for your agent is now ready 😊

3. Configure Flows

In AttackForge, click on Flows. Click New > Create Flow.

Enter the following configuration:

• Enabled = On

• Trigger Type = Action

• Restrict to Entities:

  • Project

  • Projects

  • Vulnerability

  • Vulnerabilities

  • Writeup

  • Writeups

• Action 1

  • Method = POST

  • URL = paste HTTP URL from previous step

  • Headers:

    • Content-Type - Value - application/json

• Request Script

const body = {};

if (data.projects || data.project) {
  body.project_ids = [];
  
  if (data.projects && data.projects.length > 0) {
    for (let x = 0; x < data.projects.length; x++) {
      const project_id = data.projects[x];
      Array.push(body.project_ids, project_id);
    }
  }
  else if (data.project?.project_id) {
    Array.push(body.project_ids, data.project.project_id);
  }
}
else if (data.vulnerabilities || data.vulnerability) {
  body.vulnerability_ids = [];
  
  if (data.vulnerabilities && data.vulnerabilities.length > 0) {
    for (let x = 0; x < data.vulnerabilities.length; x++) {
      const vulnerability_id = data.vulnerabilities[x];
      Array.push(body.vulnerability_ids, vulnerability_id);
    }
  }
  else if (data.vulnerability?.vulnerability_id) {
    Array.push(body.vulnerability_ids, data.vulnerability.vulnerability_id);
  }
}
else if (data.writeups || data.writeup) {
  body.writeup_ids = [];
  
  if (data.writeups && data.writeups.length > 0) {
    for (let x = 0; x < data.writeups.length; x++) {
      const writeup_id = data.writeups[x];
      Array.push(body.writeup_ids, writeup_id);
    }
  }
  else if (data.writeup?.id) {
    Array.push(body.writeup_ids, data.writeup.id);
  }
}

if (!body.project_ids && !body.vulnerability_ids && !body.writeup_ids) {
  return {
    decision: {
      status: 'abort',
      message: 'body is missing project_ids and vulnerability_ids and writeup_ids. Exiting.',
    }
  };
}
if (body.project_ids && !body.project_ids.length === 0) {
  return {
    decision: {
      status: 'abort',
      message: 'body has no project_ids. Exiting.',
    }
  };
}
if (body.vulnerability_ids && !body.vulnerability_ids.length === 0) {
  return {
    decision: {
      status: 'abort',
      message: 'body has no vulnerability_ids. Exiting.',
    }
  };
}
if (body.writeup_ids && !body.writeup_ids.length === 0) {
  return {
    decision: {
      status: 'abort',
      message: 'body has no writeup_ids. Exiting.',
    }
  };
}

return {
  decision: {
    status: 'continue',
    message: 'Trigger agent to improve Writeups',
  },
  request: {
    body: body
  }
};

• Response Script

if (response?.statusCode === 202) {
  return {
    decision: {
      status: 'finish',
      message: 'Agent successfully triggered!',
    }
  };
}
else {
  Logger.error(JSON.stringify(response));
  return {
    decision: {
      status: 'abort',
      message: 'Error triggering Agent',
    }
  };
}

Click Create. Your Flow is now ready 😊

4. Configure Actions

Click on Actions in the main navigation menu. Click on All Actions.

Select System Actions. Click on New.

Enter the following configuration:

• Entities:

  • Project

  • Projects

  • Vulnerability

  • Vulnerabilities

  • Writeup

  • Writeups

• Flows

  • Select your flow from the previous step

Click Create.

Your Action is now created and ready for use 😊

REMINDER: Don't forget to give other people access to your Action if you need to roll this workflow out to more people than yourself.

Navigate to any project and notice that your workflow is now ready to launch from your Actions menu:

This is what the writeup looked like BEFORE the agent enriched the data:

This is what the writeup looks like AFTER the agent enriched the data:

When triggering this workflow on a project - all vulnerabilities will be sent to the agent for processing.

You can also trigger this workflow on multiple projects at the same time:

You can also trigger this workflow from a vulnerability:

You can also trigger this workflow on multiple vulnerabilities at the same time:

You can also trigger this workflow from a writeup:

You can also trigger this workflow on multiple writeups at the same time:

Agentic Penetration Testing

You can use AI to run pentesting agents for you, and ingest their findings in to AttackForge.

This can help you with:

• Scale and coverage. A single agent (or a swarm of them) can probe orders of magnitude more attack surface than a human team in the same window. Every subdomain, every API endpoint, every parameter can be exercised without triage bottlenecks.

• Continuous vs. point-in-time. Traditional engagements are snapshots - accurate the day they're delivered, stale the day after. Agents can run continuously against staging and production, catching regressions as code ships. This fits modern CI/CD far better than annual or quarterly assessments.

• Speed to first finding. Reconnaissance, fingerprinting, credential-spraying checks, and misconfig scanning are the slowest parts of a human-led test. Agents compress those hours or days into minutes, so testers hit the interesting work sooner.

• Multi-step attack chaining. This is where LLM-driven agents differ meaningfully from legacy scanners. They can enumerate a service, notice a weak permission, pivot to an adjacent host, and chain low-severity issues into a high-impact path - the way a human attacker would. Scanners flag issues in isolation; agents build narratives.

• Tool orchestration. Instead of hard-coding "run nmap then Nuclei then Burp," an agent can pick the right tool for what it's seeing, feed results between tools, and adapt on the fly. It behaves more like a tester driving a toolkit than a pipeline stitched together.

• Consistency and auditability. Agents apply the same methodology every run. That makes it much easier to trend security posture over time, compare pre/post remediation states, and prove coverage for auditors. Every action is logged, timestamped, and reproducible.

• Addressing the talent gap. There aren't enough experienced pentesters to meet demand - not even close. Agents let small teams punch above their weight and let organizations that couldn't previously afford ongoing offensive testing get meaningful coverage.

• Realistic adversary simulation. Attackers are already adopting AI. Defensive testing that doesn't use the same techniques is training against yesterday's adversary. Agent-driven testing more accurately reflects what a modern attacker will actually do.

• Framework-driven coverage. Agents can systematically walk MITRE ATT&CK or a custom playbook, ensuring techniques aren't skipped because a human forgot or ran out of time. Good for compliance narratives too.

• Cost efficiency on the repetitive layer. Recon, credentialed config review, IAM enumeration, and similar tedium is where humans burn hours without adding much creativity. Offloading that to agents lets senior testers focus on business-logic flaws, chained exploits, and the judgment calls agents still can't make well.

IMPORTANT: AI agents do not replace human pentesters - they extend them. The creative leaps, the business-context understanding, the judgment about which finding actually matters to a given customer, still need people. The best way to think about it is "AI agents cover breadth, humans cover depth" - a managed workflow where both feed into the same lifecycle rather than competing.

The example below utilizes the following components in order to perform a pentest using AI agents, then ingest their findings into AttackForge:

• AttackForge Actions

• AttackForge Flows

• OpenClaw

• Microsoft Foundry

IMPORTANT: Although this example uses OpenClaw and Microsoft Foundry - you can tailor this example to use any AI agentic systems, including your own existing agents.

1. Creating and Triggering an Agent

This example utilizes OpenClaw and Microsoft Foundry. However you can use any AI agentic systems, including your own existing agents.

The following diagram illustrates the key components utilized in this workflow.

IMPORTANT: Please ensure to security harden your OpenClaw environment as the default settings for OpenClaw is inherently insecure.

Notes:

• OpenClaw is running on a Linux server hosted somewhere on your infrastructure.

• NGINX reverse proxy is installed on your linux server, and configured to manage ingress into the server, exposing the endpoint which the AttackForge Flow will communicate with. IP-whitelisting and Authorization Key is recommended to control authentication to the endpoint.

• Open Claw is configured to allow Hooks to register the agent action. NGINX should proxy-pass to the relevent hook. Hooks and Transforms are defined - which turn an AttackForge Flow webhook into an agent directive.

• The OpenClaw Gateway is configured and running.

• OpenClaw has AttackForge MCP configured. The following MCP tools are required:

  • Find Project

  • Find Project Scope

  • Create Writeup

  • Create Vulnerability

  • Patch Vulnerability

  • Get Args Schema for Tool

  • Get Field Structure

  • Count Vulnerabilities

• OpenClaw is connected to an AI Model. We used Microsoft Foundry which adds extra layers of authorization, monitoring and control - however you can connect to any model supported by OpenClaw.

• OpenClaw has Web Search configured.

• OpenClaw agents are configured with AGENTS.md, HEARTBEAT.md, IDENTITY.md, SOUL.md, TOOLS.md, USER.md

• Testing tools are installed on the linux server and in-scope of the agent tools.

2. Configure Flows

In AttackForge, click on Flows. Click New > Create Flow.

Enter the following configuration:

• Enabled = On

• Trigger Type = Action

• Restrict to Entities:

  • Project

• Action 1: Trigger Hackbots and Start Hacking!

  • Method = POST

  • URL = https://{{openclaw_hostname}}/hooks/{{hook_name}}

  • Secrets:

    • openclaw_hostname - the FQDN for your OpenClaw server

    • openclaw_api_key - <your hooks API key>

    • openclaw_hackbot_trigger_name - the name of your hook

  • Headers:

    • Content-Type - Value - application/json

• Request Script

const body = {};

if (data.project?.project_id) {
  body.project_id = data.project.project_id;
}

if (!body.project_id) {
  return {
    decision: {
      status: 'abort',
      message: 'body is missing project_id. Exiting.',
    }
  };
}

return {
  decision: {
    status: 'continue',
     message: 'Trigger agent to start hacking',
  },
  request: {
    url: 'https://' + secrets.openclaw_hostname + '/hooks/' + secrets.openclaw_hackbot_trigger_name,
    headers: {
      'Authorization': 'Bearer ' + secrets.openclaw_api_key
    },
    body: body
  }
};

• Response Script

if (response?.statusCode === 200) {
  return {
    decision: {
      status: 'finish',
      message: 'Agent successfully triggered!',
    }
  };
}
else {
  Logger.error(JSON.stringify(response));
  return {
    decision: {
      status: 'abort',
      message: 'Error triggering Agent',
    }
  };
}

Click Create. Your Flow is now ready 😊

3. Configure Actions

Click on Actions in the main navigation menu. Click on All Actions.

Select System Actions. Click on New.

Enter the following configuration:

• Entities:

  • Project

• Flows

  • Select your flow from the previous step

Click Create.

Your Action is now created and ready for use 😊

REMINDER: Don't forget to give other people access to your Action if you need to roll this workflow out to more people than yourself.

Navigate to any project and notice that your workflow is now ready to launch from your Actions menu:

Your vulnerabilities will start ingesting as your agent identifies, verifies and enriches each vulnerability:

4. Monitoring Agent Testing Progress

The OpenClaw Gateway Control UI can be used to monitor agent sessions and live agent testing progress.

Click into the session to see what the agent is doing.

5. Dynamic Agent Prompts Using Custom Forms on Actions

Coming soon!

6. Dynamically Registering Agent Test Procedures as Project Test Cases

Coming soon!

7. Driving Agent Test Procedures from AttackForge Project Test Cases

Coming soon!

Agentic Retesting

Coming soon!