AI Application Security Audit

Most security audits produce a finding list nobody acts on. The list has 230 items. Most are noise: dependencies with theoretical vulnerabilities the team does not actually expose, configurations that are technically sub-optimal but operationally fine, recommendations that would be good practice but are not actually risks. Buried in the list are the few items that matter: the production secret in a config file, the IAM role with admin permissions, the auth flow that accepts unsigned tokens. The team is supposed to triage the list, identify the real items, and fix them. In practice, the list goes into a quarterly review meeting where most items are deferred and the team commits to coming back to it. The real items get lost because the noise made the signal invisible.

A useful security audit reverses the polarity: small list, high signal, every item with severity, remediation steps, and reasoning the team can defend. The audit covers the same surface (secrets, dependencies, IAM, auth, injection, headers, public storage) but ranks the findings so the team knows what to fix first. Items below a threshold are documented but not surfaced as actionable, so the actionable list stays short. The discipline is to audit for what matters, not for what is comprehensive. The /warden-audit skill produces the audit calibrated to the team's actual exposure rather than a generic checklist.

Why generalist AI produces noisy audit lists

Ask Cursor or ChatGPT for a security audit. You get a checklist of common vulnerabilities and asked to verify each one. The checklist is not wrong; it is the same checklist the team could find on OWASP. The work that turns a checklist into an audit is the verification: does the team's specific code expose this vulnerability, and if so where. A generalist tool cannot do the verification because it cannot read the deployed configuration, the IAM policies, the production environment variables, the dependency tree with its actual usage. The output is a checklist with no verification, which is what the team had before.

The other failure mode is the missing prioritization. A generalist's findings are flat: ten items, no severity. The team has to triage. Triaging a flat list is the work the audit was supposed to do. Without the severity ranking, the audit's value is the awareness, and awareness alone does not produce action. The prioritization requires reading the actual exposure (this dependency is used; this IAM role is attached to a production service; this header is missing from a customer-facing route) and grading each finding accordingly.

What a useful security audit covers

A complete audit covers seven surfaces. Secrets: scan code, environment variable defaults, and committed config for production credentials. Dependencies: identify packages with known CVEs and verify the vulnerable code path is actually reachable from the application. IAM: identify over-privileged roles, wildcards, missing explicit denies. Auth and authorization: verify auth middleware is applied correctly, authz checks happen on every protected route, session and token handling follows the right patterns. Injection: SQL, command, template; static analysis plus reachability check. XSS: review encoding at output points and CSP coverage. TLS, headers, CORS, and rate limiting at the edge. Public storage: verify nothing is publicly accessible that should not be. Each surface gets a verification step, not a checklist tick.

The output is a prioritized list with three to seven items per severity (Critical, High, Medium, Low). Items above Medium are actionable findings the team commits to address. Below Medium is documented but deferred. The Critical and High items have remediation steps with code-level pointers, not generic advice; the Medium items have brief notes and links to a longer analysis. The discipline of capping the actionable list is what makes the audit usable: a team can address ten items in a focused week, but cannot address 230.

How /warden-audit works

Step one: scan the seven surfaces

When invoked, /warden-audit runs targeted scans across the seven surfaces. Secret scan reads the codebase, env defaults, and committed configs. Dependency scan compares the lockfile against the current CVE database and verifies vulnerable code paths. IAM scan reads the cloud account's roles and policies (if credentials are configured). Auth scan reads the route handlers for authn/authz consistency. Injection scan uses static analysis with reachability. XSS scan reviews output points and CSP. Storage scan reads bucket and object permissions. The output is the raw finding set.

Step two: verify and prioritize

Each raw finding goes through verification: is the vulnerability actually reachable, is the over-privileged role actually attached, is the missing header actually on a customer-facing route. Findings that fail verification (theoretical issues that do not actually expose risk) are demoted to Low or excluded. Findings that pass verification get a severity based on impact and exploitability: Critical for items that could lead to full compromise, High for items that could lead to data exposure, Medium for items that compound into risk, Low for items that are best practice but not risks.

Step three: produce remediation steps

Critical and High items get specific remediation: the file and line to change, the code example for the fix, the test to add to verify it. Medium items get brief notes and a link to a longer analysis. Low items get a one-line description. Each item references the standard taxonomy (OWASP ID, CVE, CWE) so the team can map findings to industry frameworks for compliance reporting.

Step four: deliver the audit

The audit lands as a structured document: executive summary (one page; what was scanned, the count by severity, the top three risks), the actionable findings (by severity), and the appendix (Low-severity items, scope notes, methodology). The structure is calibrated to two audiences: engineering, who needs the actionable findings; and leadership/compliance, who needs the executive summary.

Tonone's /warden-audit skill produces a prioritized security audit covering secrets, dependencies, IAM, auth, injection, headers, and storage, with remediation steps for every actionable finding.

When to use /warden-audit, and when not to

/warden-audit is the right call before a production launch with external users, before an enterprise sales deal that requires a security questionnaire, when something suspicious has been found and a complete sweep is warranted, or annually as a standing health check. The skill is also the right call when a previous audit produced too much noise to act on and the team wants a usable version.

Skip the skill for design-time security analysis (use /warden-threat for STRIDE threat modeling). For implementing controls after the audit identifies gaps, /warden-harden produces the hardening spec. For IAM redesign specifically, /warden-iam is the right call.

A worked example: pre-launch audit summary

Suppose the brief is: pre-launch security audit before going to public users. Run /warden-audit.

# Security Audit: Acme Application (Pre-Launch)
Date: 2026-03-01. Scope: web, api, workers. Cloud: AWS production account.

## Executive summary
- 3 Critical, 5 High, 9 Medium, 22 Low.
- Top risks: production Stripe key in committed .env.production,
  IAM role with iam:* on the workers service, missing CSP on
  customer-facing /app routes.
- Recommendation: address all Critical and High items before launch.
  Medium items can ship to production with documented owners.

## Critical (act before launch)
1. Stripe live secret in .env.production (committed at sha 4a82f1).
   Remediation: rotate key, move to AWS Secrets Manager, scrub git
   history, add pre-commit secret scan.
   Files: .env.production:14, scripts/deploy.sh:22.
2. workers IAM role has Action: iam:* and Resource: '*'.
   Remediation: scope to specific actions on specific resources.
   See /warden-iam output for the replacement policy.
3. Auth middleware not applied to /admin/users/:id/billing route.
   Remediation: add @UseGuards(AuthGuard, AdminGuard) decorator.
   File: apps/admin/src/users/billing.controller.ts:18.

## High (act before launch)
4. CSP missing on /app/* customer-facing routes.
5. CORS allows Access-Control-Allow-Credentials: true with wildcard origin.
6. 12 npm packages with HIGH severity CVEs in production deps.
7. JWT signing key has 7-day rotation TODO; not implemented.
8. Public S3 bucket 'acme-uploads-public' contains user PII.

## Medium (ship with documented owners)
[9 items, abbreviated]

## Low (deferred, documented in /docs/security/audit-2026-03.md)
[22 items]

## Methodology
- Codebase scan: secret detection, dependency CVE, static analysis
  on injection sinks.
- Cloud scan: IAM policy review, S3 bucket policy review, security
  group review.
- Manual review: auth flow, session handling, CSP coverage.

Three pages of findings. The Critical items have specific files and lines. Engineering knows what to fix; leadership has the summary they need. The Low items live in the appendix so they are documented without competing for attention. That is what an audit looks like when the discipline is to produce signal rather than noise.

Related skills

/warden-audit produces the findings. For implementing the controls the audit identified as missing, /warden-harden is the right call. For IAM redesign specifically, /warden-iam covers least-privilege role design. For threat modeling at design time, /warden-threat is the entry point.

Install

/warden-audit ships with the Warden agent in the Tonone for Claude Code package. Install Tonone, configure read-only credentials for the cloud account if cloud surfaces are in scope, and the skill produces the prioritized audit calibrated to the actual exposure.

Audits the team acts on are the ones with severity ranking, verification, and remediation. The skill is built so the audit produces signal, not the comprehensive list nobody reads.