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.
Scanned 9/22/2026
Install to Claude Code
npx -y skills add awarexone/AXguard --skill axguard-security --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Axguard Security?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/awarexone-axguard-security)More formats (shields.io, HTML) on the badges page.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!