Security Review

Review security and privacy

Establish facts and boundaries

Read the scoped design or complete diff, relevant repository policy, deployed configuration, and tests. Identify protected assets, actors, data categories, trust boundaries, entry points, privileged operations, external flows, and plausible failure impact. Mark missing facts as unknown instead of filling them from a generic checklist.

If the target runs in Nav or NAIS, handles Nav data or identities, or uses Nav authentication, audit, or network controls, load the Nav security review reference. Apply it only where repository and current authoritative evidence show that it fits.

When the change adds or materially alters an entry point, trust boundary, identity model, sensitive-data flow, privileged operation, external integration, or deployed surface, load the threat-modeling reference and perform its DFD-first STRIDE review.

Review the applicable surfaces

• Minimize sensitive data and keep it out of ordinary logs, URLs, errors, telemetry, fixtures, and agent output.
• Trace values through validation and diagnostic wrappers before approving log or error output. A field named validatedValue, a validation report, or an interpolated exception can still contain the original sensitive input.
• Verify secret sourcing, storage, rotation, redaction, and failure behavior without printing secret values.
• Separate authentication from authorization; validate identity and token constraints, then enforce role, ownership, purpose, or resource access at the operation.
• Trace untrusted input to interpreters, queries, templates, files, redirects, deserializers, and outbound requests.
• Check trust-boundary and infrastructure changes for least privilege, explicit callers and destinations, environment separation, and safe defaults.
• Review external integrations for necessary data transfer, authenticated transport, failure containment, retention, ownership, and incident handling.
• Check dependencies, build and delivery changes, generated artifacts, and automation for supply-chain or privilege expansion.
• Confirm that security-relevant events are observable without exposing the protected data itself.

Produce evidence

Discover the repository's security tools and required gates. When the active agent is Doctor Who, or otherwise lacks explicit command-execution capability, use repository evidence, approved web/MCP sources, and supplied CI or test artifacts only. Never invoke or prescribe shell, gh, raw HTTP, or another network command. When a material claim lacks evidence, ask for the smallest pasted or exported artifact and return Status: NEEDS_INPUT, naming the claim that remains unverified.

In a separate developer or security-reviewer workflow, an agent whose own contract explicitly grants command execution may run only safe, authorized checks relevant to the change and report the command, result, and exit code. A non-product reviewer that expects fresh evidence but cannot execute may return MISSING_EVIDENCE and hand the evidence request to an explicitly authorized orchestrator. This paragraph does not grant Doctor Who shell access and must not be used to route commands through the user.

Never install tools, contact external systems, rotate credentials, or mutate deployed state merely to complete a review. Return findings ordered by potential impact and exploitability. For each, identify the evidence, affected asset or boundary, credible failure mode, and smallest effective mitigation. Separate verified findings, inference, and unresolved questions. Escalate a suspected active exposure or incident through the repository's incident process without exposing sensitive evidence in the report.