Methodology
How AuditAI uses Anthropic Claude in your audit, and the controls in place around it. Every claim on this page maps to code in the repository.
Models
We use the Anthropic Claude family. Routing is task-specific so the cheapest model competent for the task is the one that runs.
- Workflow classification
- Per-tool tier + framework tagging
Fastest, sufficient for structured-output tasks with strong JSON discipline.
- Five-element finding generation
- MITRE ATLAS threat models
- Peer-benchmark commentary
- Remediation-plan drafting
Balance of reasoning quality and cost for the bulk of AI-drafted content.
- Executive-summary narrative on the final report
Reserved for the prose that matters most: the executive narrative. One call per engagement.
Hallucination guardrails
Structured framework IDs an AI feature emits are cross-checked against the canonical catalog before the response reaches the auditor.
NIST AI RMF subcategories, ISO/IEC 42001 Annex A clauses, OWASP Top 10 for LLM IDs, EU AI Act articles, and MITRE ATLAS techniques and tactics are validated. Invalid IDs are stripped silently and recorded on the API response so the rejection rate surfaces in the AI quality dashboard. Free-form descriptive citations (for example, sector-specific guidance or general gen-AI references) have no canonical ID space to check against and pass through unchanged. Validation runs at the persistence boundary: today that means the classify-workflow, threat-model, and findings-intelligence routes.
lib/ai-validators.ts. The 5 framework catalogs are first-class data in lib/frameworks/; components never hardcode framework IDs. Adding a new framework means adding a typed constant + extending the validator - no inline strings.Prompt-injection defense
User-provided content is structurally separated from the system prompt before reaching the model.
All user-provided content (inventory item descriptions, survey responses, evidence notes) is wrapped in <user_input> XML tags before being passed to the model. System prompts are static and version-controlled. We don't echo user input back into the system role.
Eval suite
Every AI route is scored nightly. Workflow classification has the deepest ground-truth case set; the other routes use structural shape-validation evals that confirm the model returns a schema-valid response.
The Inngest ai-evals-nightly cron iterates 13 runners (one per AI route the platform ships). Workflow classification has 5 ground-truth cases spanning MINIMAL through HIGH_RISK EU AI Act tiers - Marketing/ChatGPT, internal HR-RAG, support chatbot, coding assistant, automated loan-approval loop - scored against a weighted-blend rubric. The other 12 routes run structural shape evals - the model output must pass the route's Zod schema, with binary pass/fail per case. Each runner is its own memoized step so a transient failure of one prompt's eval doesn't abort the others.
Full route inventory (derived from lib/ai-evals/inventory.ts)
| Route | Eval category | Purpose |
|---|---|---|
| Workflow classification | Ground-truth scored | Classifies an AI tool description into the platform's risk taxonomy (decision-making / generative / monitoring / etc.) so the auditor sees the right framework slice first. |
| Finding drafting | Schema-validation | Drafts the 5-element (Condition / Criteria / Cause / Effect / Recommendation) finding from auditor inputs. |
| Executive summary | Schema-validation | Composes the engagement-level executive summary for client-facing reports. |
| Threat modelling | Schema-validation | Generates a threat model for an AI workflow using STRIDE-aligned categories. |
| Remediation recommendation | Schema-validation | Suggests remediation steps + effort/cost estimates for a finding. |
| Engagement scope draft | Schema-validation | Drafts an engagement scope statement from a brief client description. |
| Survey-to-finding drafting | Schema-validation | Promotes a departmental survey response into a finding draft. |
| Interview transcript summary | Schema-validation | Summarises an interview transcript into key items + risks + quotes. |
| Interview item promotion | Schema-validation | Promotes an interview item into a finding draft when the auditor flags it. |
| Control test suggestion | Schema-validation | Suggests a test procedure for a control assessment. |
| Remediation task breakdown | Schema-validation | Breaks a finding's remediation into discrete RemediationTask rows. |
| Findings theme clustering | Schema-validation | Clusters findings across an engagement into themes (shadow-IT / vendor-risk / fairness / etc.). |
| Citation map | Schema-validation | Maps a finding to its supporting framework citations across NIST / ISO / OWASP / EU AI Act / SR 11-7. |
Pass-rate trend, per-case detail, and top edited fields (from the human-feedback fingerprint table) are visible on the operator dashboard at /usage/ai-quality and the public scorecard at /trust/evals.
Human review
Every AI output is a draft for the auditor to accept, edit, or reject. The auditor is always the final say.
Findings drafted by AI are flagged draftedByAi=true in the database; edits write a FindingEdit row capturing the field-level diff (Jaccard similarity bucket for long-form text, literal before→after for enums). That feedback loop is what we use to refine the prompts.
Cost transparency
Every Anthropic call is logged with token counts, USD cost, latency, and the engagement it was made for.
Every call writes an AiCallLog row. Per-engagement cost is visible to the auditor on the engagement overview; firm-wide spend by model and route is on /usage. Per-tenant monthly AI budgets are enforced server-side so a runaway loop can't spike your bill.
Provenance
Every generated report embeds a verifiable footer your client can independently check.
Every DOCX and PDF embeds a provenance footer: AuditAI version, the set of Claude models that contributed, the eval pass-rate at time of generation, and a SHA-256 of the report's logical content. A receiving client can confirm the file they have matches what was generated and look up the eval pass-rate for the date in question.
For federal + regulated submissions, every engagement can also export an OSCAL v1.1.2 System Security Plan via GET /api/engagements/{id}/oscal/ssp - machine-readable evidence of which controls AuditAI tested against, suitable for FedRAMP-adjacent procurement diligence and direct consumption by GovTech tooling.
Auditability
The audit log is enforced by the database, not the application. Tampering raises a Postgres-level error.
Every mutation in the audited domain (Finding, ControlAssessment, Report, InventoryItem, Engagement) writes to AuditLog. Postgres BEFORE-UPDATE/DELETE/TRUNCATE triggers raise insufficient_privilege if anyone tries to alter the log post-hoc. Rows are SHA-256 hash-chained (each row carries the previous row's hash); a weekly Inngest cron (audit-log-chain-verify) walks the chain to detect deletions or rewrites. Tenant deletion uses a narrow Postgres GUC escape hatch to PII-scrub specific columns rather than to delete rows wholesale - the chain stays intact.
Want the live numbers?
The eval scorecard, hallucination rejection rate, and incident history are all on the trust hub, updated automatically.