# Agents and skills for code security and auditing

> Audit code, find vulnerabilities and stop secrets before the commit.

- Source: https://doutorai.pt/en/for/security-audit
- Site: Doutor AI (https://doutorai.pt/en) - AI tools for small businesses

Application security rarely fails for lack of knowledge, it fails for lack of time. An API key left in a configuration file, an endpoint that trusts the identifier sent by the client, a transitive dependency with a CVE that has been open for months. None of this shows up in the tests and none of it breaks the build. It usually comes to light when someone outside notices before the team does.

The components on this page put that check inside your normal workflow. There are agents that review a diff looking for authentication flaws, injection and data exposure, commands that scan the whole repository for secrets or vulnerable dependencies, and an automation that runs static analysis tools every time a file is saved. The result is a list of concrete issues, with file, line and a suggested fix.

Start with what hurts most in your project. If you have never done an audit, a generalist agent gives you the initial picture. If you already have code review in place, add secret detection and dependency auditing first, since those are the cheapest flaws to fix. The threat modeling and compliance skills are for planned work: use them when you design a sensitive feature or prepare for an external audit.

21 hand-picked components, from 4 different angles.

## General audit and code review

The first picture of a project's security posture and the recurring review of each change. This is where you start when there is no defined process yet.

- **security-auditor** (Agents): A starting point when there is no security process yet: it goes through controls, configurations and code, and returns prioritized gaps with evidence instead of a generic list. [page](https://doutorai.pt/en/components/agents__security-auditor)
- **se-security-reviewer** (Agents): A review focused on a diff or a module, with the plan adjusted to the type of code: the OWASP Top 10 for web APIs, the OWASP LLM Top 10 when there is an integration with language models. [page](https://doutorai.pt/en/components/agents__se-security-reviewer)
- **read-only-auditor** (Agents): The hooks declared in its frontmatter block Write, Edit and Bash for the whole audit, which makes it suitable for pre-merge or compliance reviews where nothing may be changed. [page](https://doutorai.pt/en/components/agents__read-only-auditor)
- **security-review** (Skills): A checklist that kicks in while you write the feature, not afterwards: authentication, user input, new endpoints, payments and anything that touches secrets. [page](https://doutorai.pt/en/components/skills__security-review)
- **vulnerability-scanner** (Skills): For anyone who needs to map the attack surface and decide what to fix first, with up-to-date OWASP principles and a validation script that runs against the project. [page](https://doutorai.pt/en/components/skills__vulnerability-scanner)

## APIs, databases and integrations

Each layer has its own flaws. These components know the attack patterns specific to each one, instead of applying the same checklist to everything.

- **api-security-audit** (Agents): Specialized in REST APIs: poorly validated JWT tokens, privilege escalation in access control and injection into SQL, NoSQL or system commands. [page](https://doutorai.pt/en/components/agents__api-security-audit)
- **api-security-best-practices** (Skills): Useful at the design stage, before there is code to audit: authentication, authorization, input validation and rate limiting patterns for REST, GraphQL and WebSocket. [page](https://doutorai.pt/en/components/skills__api-security-best-practices)
- **graphql-security-specialist** (Agents): GraphQL raises problems that do not exist in REST, such as unbounded nested queries. It handles query validation and authorization at the resolver level. [page](https://doutorai.pt/en/components/agents__graphql-security-specialist)
- **supabase-security-audit** (Commands): When the project is built on Supabase, the real risk lies in the Row Level Security policies and the keys exposed to the client. That is exactly what this command reviews. [page](https://doutorai.pt/en/components/commands__supabase-security-audit)
- **mcp-security-auditor** (Agents): For anyone who publishes MCP servers: it reviews the OAuth implementation, the role-based permission design and the places where the server exposes more than it should. [page](https://doutorai.pt/en/components/agents__mcp-security-auditor)

## Secrets, dependencies and the supply chain

Many flaws are not in the logic you wrote, they are in what you brought in from outside or what was left forgotten in the repository. They are also the quickest to fix.

- **security-scanner** (Automations): An automation that runs after every Edit or Write. If you have semgrep, bandit or gitleaks installed, the warning appears the moment the file is saved. [page](https://doutorai.pt/en/components/hooks__security-scanner)
- **secrets-scanner** (Commands): A one-off scan of the repository for API keys, passwords and certificates, including old commits whose message suggests they touched credentials. [page](https://doutorai.pt/en/components/commands__secrets-scanner)
- **dependency-audit** (Commands): Calls the ecosystem's native auditor (npm, pip, cargo) and checks known vulnerabilities, outdated packages and licensing issues in a single pass. [page](https://doutorai.pt/en/components/commands__dependency-audit)
- **supply-chain-security** (Agents): Goes beyond the CVE list: it detects typosquatting, dependency confusion and protestware, and generates an SBOM in SPDX or CycloneDX for anyone who has to deliver that document. [page](https://doutorai.pt/en/components/agents__supply-chain-security)
- **supply-chain-guard** (Skills): Starts from indicators of real attacks on npm, PyPI, crates.io and GitHub Actions, which helps when there is a concrete suspicion about a compromised package. [page](https://doutorai.pt/en/components/skills__supply-chain-guard)
- **secrets-management** (Skills): Finding secrets is half the job, storing them is the other half: it covers Vault, AWS Secrets Manager, automatic rotation and least privilege in CI/CD pipelines. [page](https://doutorai.pt/en/components/skills__secrets-management)

## Threats, hardening and compliance

Planned work instead of reactive work: understanding what can go wrong before you write the code and being able to prove afterwards that the controls exist.

- **security-threat-model** (Skills): Produces a threat model grounded in the real repository, with trust boundaries, assets, attacker capabilities and abuse paths, instead of a generic document. [page](https://doutorai.pt/en/components/skills__security-threat-model)
- **threat-modeling-expert** (Skills): The methodology behind the exercise: STRIDE, PASTA and attack trees, useful when the review is architectural and there is no code to analyze yet. [page](https://doutorai.pt/en/components/skills__threat-modeling-expert)
- **security-hardening** (Commands): Once you know what is missing, it applies concrete controls: HTTP headers, authentication configuration, encryption and infrastructure-level settings. [page](https://doutorai.pt/en/components/commands__security-hardening)
- **gdpr-dsgvo-expert** (Skills): A good fit for products with users in the European Union, with data protection impact assessments and GDPR compliance checks. [page](https://doutorai.pt/en/components/skills__gdpr-dsgvo-expert)
- **compliance-specialist** (Agents): When a client asks for evidence of SOC 2, PCI DSS or ISO, it helps you prepare for the audit: evidence gathering, security policies and risk assessment. [page](https://doutorai.pt/en/components/agents__compliance-specialist)

## Where to put each component in the project

The agents on this page are Markdown files that live in .claude/agents/ inside the repository, or in ~/.claude/agents/ if you want them in every project. Skills go in .claude/skills/, each in its own folder, and Claude Code loads them when the request matches their description. Commands go in .claude/commands/ and become available as shortcuts named after the file. The static analysis automation is different: it is a configuration block that you add to settings.json, in the PostToolUse hooks section. Keep everything under version control, so the whole team has the same controls and any change to the rules is recorded.

## Combining the three rhythms of review

These components work best in layers, each with its own cadence. The static analysis automation runs on every file save and catches the obvious mistake while it is still fresh. The secret scanning and dependency audit commands run once a week or before each release, because they analyze the whole repository and take longer. The review agents come in before merging a change that touches authentication, payments, uploads or database queries. Threat modeling sits outside this cycle: you do it at the start of a sensitive feature and revisit it when the architecture changes.

## What these tools do not solve

It is worth being clear about the limits. Several of these components depend on external tools installed on the machine, such as semgrep, bandit, gitleaks or the package manager's auditor. Without them, the analysis comes down to what the model can read in the code. A model-assisted review also produces false positives and can miss a business logic flaw that only makes sense to someone who knows the product. None of this replaces an authorized penetration test or an independent audit when there is a contractual or regulatory obligation. Treat the results as a list of leads to confirm, not as a certificate.

## Keep reading

- [Secure Code Reviewer](https://doutorai.pt/en/how-to/subagents--secure-reviewer)

## Frequently asked questions

### Do I need to install external tools for this to work?

It depends on the component. The agents and skills work by reading the code and need no extra installation. The static analysis automation, on the other hand, calls semgrep, bandit and gitleaks, and the dependency audit calls npm audit, pip or cargo audit. If those tools are not on the machine, the commands carry on without an error, but the coverage is much smaller.

### If I can only adopt one component, which one should I choose?

For most projects, secret scanning. An API key left in a commit is the most frequent flaw, the easiest to exploit and the quickest to fix. Right after that comes dependency auditing, because it exposes inherited risk without requiring changes to your code. A full code review makes more sense once those two are sorted.

### Does this replace a penetration test or an external audit?

No. These components do defensive analysis of code and configuration you already have access to, which catches a large share of the problems but does not confirm whether a flaw is really exploitable in production. If you have contractual, certification or regulated-industry obligations, you still need an authorized test carried out by a third party.

### Can I run an audit with no risk of changing the client's code?

Yes. The read-only audit agent blocks the Write, Edit and Bash tools through hooks declared in its own frontmatter, which means the restriction is enforced by Claude Code and does not depend on the model remembering it. It is the right option for pre-merge reviews and for work on third-party repositories.

### Do any of these components help with the GDPR?

The GDPR and DSGVO skill covers data protection impact assessments and compliance checks, and the compliance agent helps prepare audits under frameworks such as SOC 2, PCI DSS and ISO. They support documentation and gap identification. The final legal decision still belongs to the data protection officer.

---
Content by Doutor AI (https://doutorai.pt/en). When quoting, please cite the source: https://doutorai.pt/en/for/security-audit