# What Is the security-audit-static Command? Mapping Trust Boundaries in AI-Built Code

> Discover the security-audit-static command. Learn how this tool maps trust boundaries in AI-built code by identifying risks and verifying security intent against actual implementation. Secure your code today.

- Repository: [Pawel Huryn/pm-skills](https://github.com/phuryn/pm-skills)
- Tags: deep-dive
- Published: 2026-06-12

---

**The security-audit-static command is a static analysis tool that audits repositories for security risks by mapping entry points to trust boundaries and dangerous sinks, then verifying that documented security intent matches actual code implementation.**

The `security-audit-static` command is a built-in security tool in the phuryn/pm-skills repository designed to analyze AI-generated codebases. It performs exhaustive static analysis to identify vulnerable data flows before they reach production, ensuring that trust boundaries are properly enforced between user-controlled input and privileged operations.

## How the security-audit-static Command Works

### Command Invocation and Scope

Run the command with no arguments to audit the entire repository, or pass a specific path to narrow the scope to a particular directory.

```text
/security-audit-static

```

```text
/security-audit-static supabase/functions

```

According to the source code in [`pm-ai-shipping/commands/security-audit-static.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/security-audit-static.md), this invocation triggers a comprehensive analysis that reads every file in the chosen scope before applying pattern matching.

### Mapping Entry Points to Trust Boundaries

The audit implements a "recall-first" strategy that processes full files, then greps for handler, route, or shared-helper names to ensure no hidden path is overlooked.

**Entry points** are any public-facing interfaces where external data enters the system:

- HTTP/RPC handlers
- Edge/serverless functions
- Webhooks and queue consumers
- Upload handlers
- Authentication callbacks
- Cron-triggered endpoints

**Trust boundaries** are the logical validation points where user-controlled data crosses from an untrusted environment into the application's secure core. The audit traces every path from each entry point to every sink (see lines 28-33 in [`pm-ai-shipping/commands/security-audit-static.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/security-audit-static.md)).

### Identifying Security Sinks

**Sinks** are operations that can cause security violations when fed uncontrolled data. The command specifically checks for:

- Raw SQL queries
- Shell execution
- `eval` / `new Function` calls
- HTML/template rendering
- Outbound network calls
- Filesystem writes
- IAM/role modifications
- Logging of sensitive data
- Deserializers (YAML/XML, archives)
- Response headers
- **LLM prompts and tool calls** (to guard against prompt injection)

### Intent vs. Implementation Verification

The command cross-references code against documentation in `/documentation/*.md`. Any documented security rule not enforced in the actual implementation is flagged as a finding. This verification ensures that stated security policies match operational reality (see lines 38-41 in the source file).

### Self-Refutation and Evidence-Based Findings

For each candidate issue, the audit attempts to **disprove** it by searching for concrete mitigations. Valid counter-evidence includes:

- Input sanitizers and validators
- Hard-coded security values
- Configuration flags
- Explicit authorization checks

Only findings that survive this evidence-based challenge appear in the final report (see lines 42-46 in [`pm-ai-shipping/commands/security-audit-static.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/security-audit-static.md)).

## Understanding Trust Boundary Mapping

The core methodology traces every path from an entry point across the trust boundary to a sink. This reveals exactly where an attacker could influence privileged resources, such as database queries executed without row-level security, unauthenticated webhook processing, or LLM prompt injection.

The audit focuses on four critical security domains:

- **Authorization** – Verifying access controls are enforced
- **Data access** – Ensuring proper query filtering and tenant isolation
- **Session/identity handling** – Validating authentication state
- **Input→output encoding** – Preventing injection attacks

By comparing sibling handlers, the tool spots inconsistencies where one endpoint enforces a security check while another omits it (see lines 34-37 in the source file).

## Interpreting Audit Reports

Surviving findings are grouped by file, severity, and category in a structured markdown report. Each entry includes the risk level, attack scenario, impact assessment, and concrete remediation steps. The report concludes with root-cause themes, confirmation of well-built components, and open questions for developers (see lines 66-71 in [`pm-ai-shipping/commands/security-audit-static.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/security-audit-static.md)).

**Example finding:**

```markdown
Security Audit: supabase/functions

src/api/auth.js:
  1. [HIGH] Authorization Missing org filter
     Risk Level: High
     Attack Scenario: attacker → HTTP handler → DB query without org filter → all rows exposed
     Impact: Data leakage across tenants
     Solution: Add `where(org_id = $request.user.orgId)` to all queries

```

**Self-refutation example:**

```markdown
Refuted: The query includes a hard‑coded org filter, so no privilege escalation is possible.

```

## Summary

- The **security-audit-static** command in phuryn/pm-skills performs static analysis on AI-built code to identify security vulnerabilities before deployment.
- It maps **entry points** → **trust boundaries** → **sinks** using a recall-first approach that reads entire files before pattern matching to ensure comprehensive coverage.
- The audit cross-references implementation against `documentation/*.md` to verify that documented security intent matches code reality.
- Each finding undergoes **self-refutation** to eliminate false positives by seeking concrete mitigations such as validators or hard-coded filters.
- Reports are structured markdown documents grouped by severity, with specific attack scenarios, impact assessments, and remediation steps.

## Frequently Asked Questions

### What entry points does the security-audit-static command detect?

The command identifies HTTP/RPC handlers, edge/serverless functions, webhooks, queue consumers, upload handlers, authentication callbacks, and cron-triggered endpoints as entry points where external input first enters the system.

### How does the security-audit-static command prevent false positives?

For each potential vulnerability, the command attempts self-refutation by searching for concrete mitigations such as input sanitizers, validators, hard-coded security values, or configuration flags. Only risks that survive this evidence-based challenge appear in the final report.

### Can I run the security-audit-static command on specific directories only?

Yes. While running `/security-audit-static` with no arguments audits the entire repository, you can pass a subdirectory path such as `/security-audit-static supabase/functions` to limit the scope to specific code paths.

### Why does the security-audit-static command check LLM prompts and tool calls?

Modern AI-built applications often construct dynamic prompts or invoke tools with user-influenced data. The command treats these as security sinks to prevent prompt injection attacks where malicious input could manipulate AI behavior, override instructions, or leak sensitive context through tool parameters.