Hire an AI application security reviewer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A threat model with assets, trust boundaries and a table of threats by STRIDE
• Code findings split into fix before merge and improve when you can, each with evidence and a fix
• A numbered list of security requirements you can test
• Tests to add so each fixed bug stays fixed
• Advice on scanning tools and a list of what was not checked

How it does the job well

• Never approve code or call it safe. You can say what you found and what you could not check.
• Every finding needs evidence: the file and line (or "line not given") and the path that shows the flaw. If you cannot show it, put it under Gaps and checks as a question, not a finding.
• Split findings: "fix before merge" means an exploitable flaw. "Improve when you can" means hardening.
• Give the fix in the user's language and framework. Prefer well-known libraries to hand-written security code. Never suggest custom cryptography.
• Rank risk by how easily it can be used and what it would cost this app, not by a score alone.
• Name the asset, the threat and the impact before recommending controls.
• Rank findings by real risk (likelihood and impact), with evidence for each.

Mistakes it avoids

• Findings with no evidence.
• Long lists of low-risk notes that hide the bugs that matter. Put at most five improve-later items.
• Copying the profile's sample tables or code as if they were this project's facts.
• Long lists of generic issues with no evidence they apply.
• Testing or scanning systems without permission.
• Presenting a legal opinion as final.

What a good result looks like

An example, not your task: You are about to build a feature that handles sign-in, payments, uploads or personal data and want the risks listed first.

• Scope. The feature, data, stack and rules the review was built on.
• Assets and trust boundaries. What is worth protecting, where it lives and where trust changes.
• Threat table. Threats grouped by the six STRIDE questions, each with where, risk and fix.
• Code findings. Each flaw marked fix before merge or improve later, with evidence and a fix in your framework.
• Security requirements. Numbered requirements that can be tested in review or in automated tests.
• Tests to add. Regression tests that stop each fixed bug from coming back.

How the work is checked

• Each finding has a location, evidence, severity and a specific fix.
• Likely false positives are checked and removed.
• Items that need a lawyer or auditor are clearly marked.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Fix the scope. It confirms the feature, data, stack and rules, and says what it will not see, such as your live system.
• Map assets and trust boundaries. It lists what is worth protecting and where data crosses from untrusted to trusted.
• Run the STRIDE questions. It checks spoofing, tampering, denial of having acted, data exposure, service blocking and extra rights, one by one.
• Review the code. It reads sign-in, access checks, input handling, cryptography and file handling, and traces untrusted input to where it is used.
• Turn risks into requirements. It writes exact, testable requirements, such as "check the owner on every request", not "use good security".
• Rank and hand back. It marks findings fix before merge or improve later, adds regression tests, and lists what was not checked.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id security-appsec-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/security-appsec-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• A short description of the feature or system, what it does and what data it handles.
• The code to review, pasted or uploaded, such as sign-in code, API routes or file upload handling (optional)
• Your language, framework and where it runs, such as Python with Django on AWS.
• How sensitive the data is, and any rules you follow, such as PCI-DSS, HIPAA or SOC 2 (optional)
• Your scanner results or past findings (optional)

Helpful context (optional)

• A simple diagram or list of how data moves between your app, services and database.
• Your dependency list, such as package.json or requirements.txt, so it can flag risky libraries to check.
• The last scan report or penetration test summary.

Tools and access

• Claude Code, Cursor or another AI tool that can open your project folder: It can follow untrusted input across files, which finds more than reading one pasted snippet.

Functions and deliverables

• Application security reviewer: Get a threat model and secure code review for your feature, with bugs to fix before merge, hardening tips and security requirements you can test.
  • A threat model with assets, trust boundaries and a table of threats by STRIDE
  • Code findings split into fix before merge and improve when you can, each with evidence and a fix
  • A numbered list of security requirements you can test
  • Tests to add so each fixed bug stays fixed
  • Advice on scanning tools and a list of what was not checked
  Source: Michael Sitarzewski and Agency Agents contributors.
• Microsoft threat model file builder: Describe components, users, data paths and trust boundaries. Get a Microsoft Threat Modeling Tool file draft with mapped threats.
  • A .tm7 file built for the Microsoft Threat Modeling Tool v7.3 or newer, from a bundled example structure (not tested by us in every version)
  • A diagram with shapes laid out so they do not overlap
  • STRIDE threats attached to each data flow
  • A check of the file against known mistakes that corrupt .tm7 files
  Source: GitHub Copilot community.
• STRIDE system threat analyst: Run a STRIDE threat model on your code repository. Get diagrams, ranked findings and a report that shows new, fixed and open threats.
  • 0-assessment.md: a short summary of the main risks and what to fix first
  • 0.1-architecture.md: the system parts and how they connect
  • 1-threatmodel.md: the data flow diagram with trust boundaries
  • 2-stride-analysis.md: threats for each part, sorted by STRIDE type
  • 3-findings.md: ranked findings with severity, CWE and OWASP mappings and fixes
  • threat-inventory.json, and on update runs a comparison of new, fixed and open threats
  Source: GitHub Copilot community.
• App security threat planner: Describe your app, users and sensitive data. Get a first threat list, entry points, practical safeguards and assumptions to check.
  • A list of parts and entry points
  • The top threats, ranked, with likelihood and damage
  • One practical fix for each
  • What was assumed and what to confirm
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• You are about to build a feature that handles sign-in, payments, uploads or personal data and want the risks listed first.
• A teammate opened a pull request touching access checks or user input and you want a security review of it.
• A customer sent a security questionnaire and you need a threat model and a list of security requirements.
• Your scanner reports many issues and you want to know which ones matter and what to fix first.

Limits to check before starting

• Your code was mostly written by an AI tool and you worry about leaked keys or open database rules. Use the AI-written code security reviewer.
• You want only a threat model with no code review. Use the Threat modeler.
• You want someone to attack your running app. Use the Penetration test planner, and only on systems you own.
• You want a security design for a whole company or cloud setup. Use the Security Architect agent.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill. If you cannot, paste SKILL.md into a new chat, then paste references/source-agent.md.
• Describe the feature and your stack. Paste the code that handles sign-in, access checks, user input or data. Remove real keys and personal data first. For a whole project, use an AI tool that can open your project folder.
• Type "Threat model this first, then review the code. Mark each finding fix before merge or improve later. Show the evidence and the fix. Tell me what you could not check."
• Read the fix-before-merge findings first. Ask it to explain any you do not follow, and to show the fix in your framework.
• Turn the requirements into tickets and the tests into real tests. The AI does not run any code.
• After you fix, paste the changed code back and ask it to confirm each fix really closes the bug.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/security-appsec-engineer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.