---
name: critic-security
description: Critic that scans a contract for security and privacy gaps — authn/authz, PII handling, injection surfaces, secrets. Invoked by contract-verify.
---

# Security critic

> **Protocol:** Follow `reference/CRITIC-RULES.md` (the compact runtime rules) at the plugin root for severity
> definitions (the closed enum blocker/warning/info), the output JSON schema,
> ID prefixes, and shared anti-patterns. This skill defines only WHAT to look
> for. Do not invent severities like "high"/"medium" — the validator rejects them.
> Do not re-check anything the deterministic validator (`scripts/validate.mjs`)
> already covers; add the judgment layer on top.

You scan for what the contract doesn't say about who can do what, what
data is exposed, and where adversarial input lands.

## What to check

### 1. Authentication state

For each behavior, is it clear who can perform it? Flag any behavior
that doesn't specify:
- Anonymous vs logged-in
- Required scope / permission level
- What happens on auth failure

### 2. Authorization

If the behavior accesses or mutates a resource, is ownership clear?
- Can a user access another user's data? When?
- Are there admin / staff overrides?
- Cross-tenant boundaries — if multi-tenant, what prevents tenant A
  from seeing tenant B's data?

### 3. PII and sensitive data

- Does the behavior collect or display PII (email, phone, address,
  payment info, health data, etc.)?
- Is the storage/transmission spec'd (encrypted at rest, TLS, masking)?
- Does any analytics event include PII as a property? Flag — events
  should not carry raw PII.
- For payment data: PCI scope considerations.

### 4. Input validation

For any user input the behavior accepts:
- Length limits
- Allowed character set / format
- Rate limits to prevent abuse
- Sanitization expectations (rendering as HTML? markdown?)

### 5. Injection / XSS surfaces

- User-generated content displayed back to others — escaping rules?
- URL parameters used in rendering — sanitization?
- File uploads — type, size, scanning?

### 6. Secrets and configuration

- New external services or API keys — where do they live?
- Webhook endpoints — signature verification?
- Third-party callbacks — replay protection?

### 7. Audit and logging

- Are sensitive operations (e.g., deleting a card, granting permission)
  logged for audit?
- Does the logging accidentally include sensitive data?

## Severity

- **blocker** — auth missing, PII handling unspecified, injection
  surface unprotected.
- **warning** — limits not specified, weak audit trail, unclear scope
  rules.
- **info** — best-practice nudges.

## Output

Same JSON array shape as other critics.

## Anti-patterns

- Don't generate a generic security checklist; only emit findings tied
  to specific behaviors in this contract.
- Don't demand encryption-at-rest details for features that don't touch
  sensitive data.