Analyze code for security vulnerabilities, investigate findings, verify fixes, and assess security risk before deployment. Use when reviewing security-sensitive changes, before ship/deploy, or when an agent should call AXGuard MCP instead of inventing its own scanner.
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Is that skill safe to install?
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
Are you the author of Axguard Security?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/awarexone-axguard-security)
---
name: axguard-security
description: Analyze code for security vulnerabilities, investigate findings, verify fixes, and assess security risk before deployment. Use when reviewing security-sensitive changes, before ship/deploy, or when an agent should call AXGuard MCP instead of inventing its own scanner.
---
# AXguard Security (Agent Skill)
This skill does **not** implement security analysis. It teaches when to use AXGuard, which MCP tool to call, and how to interpret results.
**Primary interface:** AXGuard MCP tools (prefer over ad-hoc scans).
**Fallback:** if MCP is unavailable, `axguard scan .` / `axguard audit .` — then still apply the same verdict rules below.
Tool names: `references/mcp-tools.md` · catalog: [docs/mcp-tools.md](../docs/mcp-tools.md).
## When to call AXGuard
**Call** after security-sensitive edits, or before ship/deploy, when changes touch:
authn / authz / tenant / identity / permissions · DB · external HTTP · file / cmd · uploads · webhooks · secrets · OAuth · GraphQL · cloud · crypto · deps · AI agents / LLM tools / MCP · privileged ops
**Do not call** for trivial non-security edits (typos, comments, pure renames with no security surface).
## Workflow
```text
Code change
→ security-sensitive?
NO → skip AXGuard
YES → axguard_security_review
→ findings?
NO → done (respect UNKNOWN / predictive separately)
YES → axguard_investigate (suspicious)
→ fix
→ axguard_verify_fix
```
| Step | Tool | Notes |
|------|------|--------|
| Default entry | `axguard_security_review` | Prefer this over chaining engines manually |
| Dig deeper | `axguard_investigate` | Suspicious / incomplete candidates |
| After a fix | `axguard_verify_fix` | Do not mark resolved on edit alone |
| Evidence (optional) | `axguard_get_evidence` / `axguard_get_counter_evidence` | When debating a finding |
## Interpret results
| Label | Agent rule |
|-------|------------|
| **VERIFIED** | Do not dismiss without **new** counter-evidence. Treat as real until AXGuard says otherwise. |
| **UNKNOWN** | Do **not** call the change safe. State uncertainty; investigate or escalate. |
| **FALSE_POSITIVE** | Do **not** report as a vulnerability. |
| **PREDICTIVE_RISK** | Risk signal only — **not** a confirmed vulnerability. Do not merge into verified counts. |
Never invent evidence. Prefer AXGuard’s structured output over model speculation.
## Response discipline
- Prefer MCP when available; do not build a second scanner.
- Keep predictive risks and verified findings separate in summaries.
- Ship/go-no-go: blockers = VERIFIED (and policy-gated LIKELY if the review returns them) — not predictive-only noise.
- After fixes, call `axguard_verify_fix` (or re-review) before declaring closed.