# Security Audit Prover MCP

> Security Audit Prover forces your AI client to check code against OWASP Top 10 standards before deployment. It systematically validates five critical vectors—Input Validation, Secrets Management, Access Control, Injection Prevention, and Dependency Auditing. Use it when you can't trust the code base and need a non-negotiable security gate.

## Overview
- **Category:** infrastructure
- **Price:** Free
- **Tags:** security-audit, owasp-top-10, secrets-detection, sql-injection, authentication, supply-chain-security, safe-coding, agentic-security

## Description

**`validate_security_audit`**: This tool forces your AI client to run a structured audit of your code base against OWASP Top 10 standards before you ever deploy it. You use this when you need a non-negotiable security gate that systematically validates five critical vectors: input handling, credential storage, access boundaries, injection prevention, and dependency integrity. 

When the agent runs `validate_security_audit`, it first tackles data coming into your system. It checks every single user-facing input—that means headers, query parameters, and request bodies—to confirm proper sanitization, type checking, and format validation across all sources. If any external input could be hostile or unsanitized, the process fails immediately.

Next, it hunts down exposed credentials. The tool scans your code files and even checks Git history to locate hardcoded API keys, tokens, or database passwords. You'll find that these secrets must be moved out of constants and into secure environment variables for proper handling.

It then verifies access boundaries by confirming that every single user-specific endpoint enforces two things: first, authentication—proving who the user is; second, authorization—making sure that person has the ownership or role required to view that data. The system flags common IDOR (Insecure Direct Object Reference) issues right out of the gate.

For database safety, it prevents injection attacks by forcing parameterized queries for all SQL, NoSQL, and command executions. You can't use raw concatenated strings; every query must utilize binding placeholders to guarantee separation between commands and data. This applies whether you’re dealing with a relational database or executing system commands.

Lastly, the process audits dependency integrity. It checks that your package versions are properly pinned in lockfiles and that any transitive dependencies—the packages *your* packages rely on—have been audited against known CVEs. This keeps your supply chain solid and catches risks like Log4Shell before they ever hit production.

## Tools

### validate_security_audit
Forces a structured audit of code against OWASP Top 10 standards, checking input validation, secrets storage, auth architecture, injection prevention, and dependency policy.

## Prompt Examples

**Prompt:** 
```
We need to read configurations from user input. Let's load the file using user-provided paths. We trust users because this is an internal application.
```

**Response:** 
```
Verdict: INPUT_TRUSTED. Indiscriminately loading files based on user-supplied paths without validation creates a path traversal vulnerability. An attacker can supply '../etc/passwd' or similar paths. Even internal systems must sanitize input. Validate that paths match expected subdirectories and restrict character patterns before accessing files.
```

**Prompt:** 
```
Input: check input format using regex ^[a-zA-Z0-9_.-]+$. Secrets: None. Auth: session verification cookies. Query: parameterized template query SELECT * FROM users WHERE username = $1. Dependencies: package.json pins express to exact version 4.19.2 and audits dependencies via npm audit.
```

**Response:** 
```
Verdict: SECURITY_PROVEN. User input validation mapped and sanitized. Secrets secured (none used). Access control enforced via cookies. SQL injection prevented through database query parameters. Dependency versions pinned and scanned. This code adheres to secure development guidelines. Build approved.
```

**Prompt:** 
```
Input: check input format via regex. Secrets: stored directly in config/keys.js for simple configuration. Auth: verification middleware. Query: parameterized. Dependencies: pinned versions.
```

**Response:** 
```
Verdict: SECRETS_EXPOSED. Saving credentials directly in keys.js is a critical security vulnerability. Move the secrets to environment variables, access them using process.env, and add keys.js to .gitignore. Git history preserves committed credentials even if you delete them later.
```

## Capabilities

### Validate all input sources
Checks every user-facing input (headers, query params, body) for proper sanitization, type checking, and format validation.

### Identify exposed credentials
Scans code and Git history to find hardcoded API keys, tokens, or database passwords that must be moved to environment variables.

### Verify access boundaries
Confirms that every user-specific endpoint enforces both authentication (login status) and authorization (ownership/role checks).

### Prevent database injection attacks
Forces the use of parameterized queries for all SQL, NoSQL, and command executions.

### Audit dependency integrity
Checks that package versions are pinned in lockfiles and that transitive dependencies have been audited against known CVEs.

## Use Cases

### The 'Oops, I committed a key' scenario
A developer accidentally commits an API key in a comment. Instead of waiting for GitHub’s slow scanner, the agent runs `validate_security_audit`. The tool immediately detects the secret pattern and forces the dev to rotate the key *before* merging.

### The 'IDOR' bug hunt
A new microservice endpoint is built for viewing user profiles. It passes authentication but fails authorization checks (User A can view User B's data). The agent runs `validate_security_audit`, which flags the lack of ownership check, requiring an explicit `if (req.user.id !== req.params.userId)` block.

### Building a complex data pipeline
The team needs to run queries across SQL and NoSQL databases using user-provided search terms. Running the audit forces them away from string concatenation, demanding the use of safe, parameterized query builders for both database types.

### Updating a third-party package
A developer upgrades an NPM dependency without checking its transitive dependencies. The agent runs `validate_security_audit`, which forces them to audit the entire dependency tree and verify that all new packages are properly pinned in the lockfile.

## Benefits

- Stops hardcoded secrets from reaching Git. The tool immediately flags credentials found in source code, forcing developers to move them to AWS Secrets Manager or Vault.
- Eliminates injection risks by checking for parameterized queries. It forces the use of `$1` bindings instead of raw string concatenation when building SQL or OS commands.
- Stops broken access control (IDOR). The audit mandates that every resource-accessing endpoint checks not just if a user is logged in, but if they own the specific resource ID.
- Prevents supply chain attacks. By requiring pinned versions and lockfile commits, it forces developers to account for transitive dependency risks.
- Ensures all input is treated as hostile. It mandates validation on every external source—from request body text to file MIME types—before processing.

## How It Works

The bottom line is: it gives you an objective, technical report on security flaws that human reviewers often miss.

1. You activate the Security Audit Prover tool, feeding it your current code component or module.
2. The agent runs five distinct checks: input sanitization, secret scanning, access control mapping, injection parameterization, and dependency vetting. It analyzes the implementation against known secure coding patterns.
3. It returns a structured verdict (e.g., `SECURITY_PROVEN` or `SECRETS_EXPOSED`), detailing exactly which of the five vectors failed and providing concrete remediation steps.

## Frequently Asked Questions

**How does Security Audit Prover analyze my code?**
It validates security decisions using a 5-pivot structured reasoning engine. You feed it your validation techniques, secret storage strategy, database parameterized query mappings, and auth setup. It rejects configurations that expose you to vulnerability.

**Does it replace automated scanners like SonarQube?**
No. Scanners run post-build to detect patterns. This tool forces pre-build cognitive reflection. It ensures the AI agent or developer maps out and implements a security strategy before writing code, preventing vulnerable patterns from ever being written.

**What security standards are enforced?**
It uses the OWASP Top 10 (2025) vulnerability list, CWE/SANS Top 25 most dangerous software weaknesses, and NIST AI RMF safety guidelines for agentic code execution.

**How does using `Security Audit Prover` enforce authorization beyond basic authentication?**
It mandates explicit ownership checks for every resource endpoint. The tool specifically detects IDOR (Insecure Direct Object Reference) vulnerabilities by verifying that the authenticated user owns or has permission to access the requested resource ID. It forces you to implement role-based and attribute-based access control logic.

**If I accidentally commit a secret, can `Security Audit Prover` help me clean up my Git history?**
The tool alerts developers that removing secrets from the latest commit is insufficient. It emphasizes that committed credentials remain in Git history forever, forcing you to rotate the key immediately and implement pre-commit hooks (like gitleaks) for prevention.

**What types of input validation does `validate_security_audit` enforce besides basic regex checks?**
It requires comprehensive sanitization beyond simple pattern matching. You must prove type and length checking, MIME whitelisting for file uploads, and validate that user input is sanitized using libraries like DOMPurify before storage or rendering.

**Does `Security Audit Prover` cover transitive dependencies or just pinned versions in package.json?**
It mandates auditing the entire dependency graph, not just direct pins. You must commit lockfiles and run automated scans (like npm audit) to check for vulnerabilities introduced by *transitive* packages, ensuring provenance verification across all layers.

**How does `Security Audit Prover` handle injection prevention when using multiple query types?**
It requires that you use parameterized queries exclusively for every type: SQL, NoSQL, LDAP, and even template engines. It flags any instance where user input is concatenated directly into a query string or command array.