Skip to main content

AI Labs — Complete Feature Reference

AI Labs is ThreatWeaver's suite of AI-powered security analysis tools. It sits on top of the vulnerability data collected by the Exposure Management and AppSec modules and transforms raw findings into actionable intelligence — remediation plans, escalation tickets, executive narratives, and conversational analysis — without requiring a security analyst to write a single prompt.

This document covers the philosophy behind AI Labs, each of the six production features in depth, how to configure and operate them, their limitations, and what data they send to external AI providers.

The Problem AI Labs Is Solving​

Analyst Burnout and Alert Fatigue​

The average enterprise security team manages tens of thousands of vulnerability findings at any given time. A mid-sized organization running Tenable scans weekly against 5,000 assets will accumulate more open findings than three full-time analysts can meaningfully review in a month. The result is not a security team that ignores alerts — it is a security team that has developed triage heuristics that inevitably miss things.

The problem is not that security teams lack skill. It is that the volume of work that requires human judgment has grown faster than the supply of qualified humans. According to industry surveys, the average security analyst spends 35–40% of their time on tasks that are repetitive, formulaic, or primarily translational — writing tickets, drafting executive summaries, looking up remediation steps for vulnerability types they have seen dozens of times before.

That 35–40% is where AI Labs operates.

The Speed Gap in Remediation​

The time between a vulnerability being discovered and a remediation ticket landing in an engineering team's queue is, in most organizations, measured in days. The discovery happens in the scanner. Then an analyst reviews it. Then they write a description. Then they file a Jira ticket. Then engineering reviews the ticket and asks questions. Then someone looks up the fix. This process takes an average of 3–7 days for critical findings in organizations without automated workflows.

For critical vulnerabilities with public exploits (tracked in CISA KEV), 3–7 days is enough time for a breach. AI Labs compresses the analyst-to-ticket phase from hours to seconds.

The Translation Problem​

Security teams speak in CVE numbers, CVSS scores, and OWASP categories. Engineering teams speak in story points and acceptance criteria. Executives speak in business risk and regulatory exposure. AI Labs handles the translation layer — taking the same underlying finding and rendering it as a technical remediation plan for developers, a Jira ticket for the engineering workflow, and an executive narrative for the CISO's board slide.

The Philosophy: Augment, Not Replace​

AI Labs is built on a specific principle: AI should make experienced security analysts faster and more effective, not replace their judgment.

Every feature in AI Labs requires a human to initiate it. Every output is clearly labeled as AI-generated. No AI output is applied automatically — no tickets are filed without a human reviewing and approving the content, no exceptions are accepted without a human signing off, no remediation plans are executed without human review.

This is not a limitation — it is a design choice. LLM outputs are probabilistic. The same input can produce slightly different outputs on successive calls. A hallucinated fix plan that references a configuration option that does not exist in the target system's version is worse than no fix plan at all. AI Labs treats AI output as a first draft that a skilled analyst reviews and refines, not as a finished product.

The practical implication: AI Labs is most valuable when the analyst is the bottleneck, not when the analyst is absent. Organizations that try to run AI Labs with no security review of outputs will experience the same failure mode as those who never validate their scanner findings — low-quality outputs that erode trust.

Architecture Overview​

The AI Orchestrator is the central coordinator. It receives a request (e.g., "generate a fix plan for vulnerability X"), pulls the relevant data from the database, sanitizes the combined input, sends it to the configured LLM provider, and returns the structured output. Every call is logged to the AiUsageLog entity with token counts and cost estimates.

Security Architecture​

The AI pipeline includes multiple layers of security controls that run before any data is sent to an external LLM:

Prompt injection protection. The input sanitizer checks all user-supplied text against 34 injection patterns (v2.2 ruleset) covering classic prompt injection ("ignore all previous instructions"), persona hijacking ("you are now..."), delimiter injection ("new system prompt:"), and modern jailbreak techniques (DAN mode, developer mode, etc.). Inputs matching any pattern are rejected before reaching the LLM.

Input length limits. Plain text inputs are capped at 10,000 characters. Structured data inputs (vulnerability lists, JSON payloads) are capped at 50,000 characters. Inputs exceeding the absolute maximum of 50,000 characters are rejected.

Sensitive data stripping. The sensitiveDataSanitizer service strips credentials, tokens, internal IPs in RFC 1918 ranges, and other sensitive fields from vulnerability data before it is sent to external LLM providers. This is described in detail in the Privacy section below.

Output sanitization. LLM outputs are sanitized with stripHtmlTags and csvSafeCell before being returned to the client or written to the database, preventing stored XSS and CSV injection.

Feature 1: AI Fix Planner​

What It Does​

The AI Fix Planner takes a specific vulnerability finding — whether it came from a Tenable scan or from the ThreatWeaver AppSec scanner — and generates a step-by-step remediation plan tailored to the affected asset and technology stack.

A generic fix plan for "SQL injection" tells a developer to use parameterized queries. An AI Fix Planner output tells that same developer: "This SQL injection was found in the /api/users/search endpoint. The vulnerable code pattern appears to use string concatenation in the query builder. Here is how to fix it with your framework's parameterized query API, here is how to verify the fix locally, and here is the security test you should add to your CI/CD pipeline to prevent regression."

The difference is that the fix plan is contextual. It knows the CVE identifier, the affected plugin family, the asset's operating system, the severity, and (for AppSec findings) the specific endpoint and request that triggered the vulnerability. The LLM receives all of this context and produces a plan appropriate to the specific situation, not a generic category description.

What Gets Generated​

A fix plan output contains:

  • Executive summary — one or two sentences describing the vulnerability in business terms
  • Technical description — what the vulnerability is, why it is dangerous, what an attacker could do with it
  • Remediation steps — numbered, ordered steps to fix the issue. For application vulnerabilities, these include code snippets in the relevant language where applicable
  • Verification steps — how to confirm the fix worked (scanner retest, manual testing steps, CI test)
  • References — links to NVD, vendor advisories, OWASP documentation, or framework-specific documentation where relevant
  • Estimated effort — rough engineering time estimate (S/M/L/XL), which feeds into the VFP work package planner

How to Use It​

  1. Navigate to AI Labs → Fix Plan Generator (/ai-labs/fix-plan)
  2. Select a vulnerability from the picker (filtered by severity, asset, or finding type)
  3. Optionally add context in the free-text field: team names, framework versions, constraints ("we cannot restart the service during business hours")
  4. Click Generate Fix Plan
  5. Review the output. Use the Copy button to copy the full plan, or use Create Ticket to pass it directly to the Ticket Writer

Fix plans can also be generated from the Exposure Management vulnerability detail view by clicking the Generate Fix Plan button on any finding.

Integration with VFP​

Fix plans generated from VFP work package items are stored against the work package and visible to the engineering team assigned to that package. This creates a direct link between the vulnerability management workflow and the remediation guidance without requiring the analyst to manually attach documents.

Accuracy Notes​

Fix plans are accurate for common, well-documented vulnerability types that the LLM has seen extensively in training data (SQLi, XSS, SSRF, misconfigured headers, dependency CVEs). They are less reliable for:

  • Zero-day vulnerabilities where there is no public fix guidance yet
  • Proprietary or niche frameworks where the LLM has limited training coverage
  • Vulnerabilities that require business-logic-level fixes (e.g., broken access control in a custom authorization system)

Always have an engineer review the fix plan before implementing it in production.

Feature 2: AI Ticket Writer​

What It Does​

The AI Ticket Writer converts vulnerability findings into formatted ticket content ready to paste into Jira, ServiceNow, GitHub Issues, or any other issue tracker. It produces a complete ticket draft — title, description, acceptance criteria, affected components, priority justification, and reproduction steps — so that the analyst does not have to write any of this from scratch.

The goal is to make the ticket good enough that an engineer can pick it up and start work without needing to go back to the security team with questions. A well-written security ticket is one where the affected component is named, the exact endpoint or configuration is identified, the business risk is clearly stated, and the acceptance criteria tell the developer what "done" looks like from a security perspective.

Ticket Fields Generated​

FieldContent
TitleConcise, action-oriented: "Fix SQL injection in /api/users/search — HIGH severity"
DescriptionTechnical description of the vulnerability, what was found, where, and what an attacker could do
Business ImpactNon-technical statement of the risk for the engineering manager
Affected ComponentsService name, file path, endpoint, or configuration item
Steps to ReproduceFor AppSec findings: exact request that triggered the vulnerability. For Tenable findings: plugin details and asset information
Acceptance CriteriaBullet list of what must be true for the ticket to be closed: scanner clean, code review approved, test added
Priority JustificationWhy this is P1/P2/P3 based on CVSS, EPSS, asset criticality, and business context
ReferencesCVE links, OWASP documentation, vendor advisories
Labels / TagsSuggested Jira labels based on vulnerability type and compliance framework mapping

Target Issue Trackers​

The Ticket Writer produces markdown-formatted content that is compatible with Jira's description editor, GitHub Issues, and ServiceNow. It does not directly integrate with these systems via API at present — it generates the content for you to copy-paste or use via the Jira integration (when configured). Direct API push to Jira and ServiceNow is on the roadmap.

How to Use It​

  1. Navigate to AI Labs → Ticket Writer (/ai-labs/ticket-writer)
  2. Select one or more vulnerability findings to include in the ticket
  3. Choose the target format (Jira, ServiceNow, GitHub, or Generic Markdown)
  4. Add any context in the optional notes field: team name, sprint, deadline, escalation reason
  5. Click Generate Ticket
  6. Review the output, edit any fields you want to adjust, then copy or export

You can also bulk-generate tickets for a set of findings by selecting multiple items in the Exposure Management findings list and choosing Bulk Ticket Writer from the action menu.

Writing Effective Ticket Context​

The Ticket Writer produces better output when you provide context in the optional notes field:

  • Team name: "This goes to the Payments API team"
  • Sprint or deadline: "Needs to be fixed before the PCI audit on May 15"
  • Constraints: "We are on Python 2.7 for this service — fix must be compatible"
  • Business context: "This endpoint handles PII for EU customers — GDPR exposure"

Feature 3: AI Executive Summary​

What It Does​

The AI Executive Summary Generator produces a C-suite-ready narrative of your organization's current security posture. It ingests dashboard metrics — open vulnerability counts by severity, WeaverScore trend, asset counts, remediation velocity, compliance gaps, and AppSec scan results — and synthesizes them into a document that a CISO can put in front of a board without editing.

The output is written in business language, not security jargon. It does not say "47 critical-severity CVEs with EPSS scores above 0.7 are in open state." It says "We currently have 47 critical vulnerabilities that security researchers believe are likely to be exploited in the wild. Three of them are on internet-facing systems. We have remediation plans for all three and expect to close them within two weeks."

Report Sections​

A generated executive summary contains:

Security Posture Snapshot Current WeaverScore vs. last period, direction of travel, key drivers of the change. Written as a one-paragraph narrative the CISO can read aloud.

Top 3 Priority Issues The three highest-priority items requiring executive awareness or action. Selected based on severity, asset criticality, exploit availability, and business exposure (not just CVSS score). Each includes a one-sentence description, the business risk, and the recommended action.

Trend Analysis How the organization's vulnerability profile has changed over the past 30/60/90 days (configurable). Are we getting better or worse? Are we remediating faster than new findings are being discovered?

Compliance Exposure Any open findings mapped to compliance frameworks (PCI-DSS, SOC 2, ISO 27001, OWASP Top 10). Stated as "X findings are potentially relevant to your upcoming SOC 2 audit" rather than technical detail.

Remediation Velocity How many findings the team has closed in the reporting period and how that compares to the previous period. Phrased as productivity and trend, not as a performance scorecard.

Recommended Actions Three to five specific actions for the executive to authorize or communicate. These are management-level actions, not technical ones: "Approve budget for emergency patch deployment on the Payments cluster," "Request status update from the Infrastructure team on the critical OpenSSL finding," "Schedule board briefing on the cloud misconfiguration findings."

PDF Export​

Executive summaries can be exported as PDF documents via the Export to PDF button. PDFs are generated server-side using PDFKit. Note that the PDF format includes text and tables but does not include the interactive charts from the web view. For a presentation-quality export, copy the text into your organization's document template.

How to Use It​

  1. Navigate to AI Labs → Executive Summary (/ai-labs/executive-summary)
  2. Select the reporting period (last 30 days / last quarter / custom date range)
  3. Choose which modules to include: Exposure Management, AppSec, Cloud Security, Identity Security
  4. Optionally set the audience: CISO-level, Board-level, or Audit-level (adjusts the technical detail and tone)
  5. Add any context in the notes field: upcoming audits, recent incidents, business events that provide context
  6. Click Generate Summary
  7. Review, edit, and export or share

Scheduling​

Executive summaries can be scheduled for automatic generation on a weekly or monthly cadence. Scheduled summaries are emailed to configured recipients (requires email integration) and stored in the Generated Reports section.

Feature 4: AI Root Cause Analysis​

What It Does​

The Root Cause Analyzer goes beyond telling you what a vulnerability is — it explains why it exists. This distinction matters because the same underlying root cause often produces multiple vulnerability findings, and fixing each finding individually without addressing the root cause means the problem recurs.

For example: five SQL injection findings in different endpoints of the same application might all trace back to a single root cause — a utility method in the database layer that constructs queries via string formatting instead of parameterized queries. Fixing four of the five endpoints and not fixing the utility method means the sixth endpoint (or the next feature added) will be vulnerable too.

The Root Cause Analyzer identifies these patterns by examining clusters of related findings together, not individually.

Analysis Types​

Cluster Analysis Examines a set of findings with common characteristics (same CVE family, same endpoint pattern, same misconfiguration class) and identifies the shared root cause. Outputs a root cause statement plus recommended architectural fix.

Single Finding Deep Dive For a single AppSec finding, explains in detail why the vulnerability exists at a code/design/configuration level — not just what it is. "This SSRF exists because the URL-fetching utility does not validate whether the target URL resolves to an internal IP address before making the request. The fix is schema and IP validation at the input boundary."

Trend Root Cause Examines the vulnerability trend over time: if the same vulnerability type keeps appearing in scans despite remediation tickets being filed, the Root Cause Analyzer identifies why remediation is not sticking. This might be a missing test in CI/CD, a shared library being pulled from an uncontrolled source, or a developer training gap.

Root Cause Categories​

The analyzer classifies root causes into categories that map to remediation strategy:

CategoryExampleStrategic Fix
Missing input validationSQL injection, XSS, command injectionAdd validation library or framework control at input boundary
Broken access controlBOLA, IDOR, privilege escalationRedesign authorization model; add policy enforcement point
Insecure configurationDefault credentials, exposed admin panels, disabled TLSConfiguration management process; IaC policy checks
Dependency vulnerabilityThird-party library CVESCA scanning in CI/CD; automated dependency updates
Design flawRace condition, mass assignment, business logic bypassArchitecture review; threat modeling session
Cryptographic weaknessWeak cipher, broken hash, key reuseCryptography library standardization; key management review
Data exposureExcessive data in API responses, PII in logsData classification; response field allowlisting

How to Use It​

  1. Navigate to AI Labs → Root Cause Analyzer (/ai-labs/root-cause)
  2. Select findings to analyze: pick a single finding for deep dive, or select multiple findings for cluster analysis
  3. Optionally choose the analysis type (cluster vs. single vs. trend)
  4. Click Analyze Root Cause
  5. Review the output — the root cause statement, category classification, affected scope, and recommended strategic fix
  6. Use Generate Remediation Plan to feed the root cause analysis back into the Fix Planner for a more comprehensive remediation plan

Feature 5: AI Exception Handler​

What It Does​

Not every vulnerability can be fixed immediately. Sometimes a critical library cannot be patched without breaking a dependent system. Sometimes the vulnerable component is being decommissioned in 60 days and patching it is not worth the engineering cost. Sometimes a compensating control genuinely reduces the risk to acceptable levels.

In these cases, security teams need to formally accept the risk — and that requires documentation. A risk acceptance document needs to state the finding, the business reason for not remediating, what compensating controls are in place, the residual risk, who approved the exception, and when it expires.

Most security teams write these from scratch every time, often pulling from a Word template that has not been updated in years. The result is inconsistent, incomplete documentation that does not hold up to audit scrutiny.

The AI Exception Handler drafts this documentation automatically from the finding data plus a few fields of context the analyst provides.

Exception Document Components​

A generated exception document includes:

Finding Summary The vulnerability, severity, affected asset, and discovery date — pulled automatically from the finding record.

Exception Rationale Written from the context the analyst provides ("we cannot patch this library without breaking the payment processor integration"). The AI expands this into a complete business justification that reads professionally and covers the key questions an auditor would ask.

Risk Assessment An honest evaluation of the residual risk given the compensating controls. The AI does not minimize risk — it states it clearly, including what a threat actor could do with the vulnerability and the likelihood of exploitation based on EPSS and CVE metadata.

Compensating Controls A structured list of controls currently in place that reduce the risk: network segmentation, WAF rules, monitoring, access restrictions, etc. The analyst provides the controls; the AI formats them in audit-appropriate language and assesses their effectiveness.

Approval Workflow Required approver fields (blank for the analyst to fill in): business owner, security manager, CISO. Exception expiry date (defaults to 90 days, configurable).

Audit Trail Note A statement of when this exception was created, by whom, and the version of ThreatWeaver that generated it. This creates a traceable record for compliance purposes.

How to Use It​

  1. Navigate to AI Labs → Exception Assistant (/ai-labs/exception-assistant)
  2. Select the vulnerability finding for which you are requesting an exception
  3. Fill in the mandatory context fields:
    • Reason for exception: why the finding cannot be remediated now
    • Compensating controls: what controls are in place (can be a bulleted list)
    • Expected remediation date or decommission date: when the exception should be revisited
  4. Click Draft Exception Document
  5. Review the output carefully. The AI may flag concerns — for example, if the compensating controls you listed do not actually address the attack vector, it will note this
  6. Edit, approve internally, and save. The exception is linked to the finding in ThreatWeaver and the finding is marked with an Exception status

What the AI Flags​

The Exception Handler is designed to be honest, not just a rubber stamp. It will flag in the output if:

  • The compensating controls listed do not reduce the specific attack vector of the finding
  • The exception period requested is longer than 180 days for a Critical finding (it will generate the document but add a risk note)
  • The finding is on a CISA KEV list entry (active exploitation in the wild — the document will include a prominent risk statement)
  • The finding maps to a compliance control with a hard remediation requirement (e.g., PCI-DSS 6.3.3 for critical patches)

These flags appear in the document as formatted callout boxes and are designed to be included in the final document so that the approver has full visibility.

Feature 6: AI Chat​

What It Does​

AI Chat is a conversational interface for querying your vulnerability data using natural language. Instead of navigating to the Exposure Management dashboard and applying multiple filters to answer "how many critical vulnerabilities on internet-facing Windows servers are more than 90 days old?", you can ask that question in the AI Chat window and get an answer in seconds.

AI Chat is not a general-purpose chatbot. It is grounded in your actual ThreatWeaver data — it queries the database to answer questions, it does not generate answers from training data alone. When you ask "which assets have the most critical vulnerabilities?", it runs a database query against your tenant's findings and returns real numbers.

The chat interface also handles more analytical questions that require synthesizing data: "Summarize the AppSec findings from last week's scan," "Which compliance framework has the most open gaps?", "Is our remediation velocity improving?"

See the AI Chat Complete Guide for full documentation on query types, examples, and limitations.

How the Parameter Extractor Works​

When you submit a query, the AI parameter extractor (v4.0) parses your natural language into structured filter conditions before the database query is executed. This extractor understands:

  • Severity terms: "critical", "high", "medium", "low", "info"
  • Time windows: "last 30 days", "this quarter", "older than 90 days", "from last week"
  • Asset attributes: OS type ("Windows servers"), network exposure ("internet-facing"), environment ("production")
  • Vulnerability attributes: CVE IDs, plugin families, exploit availability, KEV status, patch availability
  • Compliance frameworks: "PCI-DSS", "SOC 2", "ISO 27001", "OWASP Top 10"
  • Count and sort modes: "how many", "top 10", "newest first", "highest CVSS"
  • Security terms: "SQL injection", "XSS", "RCE", "SSRF" — mapped to plugin name searches

The extractor runs locally (no LLM call needed for parsing) and the structured filters are passed to the AI Query Engine, which builds the database query. The LLM is then called to synthesize the data into a narrative response.

How to Use It​

  1. Navigate to AI Labs → AI Chat (/ai-labs/chat)
  2. Type your question in natural language in the chat input
  3. Review the response — data-backed answers include a View Source Data link that shows the underlying findings
  4. Follow up with additional questions in the same conversation thread
  5. Use Export Conversation to save the chat as a PDF or markdown file

Configuration​

Required: LLM Provider Setup​

AI Labs requires at least one LLM provider to be configured. Without an active provider, all AI endpoints return an error.

Navigate to AI Labs → AI Settings (/ai-labs/settings) to configure providers.

Anthropic (Claude) — Recommended Default​

ThreatWeaver's AI pipeline was designed and optimized for Anthropic's Claude models. Claude's instruction-following, structured output quality, and refusal to hallucinate confidently on unknown topics makes it well-suited for security analysis tasks.

Provider Type: anthropic
API Key: your ANTHROPIC_API_KEY
Model: claude-3-5-sonnet-20241022 (recommended) or claude-3-haiku-20240307 (lower cost)
Max Tokens: 4096 (fix plans, summaries) / 1024 (chat responses)
Temperature: 0.2 (recommended — lower temperature = more consistent, factual output)

Set the environment variable on the backend:

ANTHROPIC_API_KEY=sk-ant-...

OpenAI (GPT-4)​

OpenAI's GPT-4 and GPT-4o models are also supported.

Provider Type: openai
API Key: your OPENAI_API_KEY
Model: gpt-4o (recommended) or gpt-4-turbo
Max Tokens: 4096
Temperature: 0.2

Set the environment variable on the backend:

OPENAI_API_KEY=sk-...

Local Models​

ThreatWeaver supports local model endpoints compatible with the OpenAI API format (Ollama, LocalAI, LM Studio, vLLM). Use the local provider type and set the apiEndpoint to your local server URL.

Provider Type: local
API Endpoint: http://localhost:11434/v1
Model: llama3:8b (or any model your local server supports)
Max Tokens: 2048
Temperature: 0.1

Note: Local models produce significantly lower quality output than Claude or GPT-4 for complex security analysis tasks. This option is suitable for privacy-sensitive environments where no data can leave the organization's infrastructure, but output quality will be degraded.

Provider Selection Priority​

If multiple providers are configured, ThreatWeaver uses the following priority:

  1. The provider marked as Default in AI Settings
  2. If no default is set, the first active provider by creation date

Individual users can configure their own provider in User Settings → AI Provider, which overrides the tenant default for their requests.

Feature Flag and License Gate​

AI Labs is controlled by two independent gates:

GateWho Controls ItEffect When Disabled
ai_features license moduleVendor (BluCypher)All AI endpoints return HTTP 404 — module is invisible to the tenant
ai_enabled feature flagTenant adminAll AI endpoints return HTTP 404 — module is hidden but license is still active

Both gates must be active for AI Labs to function. The feature flag allows tenant administrators to temporarily disable AI features without contacting the vendor.

Privacy and Data Handling​

Understanding what data is sent to external LLM providers is important for organizations with data classification policies, privacy regulations, or contractual restrictions on data sharing with third parties.

What Is Sent to the LLM​

When you use an AI Labs feature, the following data is sent to the configured LLM provider (Anthropic or OpenAI):

Data ElementSent?Notes
Vulnerability description (CVE, plugin name, severity)YesPublic vulnerability information
Asset hostnameYes, but can be anonymizedSee anonymization setting below
Asset IP addressNoStripped by default (RFC 1918 and public IPs)
Vulnerability output / evidence textYes, sanitizedCredential patterns removed before sending
Operating system and technology stackYesFor context on fix plans
CVSS score, EPSS scoreYesPublic data
User-provided notes and contextYesUser-controlled; do not include credentials
Tenant name or customer identityNoNever sent
User identity (email, name)NoNever sent
Raw scan output / payloadsYes, for AppSec findingsAttack payloads sent for context

Sensitive Data Stripping​

The sensitiveDataSanitizer service runs before every LLM call and removes:

  • Patterns matching credential formats (passwords, API keys, tokens) found in scan evidence
  • IPv4 and IPv6 addresses in RFC 1918 ranges (10.x.x.x, 172.16.x.x, 192.168.x.x)
  • Patterns matching internal domain suffixes configured by the tenant admin
  • Any content flagged by the vulnerability record as containing PII

If you are sending vulnerability data that contains credential exposure (e.g., a finding from the AppSec scanner that captured a password in a response), the credential value is replaced with [REDACTED] before the data reaches the LLM.

Asset Anonymization​

In AI Settings, you can enable Asset Anonymization Mode. When enabled, hostnames are replaced with pseudonyms (asset-001, asset-002) before being sent to the LLM. This prevents your internal host naming conventions from leaving your environment. Note that anonymization reduces the quality of fix plan output because the LLM cannot use hostname patterns to infer technology stacks.

Data Residency​

ThreatWeaver does not control the data residency of the LLM provider you configure:

  • Anthropic: Processes data in the United States. Anthropic does not use API inputs to train models.
  • OpenAI: Processes data in the United States by default. OpenAI API data is not used for model training per their enterprise policy.
  • Local models: Data does not leave your infrastructure.

For EU organizations with GDPR obligations, local model deployment is the only option that ensures data does not cross jurisdictional boundaries. If you require a cloud LLM provider in an EU-resident configuration, check with the provider for their EU endpoint availability.

LLM Provider Data Retention​

Both Anthropic and OpenAI retain API request and response data for a period defined in their terms of service (typically 30 days). This means that vulnerability data sent to the LLM provider may be retained by that provider for up to 30 days. Review the provider's data processing agreement for your use case.

AI Accuracy and Limitations​

Why Human Review Is Mandatory​

LLMs are probabilistic text generators. They do not reason in the way humans do — they predict the most likely next token given their training data and the current context. This means:

  • Fix plans may reference APIs, configuration options, or version numbers that do not exist in the specific version of the software running on your asset. Always have an engineer validate the fix before implementing it.
  • Root cause analysis may miss the actual root cause if the pattern in your data is unusual or not well-represented in training data.
  • Executive summaries may frame risk in ways that are technically correct but strategically misleading — for example, emphasizing findings that have high CVSS scores but low actual business impact.
  • Exception documents may miss compliance-specific requirements that are not widely documented in public training data.

None of these mean AI Labs is not useful — they mean it is a first draft, not a final product.

Hallucination Signals​

ThreatWeaver cannot detect hallucinations automatically, but you can recognize common patterns:

  • Fix plans that reference library versions newer than the current release date
  • Fix plan code snippets that use method names that do not exist in the framework's documentation
  • Root cause analyses that are plausible-sounding but too generic to be actionable
  • Executive summaries that include statistics or benchmarks without citing a source

If an AI output seems too confident, too specific, or references something you cannot verify, treat it with additional skepticism.

Non-Deterministic Output​

LLM outputs are not reproducible. Running the AI Fix Planner on the same finding twice will produce different but semantically similar outputs. This is expected behavior. If you need consistent outputs across your organization, use the AI Prompt Service to configure specific prompt templates that constrain the format and scope of the output.

No Security-Specific Fine-Tuning​

AI Labs uses general-purpose LLMs (Claude, GPT-4). These models have broad knowledge of security topics from their training data but are not fine-tuned on ThreatWeaver-specific vulnerability data or your organization's internal security posture. This means:

  • The LLM does not know your organization's risk tolerance without you telling it
  • The LLM does not remember previous sessions or learn from your feedback
  • The LLM's security knowledge has a training cutoff date and may not know about very recent CVEs or attack techniques

Cost Management​

Every AI Labs call that reaches an external LLM provider consumes tokens and costs money. ThreatWeaver tracks all AI usage per tenant and per user in the AiUsageLog entity.

Viewing Usage​

Navigate to AI Labs → AI Settings → Usage Logs to see:

  • Total calls by feature type (fix plans, summaries, chat, etc.)
  • Token consumption broken down by input and output tokens
  • Estimated cost per call and total cost for the period
  • Usage by individual user

Cost Control Mechanisms​

Caching. The aiCache service deduplicates identical inputs. If two analysts generate a fix plan for the same finding with the same parameters within the cache window, the second request returns the cached response without making a second LLM call. Cache TTL is configurable (default: 24 hours for fix plans, 1 hour for chat).

Rate limiting. A per-user sliding window rate limiter prevents any single user from making excessive AI calls. The default limit and window are configurable in AI Settings. Users who exceed the rate limit receive an HTTP 429 response.

Budget alerts. ThreatWeaver does not currently enforce hard spending caps at the API level. Monitor usage through the Usage Logs page and set alerts in your LLM provider's billing dashboard.

Approximate Token Costs​

These are estimates based on Claude 3.5 Sonnet and GPT-4o pricing as of Q1 2026. Verify with the current provider pricing page.

FeatureAvg Input TokensAvg Output TokensApprox Cost per Call
Fix Plan~2,000~800$0.01–$0.04
Ticket Writer~1,500~600$0.008–$0.03
Executive Summary~4,000~1,500$0.02–$0.08
Root Cause Analysis~3,000~1,000$0.015–$0.06
Exception Handler~2,500~1,200$0.015–$0.06
AI Chat (per turn)~1,000~400$0.005–$0.02

A team of 5 analysts making 20 AI Labs calls per day would spend approximately $5–$15/day on LLM costs depending on feature mix and provider. At scale, using Claude Haiku or GPT-4o-mini for chat queries and reserving the larger models for fix plans and executive summaries significantly reduces cost.

License Gating Reference​

RequirementDetail
License moduleai_features must be in the tenant's allowedModules list
Feature flagai_enabled must be set to true in the tenant feature flags
PermissionMost read operations require no special permission. Provider management requires the MANAGE_AI permission
LLM providerAt least one active provider with a valid API key must be configured

When AI Labs is not licensed or not enabled, the AI Labs menu section does not appear in the sidebar. This prevents users from navigating to non-functional pages.

Troubleshooting​

"AI module is not enabled" (HTTP 404)​

Check both the license gate and the feature flag:

  1. Verify the tenant license includes ai_features (Admin → Tenant Settings → License)
  2. Verify the ai_enabled feature flag is active (Admin → Feature Flags)

"No AI provider configured"​

Navigate to AI Labs → AI Settings and add an LLM provider with a valid API key. The provider must have isActive: true.

Slow or failed AI responses​

  • Check the LLM provider's status page (status.anthropic.com / status.openai.com)
  • Check the AI Usage Logs for error entries — error messages from the LLM provider are logged
  • Verify the API key is valid and has not expired or hit spending limits
  • For local models: verify the local server is running and the endpoint URL is correct

Rate limit exceeded​

The user has made too many AI calls within the sliding window. Wait for the window to reset (default: 2 minutes) or ask an admin to increase the rate limit in AI Settings.

Poor quality outputs​

  • Ensure the AI provider model is set to a capable model (claude-3-5-sonnet or gpt-4o, not older or smaller models)
  • Lower the temperature setting (0.1–0.2 produces more focused, factual outputs)
  • Add more context in the optional notes field — the more specific context you provide, the more tailored the output
  • For fix plans: ensure the vulnerability finding includes the technology stack information (operating system, framework) — without this, the LLM defaults to generic advice

Summary Table​

FeatureUI PathPrimary AudienceRequires LLM CallCached
Fix Planner/ai-labs/fix-planSecurity analysts, engineersYesYes (24h)
Ticket Writer/ai-labs/ticket-writerSecurity analystsYesYes (24h)
Executive Summary/ai-labs/executive-summaryCISOs, security managersYesYes (1h)
Root Cause Analyzer/ai-labs/root-causeSecurity architects, analystsYesYes (24h)
Exception Handler/ai-labs/exception-assistantSecurity managers, GRC teamsYesNo
AI Chat/ai-labs/chatAll security team membersYes (per turn)Partial
AI Settings/ai-labs/settingsTenant administratorsNoN/A