# Security audit agent
The Security Audit Agent is a starter reviewer for security-sensitive work. It is language-aware but not language-bound: it can inspect application code, infrastructure, dependencies, and delivery configuration, then return findings with severity, confidence, evidence, remediation, and verification steps.

Use it when you want a structured security review before or after implementation, especially when the risk spans more than one language or tool.

> [!NOTE]
> This is not a compliance guarantee. The agent can provide control-alignment observations and evidence-backed findings, but your team remains responsible for policy interpretation, approval, and risk acceptance.

## Agent shape

| Field | Value |
|-------|-------|
| Handle | `security-audit-agent` |
| Name | Security Audit Agent |
| Kind | `bot` |
| Default role | `reviewer` |
| Source pattern | `valdr-packs/valdr/vanguard/agents/security/` |

The security starter differs from the language task agents because it is a reviewer. Its capabilities are grouped by scanning and policy concerns:

```yaml
schemaVersion: 1.0
agent:
  handle: security-audit-agent
  name: Security Audit Agent
  kind: bot
  defaultRole: reviewer
  tags:
    - valdr
    - security
    - audit
    - vulnerability
    - compliance
    - reviewer
capabilities:
  - key: valdr.agents.security.security-audit-agent.system
    role: core
    category: system
  - key: valdr.agents.security.vulnerability-patterns
    role: constraints
    category: policy
    hot-load: true
  - key: valdr.agents.security.dependency-audit
    role: validation
    category: scanning
    hot-load: true
  - key: valdr.agents.security.secrets-detection
    role: validation
    category: scanning
    hot-load: true
  - key: valdr.agents.security.compliance
    role: constraints
    category: policy
    hot-load: true
```

## What it is good at

| Need | Why this agent fits |
|------|---------------------|
| Vulnerability review | It separates confirmed vulnerabilities from plausible indicators |
| Dependency risk | It can hot-load dependency audit guidance for CVE and supply-chain work |
| Secrets checks | It can inspect code/config/history patterns for exposed credentials |
| Control alignment | It can map findings to frameworks such as OWASP or CWE without claiming certification |

Its output contract is intentionally strict. Each finding should include a stable ID, title, severity, confidence, category, evidence, impact, remediation, and verification step.

## How to use it

Launch the agent with `/valdr-agent` and pass the starter handle first:

```text
/valdr-agent security-audit-agent review the OAuth callback changes.
Focus on authorization bypass, token exposure, redirect handling, and dependency risk.
Return findings with severity, confidence, evidence, remediation, and verification.
```

Good security launch prompts include:

- the changed surface area
- relevant trust boundaries
- sensitive data involved
- whether dependencies or infrastructure are in scope
- the audience for the output: developer, reviewer, or risk owner

## When not to use it

Do not use `security-audit-agent` as the implementation owner for ordinary feature work. If it finds a bug, route the fix to a task executor such as `java-task-agent`, `go-task-agent`, or a team-specific agent.

For general code review, use [Sigrid](../../included-agents/sigrid/). For auditing an agent session rather than the code or configuration, use [Tyr](../../included-agents/tyr/). For dependency upgrade planning, consider `dependency-audit-scout`.

## How to adapt it

Security agents become much more useful when they know your threat model and safe defaults. Keep the starter structure, then add capabilities for:

- authentication and authorization patterns
- data classification and logging rules
- secrets-management process
- dependency approval policy
- cloud/IaC guardrails
- incident severity taxonomy

Example:

```yaml
capabilities:
  - key: acme.security.audit-agent.system
    role: core
  - key: acme.security.authz-patterns
    role: constraints
    hot-load: true
  - key: acme.security.secrets-policy
    role: validation
    hot-load: true
  - key: acme.security.cloud-boundaries
    role: context
    hot-load: true
```

The goal is not to make an agent declare your system "secure." The goal is to make review evidence more consistent, concrete, and actionable.

## Next step

Use [Build your own](../build-your-own/) to turn the security starter into a reviewer that understands your product, data, and controls.