| name | pc-security-audit |
| description | Use when a reviewed change, release candidate, or high-risk slice must be challenged for abuse paths, trust-boundary failures, secret handling, dependency risk, or data exposure before release. |
| metadata | {"phase":"05-quality","inputs":["intake-brief","source-code","architecture-doc","threat-model"],"outputs":["security-report"],"prerequisites":["pc-code-review"],"quality_gate":"High and critical findings are resolved or explicitly accepted, abuse paths are reviewed, and release-blocking security risks are documented","roles":["reviewer","qa-engineer","devops-engineer"],"methodologies":["all"],"effort":"medium"} |
Security Audit
Challenge the change from an attacker and misuse perspective before it ships.
Context
Security audit is the focused quality pass for abuse resistance.
See context and anti-pattern notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 0: Calibrate the Security Target
Read quality_target_context before mapping attack surface. Confirm whether the reviewed target is an agent-internal skill, host runtime tool, local harness, internal service, or public HTTP service.
Do not downgrade baseline security because the target is internal. An agent-internal skill still needs review for prompt injection, command safety, remote instruction trust, tool/file/network side effects, secrets and PII in prompts, examples, logs, and artifacts, dependency execution risk, and public export supply-chain safety.
Escalate to full service-style audit when runtime_context=public_service, exposure_profile=public_internet, or evidence shows externally reachable behavior, multi-user access, sensitive data handling, auth/authz, privileged operations, new deployment exposure, or service-to-service trust boundaries. Only then should CORS, public auth, rate limiting, browser session handling, and internet abuse paths become release blockers.
If target context is missing or contradictory, stop and request the boundary or route a course-correction-note; do not invent public service blockers from HTTP-shaped implementation details alone.
Step 1: Map the Attack Surface
List the externally reachable paths, privileged operations, secret stores, data flows, and dependency changes involved in the slice. Focus on what changed, not the entire product.
Step 2: Inspect Trust Boundaries
Check authentication, authorization, tenancy isolation, input validation, output encoding, secret handling, and failure modes. Confirm the implementation matches the intended trust model instead of assuming the architecture doc was followed.
Step 3: Check Supply Chain and Configuration Risk
Review dependency additions or upgrades, deployment configuration, default exposure, logging of sensitive fields, and environment-specific behavior. Security failures often come from unsafe defaults rather than the core business logic.
Step 4: Write a Release-Useful Report
Classify findings by severity and exploitability. Separate:
- release blockers that must be fixed now
- medium-risk issues that need an owner and follow-up date
- accepted risks with explicit rationale
Every finding should point to the affected boundary, evidence, and expected remediation direction.
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
