Security Intelligence

Ghost’s security intelligence system provides layered vulnerability detection — from passive traffic analysis that runs automatically in the background, to AI-driven active testing with external security scanners, to runtime instrumentation with Frida for bypassing app protections.

When you switch Ghost to Security Mode, the entire interface transforms: the sidebar shows findings and targets instead of domains and bookmarks, the flow list highlights vulnerability severity, the inspector gains a findings tab and JWT decoder, and the AI agent switches from a QA engineer persona to a senior penetration tester following PTES (Penetration Testing Execution Standard) methodology.

Architecture

What this diagram shows:

All security detections — whether from the passive interceptor (54 checks across 3 tiers) or from active testing tools — flow through a deduplication engine before being stored. The dedup engine ensures the same finding is only reported once per session (e.g., if 100 responses from api.example.com are missing the HSTS header, you get one finding, not 100). The findings are stored in SQLite and streamed to the UI via WebSocket events.

Dual Mode

Ghost operates in two modes. Security intelligence activates when you switch to Security Mode.

Aspect	QA Mode	Security Mode
Sidebar	Scope Panel (domains, bookmarks)	Findings Panel (targets, severity stats)
Flow list	Standard columns	Severity dots, findings count, auth badges
Inspector	Headers, body, timing	Findings tab, auth analysis, JWT decoder
Agent persona	QA engineer	Senior penetration tester
Agent tools	QA tools (test generation, regression, export)	Security tools (scanners, attacker, Frida)
Accent color	Cyan/Blue	Red/Orange
Finding prefix	BUG-NNN	VULN-NNN

Security Sub-Modes

Sub-Mode	What’s Different
Web	Web + API security testing. No Frida tools in prompt, no mobile inspector context.
Mobile	Adds Frida tools section, mobile inspector context, mobile vulnerability taxonomy (certificate pinning, insecure local storage, root/jailbreak detection, sensitive data in logs, hardcoded secrets, deep link injection, clipboard leakage, missing binary protections, debug mode enabled, excessive permissions, weak encryption, man-in-the-disk).

Scan Modes

Scan modes control how aggressive the AI agent is allowed to be. They form a trust escalation chain — you start passive and can escalate as you get comfortable.

Passive (Default)

Observe and analyze captured traffic only. Ghost reads traffic that’s already flowing — it never sends additional requests.

Allowed:

• Analyze all captured flows for vulnerabilities
• Search traffic, get flow details, list endpoints
• List existing findings from the store
• run_trufflehog with --no-verification flag only (static secret scanning — scans existing data without making network requests)
• run_semgrep (static analysis for DOM XSS patterns)
• Browser read-only actions (browser_read_page, browser_query_all, browser_screenshot)
• proxy_inject_script for DOM annotation only (read-only highlights)

Forbidden: replay_request, send_http_request, attack_request, all other external scanners, all Frida tools, all browser modification actions

Active Safe

Test without modifying target data — like a security auditor who looks but doesn’t touch.

Allowed (in addition to everything in passive):

• GET requests freely, read-only POST endpoints
• All external scanners at safe configurations: nuclei, dalfox, ffuf, katana, nmap, sslscan
• run_sqlmap (risk capped at level 1 — detection only, no exploitation)
• attack_request for automated payload testing
• Browser click/fill actions
• frida_check, frida_list_apps, frida_trace (read-only function hooking)

Requires request_approval first: Data-modifying requests (POST/PUT/PATCH/DELETE that modify data), frida_bypass_ssl, frida_root_bypass, frida_inject, browser script injection

Active Full

Full exploitation capability. All tools unrestricted without approval.

Still requires request_approval: Data-modifying write operations (even in full mode, the agent asks before modifying production data), credential brute force (run_hydra)

Passive Detection

The SecurityInterceptor sits at the end of the interceptor pipeline (after storage), analyzing every response passively with 54 checks. It runs in OnResponse only — OnRequest is a no-op.

Target Filtering

The interceptor only scans traffic for hosts matching configured target patterns (using Go’s path.Match glob syntax):

*.mydomain.com
api.example.com
staging-*.internal.net

Port numbers are stripped before matching, and comparison is case-insensitive. Empty target list = scan nothing. This prevents noise from CDNs, analytics, and third-party services.

Core Checks (9)

Check	What It Detects	Severity	CWE
Plain HTTP	Non-TLS traffic to target hosts	High	CWE-319
URL Sensitive Data	Passwords, tokens, API keys in URL query parameters	High	CWE-598
Security Headers	Missing HSTS, X-Content-Type-Options, clickjacking protection	Medium/Low	CWE-319/16/1021
Dangerous CORS	Wildcard origin + credentials, reflected origin	High/Medium	CWE-942
Cookie Flags	Missing Secure, HttpOnly, SameSite on session cookies	Medium/Low	CWE-614/1004/1275
Info Leakage	Server version, X-Powered-By disclosure	Info	CWE-200
Sensitive Data in Body	AWS keys, GitHub/Slack/OpenAI tokens, private keys	Critical/High	CWE-200/321
Stack Traces	Java, Python, Go, Node.js, .NET in error responses	Medium	CWE-209
JWT Reflection	JWT tokens in response body, request JWT reflected, JWT claims reflected	High/Medium	CWE-200

Extended Checks — Tier 1: High Impact (10)

Check	Severity	CWE
CSP missing or weak (unsafe-inline, unsafe-eval, wildcard, data: in script-src)	Medium/Low	CWE-693
Private IP disclosure (RFC 1918, IPv6 link-local, EC2 hostnames)	Low	CWE-200
Credit card numbers (Visa/MC/Amex/Discover + Luhn validation)	High	CWE-359
Basic authentication over HTTP	High	CWE-522
Mixed content (HTTP resources in HTTPS pages)	Medium	CWE-311
Missing anti-CSRF tokens on POST forms	Medium	CWE-352
Directory listing enabled	Medium	CWE-548
SQL errors + framework debug pages (Django, Laravel, Spring, Express, Rails, Flask, ASP.NET)	Medium	CWE-209
Cache-Control missing on sensitive responses	Medium	CWE-525
Open redirect via Location header	Medium	CWE-601

Extended Checks — Tier 2: High Value (10)

Check	Severity	CWE
Missing Referrer-Policy	Low	CWE-200
Missing Permissions-Policy	Low	CWE-693
Cross-domain script without SRI	Low	CWE-829
Reverse tabnabbing (target=_blank without noopener)	Medium	CWE-1022
Dangerous JavaScript sinks (eval, document.write, innerHTML)	Info	CWE-79
Session ID in URL (JSESSIONID, PHPSESSID, sid)	Medium	CWE-598
Full path disclosure (/home/, /var/www/, C:\inetpub)	Low	CWE-200
Source map exposed (header + sourceMappingURL in JS)	Info	CWE-540
Debug headers (X-Debug-Token, X-ChromeLogger-Data)	Medium	CWE-200
Password returned in API response	High	CWE-200

Extended Checks — Tier 3: Comprehensive (25)

Email disclosure, suspicious comments, HSTS misconfiguration, cookie domain scope, password autocomplete, deprecated headers (X-XSS-Protection), X-AspNet-Version disclosure, X-Backend-Server disclosure, GraphQL introspection, sensitive JSON fields, CORS null origin, Java serialization, SSN patterns, cleartext password submission, user input reflection, insecure HTTP methods (TRACE), big redirect bodies, source code disclosure (PHP/ASP/JSP), compromised CDN domains (polyfill.io).

For full details on every check, see the Security Interceptor backend reference.

Body Scanning

Only text content types are scanned (8 prefix patterns). Maximum body size: 5 MB (maxBodyScanSize). All regex patterns are compiled once at package level (not per-call). HTML-specific checks (mixed content, anti-CSRF, SRI) only run when content-type contains html. JS-specific checks (dangerous sinks, source maps) only run when content-type contains javascript.

Session Cookie Heuristic

Cookie flag checks use isLikelySessionCookie() to avoid false positives on harmless cookies. Only cookies with names containing session-related substrings (session, token, auth, jwt, etc.) are flagged. Flag detection parses only the attributes portion (after first ;) to avoid false negatives on cookie names containing flag-like strings.

Deduplication

Each finding gets a dedup key formatted as host|type|title — for example, api.example.com|config|Missing HSTS Header. A UNIQUE database index on (session_id, dedup_key) ensures the same issue is only stored once per session.

Finding Model

Every security finding — whether from passive detection, active scanning, or AI analysis — follows the same structure:

Field	Type	Description
id	string	Unique ULID identifier
session_id	string	Which session this finding belongs to
flow_id	string	The specific HTTP flow where this was detected (nullable — some findings aren’t tied to a single flow)
dedup_key	string	Deduplication key: host|type|title
type	string	Category of vulnerability (see table below)
severity	string	Impact level: critical, high, medium, low, or info
confidence	float	How confident the detection is (0.0 to 1.0). A confidence of 0.95 means very likely a real issue. Lower values (0.7) indicate heuristic detections that may be false positives.
title	string	Short description of the finding (e.g., “Missing HSTS Header”)
description	string	Detailed explanation of the vulnerability and its impact
evidence	string	The specific data that triggered the finding (e.g., the header value, the leaked key, the stack trace excerpt)
remediation	string	How to fix the issue
cwe_id	string	Common Weakness Enumeration identifier (e.g., CWE-319) — the industry-standard vulnerability classification
owasp_id	string	OWASP Top 10 category (e.g., A02:2021) — the most well-known web application security risk list
status	string	Current review state: open, confirmed, false_positive, or fixed
source	string	What created this finding: passive (interceptor), active (scanners/attacker), or ai (agent analysis)
metadata	map	Additional key-value data specific to the finding
created_at	datetime	When the finding was first detected
updated_at	datetime	Last status change

Finding Types

Type	What It Covers
auth	Authentication and authorization issues — weak auth mechanisms, missing auth on endpoints, session fixation
injection	SQL injection, XSS, command injection, template injection, NoSQL injection
exposure	Data exposure — sensitive information in responses, leaked API keys, PII in URLs
config	Security misconfiguration — missing headers, dangerous CORS, verbose error messages
crypto	Cryptographic weaknesses — weak TLS versions, bad JWT configuration, missing encryption
access	Access control issues — IDOR (insecure direct object references), privilege escalation, broken authorization
session	Session management — cookie flag issues, session fixation, predictable session IDs

Finding Lifecycle

Status	Meaning
open	Newly detected, not yet reviewed by a human
confirmed	Reviewed and verified as a real vulnerability
false_positive	Reviewed and dismissed as not a real issue (the detection was wrong)
fixed	The vulnerability has been remediated

Source Attribution

Source	Created By
passive	SecurityInterceptor (runs automatically on every response matching target patterns)
active	External scanners (run_nuclei, run_dalfox, etc.) or attack_request payloads
ai	AI agent’s analysis of traffic patterns and flow data

Finding Numbering

Security findings use VULN-NNN prefix (e.g., VULN-001, VULN-002), while QA mode findings use BUG-NNN. This is managed by the EngagementState which tracks a sequential counter per session. The counter is zero-padded to 3 digits and capped at 100 findings per session.

Deduplication at the engagement level: the same finding type for the same endpoint is only counted once. Evidence files are tracked when the agent writes files like findings/VULN-001-sqli.md — the path is parsed to link the file back to the finding.

External Scanners

Ghost integrates external CLI security tools. There are 7 tools with full UI management (install, toggle, version detection) and 3 additional tools available only to the AI agent:

UI-Managed Tools (7)

These appear in the Security Tools panel where you can install them with one click, see their version, and toggle them on/off:

Tool	Purpose	What It Does
nuclei	Template-based vulnerability scanner	Runs 9,000+ security checks against target URLs. The most comprehensive single-tool scanner.
dalfox	XSS specialist scanner	Focused specifically on finding cross-site scripting (XSS) vulnerabilities with advanced payload generation.
ffuf	Path and parameter fuzzer	Discovers hidden directories, files, and parameters by trying thousands of common paths and names.
sqlmap	SQL injection detection	The industry-standard SQL injection tool. In Active Safe mode, restricted to risk level 1 (detection only, no exploitation). Requires Python.
trufflehog	Secret scanner	Scans for leaked secrets — API keys, passwords, tokens — using 800+ detector types. In passive mode, runs with --no-verification (checks patterns but doesn’t verify against live services).
katana	JavaScript endpoint discovery	Crawls JavaScript files to find hidden API endpoints, internal URLs, and hardcoded paths.
semgrep	Static analysis for DOM XSS	Analyzes JavaScript code for DOM XSS patterns using semantic analysis rules. Requires Python.

Tool management:

• Auto-detection: Ghost checks for each tool using exec.LookPath + a version command (10-second timeout) on startup
• Installation: SSE (Server-Sent Events) streaming shows real-time progress during installation (10-minute timeout, 512 KB output cap)
• Toggle: Per-tool enable/disable stored in ~/.ghost/config.toml under security.disabled_tools

Input validation: All scanner tools validate their inputs before execution to prevent flag injection and SSRF attacks:

• Host validation (ValidateExternalHost) — every target hostname is checked: empty hosts are rejected, hosts that look like CLI flags (starting with -) are rejected, and the hostname is DNS-resolved with the resulting IP checked against loopback, private (RFC 1918), link-local, and unspecified addresses. Hosts that are explicitly configured as scan targets bypass the private-IP check (since the user intentionally chose them).
• Parameter allowlisting — tools that accept enum-like parameters (e.g., nmap’s scan type -sV/-sS/-sT/-sU, sslscan’s StartTLS protocol smtp/pop3/imap/ftp) validate against a fixed allowlist rather than passing user input directly to the CLI. Any value not in the allowlist is silently ignored.
• Pipeline panic recovery — the scan pipeline wraps each run in a defer recover() block. If a scanner panics (e.g., nil pointer in output parsing), the panic is caught, the session is marked as "failed" with the panic message, a EventFailed is emitted, and the pipeline cleans up — Ghost never crashes from a scanner bug.
• StopAll for graceful shutdown — the scanner manager exposes a StopAll() method that cancels all running scans. This is called during Ghost’s graceful shutdown sequence to ensure no orphaned scanner processes are left running.

Agent-Only Tools (3)

These are registered as agent tools but have no UI management — they must be pre-installed on the system:

Tool	Purpose
nmap	Network port scanning and service detection
sslscan	SSL/TLS configuration auditing (cipher suites, certificate details, protocol versions)
hydra	Credential brute force testing (requires request_approval even in Active Full mode)

Agent Tool Names

Agent Tool	Scanner	Scan Mode Restriction
run_nuclei	nuclei	Active Safe+
run_dalfox	dalfox	Active Safe+
run_ffuf	ffuf	Active Safe+
run_sqlmap	sqlmap	Active Safe+ (risk capped at 1)
run_trufflehog	trufflehog	Passive (with --no-verification) or Active
run_katana	katana	Active Safe+
run_semgrep	semgrep	Passive+
run_nmap	nmap	Active Safe+
run_ssl_scan	sslscan	Active Safe+
run_hydra	hydra	Active Full (requires approval)

XSS Callback Security

When dalfox runs blind XSS tests, it embeds a callback URL in payloads. If a stored XSS payload fires later (e.g., when an admin views a page containing the injected payload), the victim’s browser sends a request to Ghost’s callback endpoint (/api/v1/security/xss-callback). This endpoint is unauthenticated by design — the XSS payload fires in an arbitrary browser context that cannot include Ghost’s bearer token.

To prevent attackers from injecting fake findings into arbitrary sessions, callback URLs are HMAC-signed. The SignCallbackURL function generates an HMAC-SHA256 signature binding the session ID and plan ID to the Ghost bearer token. The callback endpoint verifies this signature before creating a finding — requests with an invalid ?sig= parameter are rejected with HTTP 403. Unsigned callbacks are currently allowed with a warning log for backward compatibility, but this will become mandatory.

The callback body (execution context like document.cookie, document.domain) is capped at 4 KB (maxCallbackBody).

AI Security Agent

In security mode, the agent operates as a senior penetration tester following PTES methodology. The agent progresses through phases autonomously using a plan-execute-reflect-terminate loop.

Engagement Phases

What this diagram shows: The agent moves through five phases, with each phase unlocking different tool categories. Phase transitions happen automatically based on how many tools the agent has used in the current phase:

Phase	Transitions After	What The Agent Does
Traffic Analysis	3+ reconnaissance tool calls	Examines captured traffic to understand the application — maps endpoints, identifies auth mechanisms, catalogs technologies
Passive Detection	4+ passive tool calls	Analyzes headers, cookies, response bodies for vulnerabilities without sending any traffic
Active Scanning	3+ active tool calls	Runs external scanners, sends test payloads, probes for vulnerabilities
Exploitation	4+ exploit tool calls	Generates proof-of-concept scripts, validates findings, tests exploit chains
Reporting	(Terminal)	Summarizes findings, generates report, writes PoC files

Security-Specific Agent Tools

The following tools are registered and available in security mode:

Tool	Purpose
list_findings	Query existing findings from the store (filter by severity, type, status)
send_http_request	Send arbitrary HTTP requests with SSRF protection and scan mode enforcement
get_page_resources	Map JavaScript, CSS, and image dependencies from HTML responses
attack_request	Automated payload testing (see Request Attacker)
list_wordlists	List available attack payload wordlists
request_approval	Gate for write operations — the agent asks for your permission before modifying data
6 Frida tools	See Frida Integration
10 external scanner tools	See the scanner table above

Note: The AI agent performs authentication analysis, JWT decoding, sensitive data detection, IDOR pattern recognition, security header auditing, and PoC generation directly using its language understanding capabilities — it reads the raw flow data and reasons about it, rather than using dedicated tools for these tasks.

Security UI

Findings Panel (Sidebar)

Replaces the Scope Panel when in security mode:

• Target hosts — add/remove glob patterns for what the passive interceptor should scan
• Severity stats bar — color-coded breakdown showing how many findings at each severity level (critical=red, high=orange, medium=yellow, low=blue, info=gray)
• Clickable severity filters — tap a severity segment to filter the flow list
• Three tabs: Traffic, Devices, Findings

Security Flow List

The flow list gains security-specific columns:

• Severity dot — color-coded left border indicating the highest finding severity for that flow
• Findings count — number of security findings associated with each flow
• Security-test badge — marks flows generated by active testing tools (scanners, attacker)
• Auth type badge — shows the detected authentication mechanism (JWT, cookie, API key)

Security Inspector

The flow inspector adds security context:

• Findings tab — per-flow findings with severity badges, evidence (shown in code blocks), and remediation guidance
• Request/Response — standard headers and body view
• Auth Analysis — JWT decoder with security checks

JWT Decoder

A standalone JWT analysis tool in the auth analysis tab:

• Decodes header, payload, and signature sections
• alg:none detection — flags tokens with no algorithm (can be forged without a key)
• HS256/RS256 confusion — flags algorithm switching attacks (where an attacker tricks the server into using the public key as an HMAC secret)
• Expiry check — warns on expired tokens or missing exp claim
• PII detection — warns if the JWT payload contains email addresses, phone numbers, or SSN patterns (these shouldn’t be in tokens)

Findings View

Full-screen findings list with:

• Severity pill filters — click to filter by critical / high / medium / low / info
• Status filter dropdown — filter by open / confirmed / false_positive / fixed
• Card-based display — each finding shows severity badge, type tag, description, evidence (in a code block), remediation guidance, CWE/OWASP references, a status dropdown to change the finding’s state, and a link to the source flow

AI Enhancement

Security findings from the passive interceptor are often terse — “Missing HSTS Header” with a generic description. Ghost’s AI enhancement rewrites findings into full exploitation reports with pentest-grade detail.

How It Works

Click “Enhance with AI” on any finding card. Ghost sends the finding’s title, type, severity, classification (CWE/OWASP), evidence, and current description/remediation to the configured LLM provider. The AI returns a structured JSON response with enhanced fields that are stored as metadata on the finding.

Enhanced Fields

Field	What the AI Produces
Title	Vulnerability class + specific target. Max 100 chars.
Description	4-8 sentences. What was observed, why it matters, inferred risk with hedging language.
Remediation	Specific fixes with config/code snippets. Defense-in-depth layers.
CVSS Vector	CVSS v3.1 vector scored on demonstrated impact only.
PoC	Full pentest procedure with tagged steps (see below).
Attack Chain	How this finding chains with other vulnerabilities for escalated impact. 2-4 chains.
Severity Recommendation	Whether severity should change, based on proven impact only.

Evidence-Based Rigor

The enhancement prompt enforces strict evidence-based standards across all fields — not just the PoC. This prevents the common LLM failure mode of presenting inferred risk as proven fact.

PoC Structure — the PoC field uses a mandatory 4-section format that structurally separates verified from hypothetical steps:

=== PREREQUISITES ===
Tools needed, setup instructions

=== VERIFIED STEPS (evidence-backed) ===
Step 1: curl command using actual URLs from evidence
Step 2: additional verification from observed data

=== HYPOTHETICAL STEPS (inferred — needs validation) ===
Step 3: exploitation scenario with explicit assumptions
Step 4: further exploitation

=== IMPACT ===
What the attacker gains if hypothetical steps succeed

Section	Rendering
=== VERIFIED STEPS ===	Green (emerald) left border per step
=== HYPOTHETICAL STEPS ===	Amber left border + “needs validation” per step
=== PREREQUISITES ===	Gray left border
=== IMPACT ===	Red left border

The frontend parser (parsePoCSteps()) also supports legacy inline tags ([VERIFIED], [HYPOTHETICAL]) for backward compatibility. Findings without any recognized format fall back to raw <pre> rendering.

Description — must separate observed facts from inferred risk. “The target returns 14 tokens with 10-day expiry (verified). If tokens are accepted by other services (not verified), lateral movement is possible.” Not: “grants access to seller management and financial operations.”

CVSS Vector — scored only on demonstrated impact. S:C (Scope Changed) requires proven cross-boundary impact. Default to S:U when scope change is unproven.

Severity Recommendation — can only recommend changes based on proven impact. Must explain what evidence would be needed to justify escalation.

UI States

Each finding card shows the enhancement lifecycle:

State	Button Text	Visual
Not enhanced	”Enhance with AI”	Standard card
Enhancing	”Enhancing with AI…”	Cyan shimmer animation + pulsing sparkle icon
Enhanced	”Re-enhance with AI"	"Enhanced with AI” sparkle label + original/enhanced toggle

The original/enhanced toggle switches between the original passive scanner output and the AI-enhanced version for title, description, and remediation. PoC, attack chain, and CVSS are only shown when viewing the enhanced version.

WebSocket Events

Event	When It Fires	What Happens in UI
finding.created	New finding detected (passive or active)	Finding appears in panel. Critical and high severity findings trigger toast notifications automatically.
finding.updated	Finding status changed (e.g., open → confirmed)	Status badge updates in the findings list
finding.deleted	Finding removed	Finding disappears from the panel

API Reference

Findings

Method	Endpoint	Description
GET	/api/v1/findings	List findings. Requires session_id. Supports filters: type, severity, status, flow_id, limit (max 500), offset.
GET	/api/v1/findings/stats	Get finding statistics by session — totals broken down by severity, type, and status.
GET	/api/v1/findings/{id}	Get a single finding with full details.
PATCH	/api/v1/findings/{id}/status	Update a finding’s status. Body: { "status": "confirmed" }. Validates against allowed statuses.
DELETE	/api/v1/findings/{id}	Delete a finding.

Note: There is no POST /findings endpoint — findings are created exclusively by the SecurityInterceptor callbacks and AI agent tools, never directly via the API.

Security Tools

Method	Endpoint	Description
GET	/api/v1/security/tools	List all external security tools with installation status, version, and enabled state. Includes Frida status.
POST	/api/v1/security/tools/install	Install a tool via package manager. SSE streaming output. 10-minute timeout.
PATCH	/api/v1/security/tools/{name}/toggle	Toggle a tool’s enabled/disabled state.

Use Cases

Passive security audit — Just capture traffic from your application normally. Ghost’s security interceptor automatically finds missing security headers, exposed API keys, dangerous CORS configurations, and sensitive data in response bodies — all without sending a single additional request.

Active penetration test — Switch to Active Safe mode and let the AI agent run nuclei, dalfox, and sqlmap against your application. The agent follows PTES methodology — starting with reconnaissance, moving to passive detection, then active scanning, and finally generating a report with findings and PoC scripts.

Mobile app security — Switch to Mobile sub-mode. Use Frida to bypass SSL pinning and root detection, then let the passive interceptor analyze the now-visible traffic. The mobile vulnerability taxonomy guides the agent to check for certificate pinning bypass, insecure local storage, sensitive data in logs, and other mobile-specific issues.

JWT security analysis — The JWT decoder instantly reveals weak algorithms (alg:none, HS256/RS256 confusion), missing expiry claims, and PII leaked in token payloads. No manual decoding needed.

Compliance checking — Run in passive mode to audit security headers across your entire application. The findings panel shows which hosts are missing HSTS, which cookies lack Secure flags, and which endpoints expose server version information — exactly the data a compliance auditor needs.