TL;DR
L1: I can use Claude.
L2: Claude understands my project.
L3: Claude executes my workflow.
L4: Connect Claude to can access my ecosystem
L5: Claude Code run autonomously
Here's the thing: Many security engineers never move past Level 1. You write a prompt for one task, get an answer, and that's it
This means constantly re-explaining the repo layout, your auth model, the parts of the codebase that have had problems before. You get faster at one-off jobs.
The levels below fix that by building on each other, one step at a time.
Level 1: AI-assisted security prompts
Core idea: Prompt-level usage. Claude keeps no memory between sessions
Ad-hoc prompts drive vulnerability review, incident triage, and log analysis
Each prompt is self-contained. Repo layout and known issue areas get explained from scratch, every time
Fast for a single job: a prompt can summarize a log dump or explain a suspicious diff in seconds
Breaks the moment the job changes. Move from log triage to code review, and the context is gone again
Two Prompt Framework you can leverage at this level:
Framework | What it structures | Why use it |
|---|---|---|
CORE (Context, Objective, Result, Example) | A single prompt into 4 labeled parts | Adds one concrete example so Claude isn't guessing at intent |
R.I.S.E. (Role, Input, Steps, Expectation) | A prompt into role, data, process, and output | Keeps a multi-step job, like triage, from drifting mid-answer |
Reader challenge: Can you start a new security project without re-explaining the repository, coding standards, and security context to Claude?
If the honest answer is no,
Move to Level 2: stop re-explaining the same context. Write it down once, in a file Claude reads automatically.
Level 2: Context-Aware Security Reviews
Core idea: CLAUDE.md gives Claude persistent, and reusable project context
A global
CLAUDE.md(in~/.claude/) holds rules that apply across every repo: never suggest disabling TLS verification, always confirm before a destructive git command, flag hardcoded secrets on sightA project
CLAUDE.mdholds what's specific to one repo: stack, auth model, known issue areas, and the standard a finding has to meet before it gets reported
Example project CLAUDE.md for a Django app:
# Security Review Context
- Stack: Python 3.12, Django 5
- Auth: session-based, custom RBAC in accounts/permissions.py
- Known issue areas: file upload handler, webhook signature check
- Standard: run ruff and bandit before flagging a finding
...Why it matters: the same review question gets the same quality answer whether it's the first review of the week or the fifth, and it's still just Claude reading a file, not remembering a conversation
Why it's the foundation: the playbooks, tool connections, and autonomy in the next three levels all build on this. Skip it, and there's nothing solid underneath them
Reader challenge: Does Claude already understand your project before you ask your first security question?
If the answer is still no after reading this, the fix takes less time than the next Level 1 prompt would
Move to Level 3: once Claude understands the project, turn a review repeated often into a playbook it can run itself.
Level 3: Repeatable Security Workflows
Core idea: Claude Code Skills turn a manual process into a repeatable workflow
A Skill is a named, reusable procedure. A set of steps to follow, not a one-time prompt
Chaining Skills into one playbook beats running each step by hand. One command starts a sequence Claude executes in order
Repeatable playbooks cut session-to-session difference. The same steps run whether it's the first review of the day or the fifth
Example Skills worth building for a solo review habit:
Skill | What it runs | Why build it |
|---|---|---|
| Reads the diff, maps affected inputs, checks against known issue areas in | Turns a 45-minute manual review into a checklist Claude runs and you confirm |
| Pulls the relevant logs, timelines the events, flags the first anomaly, drafts a summary | Cuts the time from alert to first draft timeline |
Reader challenge: Are you still coordinating every review step by hand, or can Claude run the playbook for you?
Move to Level 4: What's still missing is everything that lives outside it: logs, tickets, and telemetry.
Level 4: Connected security tool
Core idea: MCP connects Claude Code to the tools that hold the rest of the context.
Without MCP, context comes from copy-pasted logs and screenshots. With MCP, Claude pulls it directly from the source
Tool scoping matters more than the connection itself. Give each MCP server only the access the playbook needs, not blanket account access
Set up one MCP config once, and the same connected playbook keeps working every session after, not just the one it was set up in
Example | What it exposes | Why connect it |
|---|---|---|
Repos, PRs, issues, and code search | Claude reviews a PR against the actual diff and history, not a pasted snippet | |
A log platform MCP (Splunk, Elastic, and others ship their own) | Search, alerts, and saved queries | Claude pulls the real log window instead of working from a screenshot |
Detections, incidents, and threat intel from CrowdStrike Falcon | Claude correlates an alert with the actual detection data during triage |
Reader challenge: Is Claude Code limited to your local repository and local files, or can it securely retrieve the context it needs from your security tools?
Move to Level 5: the tools are connected and the playbook is defined. The remaining manual step is starting it, every single time
Level 5: Full autonomous agent
Core idea: Claude Code agent runs the playbook end-to-end. A human approves the steps that matter
Full autonomy here still keeps a human in the loop. It just means no one has to manually kick off each step in the chain
An autonomous agent can pick up a new PR or alert, run the Level 3 Skill, pull Level 4 MCP context, and produce a draft finding without anyone starting it by hand
Approval checkpoints get stricter at this level. Filing a ticket, notifying a channel, or closing an alert goes through a human first
Example | What it runs on its own | What stays human |
|---|---|---|
Autonomous vulnerability review agent | Watches new PRs, runs the review Skill, pulls MCP context, drafts the finding | You confirm the finding and decide what gets reported |
Autonomous vulnerability research | You validate the finding |
Reader challenge: Can your security process run end-to-end without manual coordination while keeping you in control of critical actions?
How to move up one level
Level 1 → 2: Write down the repo's stack, auth model, and known issue areas once, in a project
CLAUDE.mdLevel 2 → 3: Turn the review run most often into a Skill with a fixed, versioned set of steps
Level 3 → 4: Connect one MCP server for the tool pasted from most today: logs, tickets, or a threat intel feed
Level 4 → 5: Let the playbook trigger itself on a new PR or alert, but keep an approval checkpoint before anything gets filed or closed
At every level: Confirm every finding manually before it goes in a report. That doesn't change no matter how far up the ladder the playbook runs
Ready to apply AI to your Security Engineering?
Subscribe to Secengai Newsletter for weekly actionable content on AI for security engineers.
This content reflects personal views, experiments, and use cases in AI and security engineering. It does not represent any employer's positions, policies, or practices.
