Automating Threat Intelligence: Building Multi-Agent Vulnerability Assessment Pipelines with CrewAI and LangChain

A useful threat-intelligence pipeline is a role split, not a smarter prompt. CrewAI assigns scout, analyst, and reporter jobs; LangChain supplies tools and models; a MERN or Next.js shell stores runs and shows operators what to patch. Manual auditing does not scale with the attack surface. A single undifferentiated LLM call does not scale either—it just fails fluently.

As corporate attack surfaces grow, manual auditing and rule-based scanners cannot keep up. Security teams need adaptive pipelines that parse, correlate, and evaluate vulnerabilities dynamically.

Merging LLMs with CrewAI and LangChain lets us automate threat hunting, analyze intelligence logs, and assess software environments in real time. The architecture below is how I keep that automation inspectable: agents with jobs, artifacts in a database, humans on the loop for anything that becomes a ticket.

Who this is for

This is for product teams adding "AI security" without boiling the ocean, for startups whose stack is a known MERN or Next.js surface, and for engineering teams in Lahore, across Pakistan, and working remote-from-Pakistan who need a pipeline they can run on a modest GPU budget or a hosted LLM.

If you are a product manager, the deliverable is a brief a developer can act on, not a chat transcript. If you are a founder, the risk is an agent that pages the team with false positives. If you are an engineer, this is orchestration, schemas, and a queue—not a demo notebook.

How should autonomous security agents be split?

Traditional automation runs a rigid script. Multi-agent systems operate on roles and goals. Instead of one monolithic prompt, split the workload across specialists.

1. The Threat Intelligence Scraper (Scout)

• Role: OSINT and intelligence gathering
• Goal: Scrape public threat feeds, CVE databases, and advisories for issues that match a software stack
• Tooling: LangChain search tools, scrapers, and rate-limited API connectors

The scout is not allowed to decide exploitability. If it does, you will never know whether a miss was retrieval or judgment. I constrain its output to a list of records: identifier, source URL, affected products, published date. Garbage in the list is a scout bug.

2. The Vulnerability Analyzer (Engineer)

• Role: Configuration and code auditor
• Goal: Cross-reference scout findings against asset inventories and dependency trees
• Logic: Filter false positives using runtime context

This is the only agent that should see internal inventory. The scout can run against the public internet. The analyst maps "CVE-xxxx affects package y" to "we actually ship y@1.2.3 on service z." Without that join, you get theater: a beautiful report about software you do not run.

3. The Security Compliance Reporter (Auditor)

• Role: Threat modeling and compliance
• Goal: Produce risk reports with CVSS-style scores and relevant legal frameworks

The reporter writes for humans. It must not invent scores. I pass through vendor or NVD severity when present and label anything the model infers as model_estimate. Mixing those silently is how AI security products lose trust.

A fourth role I add only after the three work: a red-team critic that challenges the analyst's "not applicable" calls. Sequential first. Debate later.

How do I orchestrate the crew with CrewAI?

from crewai import Agent, Task, Crew, Process
from langchain_groq import ChatGroq

llm = ChatGroq(temperature=0.2, model_name="llama3-70b-8192")

threat_scout = Agent(
    role="Lead Threat Intelligence Scout",
    goal="Identify emerging critical vulnerabilities matching specified infrastructure profiles.",
    backstory="A cybersecurity researcher specialized in APTs and OSINT indexing.",
    verbose=True,
    llm=llm,
)

security_analyst = Agent(
    role="Senior Vulnerability Assessment Engineer",
    goal="Analyze threat intelligence against system architectures to locate critical risk factors.",
    backstory="A developer with a deep understanding of design patterns and dependency matrices.",
    verbose=True,
    llm=llm,
)

task1 = Task(
    description="Scan public databases for the latest critical vulnerabilities affecting MERN stacks.",
    agent=threat_scout,
)

task2 = Task(
    description="Cross-reference discoveries to calculate exploitability and mitigation paths.",
    agent=security_analyst,
)

cyber_guard_crew = Crew(
    agents=[threat_scout, security_analyst],
    tasks=[task1, task2],
    process=Process.sequential,
)

result = cyber_guard_crew.kickoff()
print(result)

Temperature 0.2 is intentional. Threat briefs should not be creative. Process.sequential is also intentional: the analyst must not start before the scout has produced a list. Hierarchical process types look impressive and make evaluation harder.

I extend this file in production with a reporter agent and explicit expected_output on each task (JSON schema in the description). CrewAI will still return prose if you let it. I parse with a validator and fail the job if the scout did not emit a list.

Tools belong on the scout and analyst, not on the reporter. If the reporter can search the web, it will "fill in" CVEs it never received. That is a policy bug disguised as helpfulness.

What I pin before the first kickoff

• Inventory as data, not as vibes in a backstory. A JSON file or collection of services and versions.
• Allowlisted sources. NVD, vendor advisories, your scanner export—not an unbounded browse.
• Rate limits. OSINT tools will get you blocked. The API-gateway lessons apply here too.
• Secrets. The crew runs with the same tenancy rules as the rest of the backend. No prompt should contain another customer's SBOM.

How do I connect the AI core to MERN?

Python can own the agent loop. Value shows up when operators see results in a secure UI:

• MongoDB stores variable JSON threat payloads without a rigid schema.
• Node.js and Express can stream live agent status over websockets.
• React and Next.js let operators trigger workflows and inspect reports in a scannable dashboard.

I treat a run as a document:

jobs/{id}
  status: queued | running | succeeded | failed
  inventoryRef
  scoutArtifacts[]
  analystDecisions[]
  reportMarkdown
  tokenUsage
  error

Node enqueues. A worker process runs kickoff, writes artifacts incrementally, and emits socket events (scout.done, analyst.done). React does not wait for a single giant string at the end. Operators can cancel. Cancel is a product feature; unbounded crews are a cost feature.

Auth on the dashboard is not optional. Threat intel plus inventory is a map of your weaknesses. Same session rules as the rest of the admin app.

Scout vs analyst vs reporter vs a single prompt

The shift from reactive security to proactive autonomous hunting is already underway. Turning raw logs into patchable findings is becoming standard practice for next-generation systems builders. The teams that succeed are the ones who still know which box is a scanner, which box is a model, and which box is a human change window.

How do I keep false positives from paging the whole company?

An autonomous pipeline that cannot be wrong will never ship. An autonomous pipeline that cannot be audited will ship once. I keep a review queue for anything the analyst marks exploitable or patch_now. The reporter can draft the ticket; a human assigns the sprint. That is not a lack of faith in LLMs. It is how you avoid training the org to ignore the dashboard.

Evaluate the crew the same way you evaluate RAG. Freeze a week of known inventory plus a fixture of CVEs (including ones that do not apply). Score: did the scout retrieve the relevant advisory, did the analyst drop the irrelevant ones, did the reporter cite identifiers that exist? If you only read the markdown, you will grade tone. Grade the join.

Rate-limit outbound tools and log every URL the scout touched. Product teams in Lahore shipping to customers in the EU or the US still inherit the scout's request trail. Keep it boring and allowlisted.

I build production AI and full-stack systems from Lahore, and this pipeline shape is the one I trust when a product team wants "agents" without surrendering the asset list to a chat window. Anber Aziz is the author because I have had to sit with engineers who needed a patch order by Friday, not a chain-of-thought.

If you are designing a threat-intelligence or assessment workflow that has to land in a real dashboard, services is the overview of how I work, and contact is the direct line.

FAQ

Why use multiple agents instead of one LLM prompt for vulnerability assessment?

One prompt mixes gathering, judging, and writing, so errors in retrieval look like errors in analysis. Split scout, analyst, and reporter so each step has a tool set, a schema, and a place to fail. You can retry a scrape without regenerating the whole report.

How do CrewAI and LangChain work together in a security pipeline?

LangChain is the tool and model layer—search, HTTP, parsers, Groq or other chat models. CrewAI is the role and task layer—who does what, in what order. I keep tools thin and deterministic, and I keep crew tasks narrow so the analyst cannot wander into writing marketing copy.

Can this replace a traditional vulnerability scanner?

No. Agents correlate and explain; scanners and SBOMs still find packages and CVEs. The pipeline should consume scanner output, asset inventory, and public advisories, then produce a prioritized narrative. Treat LLM scoring as an assist, not as a CVSS authority.

How do I show agent results in a MERN or Next.js dashboard?

Write each run to MongoDB as a job document with status, artifacts, and errors. Stream status over a WebSocket from Node. Let React render the latest report and a log of tool calls. The Python crew should not own the UI session.

What is a realistic first pipeline for a startup in Pakistan?

One sequential crew: scout latest CVEs for your stack, analyst maps them to a hand-maintained inventory, reporter writes a markdown brief. Product and engineering teams in Lahore can ship that without a SOC platform. Add parallelism after the sequential path is evaluable.