Skip to content
Anshuman Bhartiya

Spec sheet for the career blueprint

The AI-native AppSec engineer

A blueprint for the AppSec career that is arriving, not the one that is fading

Every week someone asks me how to get into AppSec, or how to grow once they're in. The honest answer has changed. The job I learned (read the spec, review the code, file the bug, chase the fix) is being absorbed by agents I've helped build. What's left is more interesting: you design, measure and improve the agents that do that work, you make them something the rest of the company can call on their own, and you use every finding to make a whole class of bugs impossible.

So this isn't a list of certs. It's two acts. First, the same four workflows in both worlds, so you can see what has changed and what is still changing. Then the skills, what you end up owning, and a 90-day plan to become the engineer who does the after version.

Drawn by
Anshuman Bhartiya
Updated
November 2026
Contents
  1. Act 1: Two worlds
  2. Act 2: Becoming the after
  3. Your 90-day plan
  4. Why I believe this
Key
  • Stays the same: the fundamentals every version of this job rests on.
  • What changes: where the AI-native role departs from the traditional one.

Act 1: Two worlds

The same request, handled twice: once the way most AppSec teams still work, once the way I think every team will. Watch where the time goes, and what the human ends up doing.

Time to outcome

Four everyday AppSec workflows. For each, the same request runs through both worlds, plotted on one shared clock.

Pick a workflow. Each card is the same comparison in miniature: how long until the outcome, before and after.

Design review

The requestAn engineer needs a security review of a new design: a payments webhook that calls two internal services.

Timings are illustrative, from my experience, not measurements. Both rows share one logarithmic time axis: the gap from a minute to an hour is drawn about as wide as the gap from a day to a month. On an ordinary timeline the whole after row would be a single dot.

Step by step

Before agents1 to 7 days, then silence
Design review, before agents: every step
StepWhenWhoWhat happens
1Day 0EngineerFiles a Jira ticket asking for a security review and attaches the spec.
2Days 1–3QueueThe ticket waits behind everything else in the AppSec queue.Waiting
3Day 3AppSec engineerReads the spec, digs through old docs and pings the engineer to set up a call.
4Day 4BothA 30-minute meeting. Context comes from memory and whoever showed up.
5Day 5AppSec engineerWrites feedback in the ticket. How deep it goes depends on who picked it up.
6Day 7JiraTicket closed. Nobody checks whether the design that shipped is the design that was reviewed.
With agentsMinutes, then continuous
Design review, with agents: every step
StepWhenWhoWhat happens
1Minute 0EngineerAsks the design-review agent from inside Claude while still writing the spec. No ticket, no queue.
2Minutes 1–4AgentPulls context over MCP: the spec, both services’ repos, the service catalog, past incidents and our security standards.
3Minute 5AgentReturns a threat model and specific findings, each with evidence and a risk rating. The engineer fixes them before the doc is shared.
4Minute 10AppSec engineerOnly sees what the agent escalated: the one decision that genuinely needs human judgment.
5From then onAgentWatches for drift. When the code or infra moves away from the reviewed design, it flags the gap.Keeps running

What the old way missed

  • How the two internal services actually authenticate callers
  • The design changing three weeks later
  • Every "low-risk" design nobody filed a ticket for

What agents add

  • Depth no human reviewer has time for: every repo and doc, every time
  • Non-security engineers get unblocked themselves, instantly
  • Review becomes monitoring instead of a one-off

What the AppSec engineer does

Before agents
Spends the week as the bottleneck: reading, scheduling, chasing.
With agents
Builds and tunes the reviewer, decides what it escalates, and measures whether it is right.

Act 2: Becoming the after

Fundamentals still hold the building up. On top of them sit five skills that barely existed in the old job description, and they are the ones I would invest in first.

The five skills, and the fundamentals under them

Each skill is a line item: what it is, why it matters, and how you would know you have it. The base row is what everything else stands on.

  1. Context engineering

    Give agents the whole system, not just the diff.

    Agents are only as good as what they can see. Most real vulnerabilities live in the gaps between services, so the skill is wiring agents into repos, docs, service catalogs and infra over MCP, and choosing what they need to see for each decision.

    What good looks like

    Your agent dismisses a scary-looking change because it checked the other three services and knows it’s safe.

    Read VulnVibes and The future of AppSec

  2. Agent reliability

    Make agent reviews accurate, consistent and measurable.

    If humans stop reading the code, the agent’s accuracy is the security program. That means evals built from real advisories, tracking precision and recall, running across models and runs, and catching regressions every time you change a prompt or skill.

    What good looks like

    You can say how often your reviewer is right, and the number goes up every month.

    Read A benchmark for AI scanners and SecureVibes, measured

  3. Bug-class elimination

    Learn from every review so the next bug can’t be written.

    Each finding is a lesson. Turn it into a skill the reviewers use, a secure-by-default library, a guardrail in the coding agent and an eval case. The goal moves from closing tickets to making whole classes of bugs disappear.

    What good looks like

    A bug class that showed up every quarter hasn’t appeared in a year, and you can show why.

    Read Authz bugs at scale and Skills: the missing piece

  4. Security as a product

    Ship agents other people call themselves.

    The design-review agent only matters if engineers use it. Make your agents callable over MCP from the tools people already use, design what they say and when they escalate, and earn trust by being right and staying quiet when there’s nothing to say.

    What good looks like

    Engineers ask your agent before they ask you, and security stops being the queue.

  5. Securing agents

    Treat the agents that write and review code as part of the attack surface.

    Agents read untrusted input for a living: specs, logs, error reports, retrieved docs. Any of it can carry instructions. The skill is threat-modeling the agent itself, limiting what it can touch with tool allowlists and sandboxed subagents, and checking its actions with pre-tool hooks before they run, with a human approving the risky ones.

    What good looks like

    A poisoned ticket tells your agent to run a command, and a hook stops it before anything happens.

    Read Prototyping without getting pwned and Browser Relay

Fundamentals

You can’t judge an agent’s verdict on a bug you couldn’t find yourself.

  • Web vulnerability classes, learned by breaking real apps
  • Secure code review and data-flow diagrams with trust boundaries
  • Threat modeling (STRIDE) and how real breaches happened
  • Enough coding to read, write and ship the tools yourself

What you own, and how it changes

Four things an AppSec engineer ends up owning, roughly in the order people take them on. Each one shows what stays the same and what the AI-native version asks of you instead. It is not a ladder; most people are working on more than one at once.

1. Your own judgment

Learn how software breaks, with an agent at your elbow.

The first thing you own is the judgment no model can hand you. Hunt real bugs. Read breach write-ups until you can predict the root cause. Use an AI coding agent every day, but make it explain itself and review every line it writes. Then start pointing agents at security work and checking their answers against your own.

Stays the same
  • Web vulnerability classes, learned by breaking things: replay and tamper requests, chase authz and IDOR gaps.
  • Secure code review with a checklist, and data-flow diagrams with trust boundaries drawn on them.
  • Breach teardowns: what went wrong, what went right, where least privilege would have stopped it.
What changes
  • Run a security review with an agent and grade it against your own findings. That’s your first eval.
  • Write your first skill: a markdown file that teaches an agent one bug class you understand well.
  • Know how LLM apps fail: prompt injection, tool misuse, over-broad permissions.

2. A reviewer

Build the reviewer, then make it trustworthy.

Next you own a real workflow, like design review or code review. Learn it by doing it by hand, then build the agent that does it, wire in the context it needs, and measure it. The person who can say how often their reviewer is right is the person every team wants.

Stays the same
  • Risk assessments, threat modeling and security questions baked into design docs.
  • The vulnerability lifecycle: triage, route to an owner, remediate.
  • How your company’s systems connect: services, identity, gateways, infra.
What changes
  • Wire a reviewer into repos and docs over MCP, and choose what context each decision needs.
  • Build an eval set from real bugs and track precision and recall on every change.
  • Make your agent callable by non-security engineers, and watch how they actually use it.

3. The loop

Turn every review into a bug class that can’t come back.

This is where you stop being the best reviewer and start owning the system that learns. Your agents review everything; your job is to close the loop: findings become skills, secure defaults, guardrails and eval cases, and the same bug stops showing up. You also threat-model the agents your company ships.

Stays the same
  • Secure-by-default libraries, paired with detection for anything that drifts from them.
  • Architecture-level threat modeling across services, identity and infrastructure.
  • Partnering with engineering leads so security lands in their roadmap.
What changes
  • Close the loop: every confirmed finding becomes a skill, a guardrail and a regression eval.
  • Continuous review: drift detection on designs and living threat models instead of one-off reviews.
  • Agent hardening: tool allowlists, sandboxed subagents for untrusted input, human approval for risky actions.

4. The direction

Set the direction for humans and agents together.

Finally you own the direction. You decide where agents carry the load, where humans stay in the loop, and how authorization works when the actor is a model. Your leverage comes from a security platform the whole company calls into, risk models leadership understands, and public work others build on.

Stays the same
  • A risk model and risk register leadership signs off on.
  • A multi-year roadmap across vulnerability management, partnerships and tooling.
  • A network of engineering leaders who carry security without being asked.
What changes
  • Security as a platform: a set of agents every team calls over MCP, with clear escalation to humans.
  • Org-wide agent authorization: task-scoped, delegated, enforced by hooks before the action runs.
  • Honest public work: open-source tools, benchmarks and skills others can build on.

The six shifts

The whole change in one table. Each row is one place the AI-native job departs from the traditional one, and why.

Six shifts: from the traditional job to the AI-native one
No.BeforeAfterWhySource
1Security reviews a spec when a ticket reaches the front of the queue.Engineers call a review agent themselves and get answers in minutes.Waiting a week for security was never about the review. It was about the queue.The future of AppSec
2Humans review pull requests.Agents review every change in the loop, and PRs fade away.When agents write and ship code continuously, review has to move to where the code is made.VulnVibes
3You trust the tool’s output.You check the agent’s reasoning, measure how often it is right, and feed every miss back into its skills and evals.If humans stop reading code, the reviewer’s accuracy is the security program.A benchmark for AI scanners
4Fix the reported instance and close the ticket.Eliminate the class: an org-specific skill, a secure default, a guardrail and an eval.Every finding is a lesson the whole system should learn once.Authz bugs at scale
5Point-in-time reviews and workshops, written up by hand.Threat models generated from the code as it is now, kept current, with drift flagged.Systems change weekly. A hand-written artifact goes stale; one built from the current code is more likely to be right.Skills: the missing piece
6You secure the app.You secure the app and the agents building and running it.Agents are the new attack surface. Their actions get checked by hooks before they run, and authorization is the hard part.Prototyping without getting pwned

That is the shape of the job. Now the practical part: find your thinnest skill, and I will point you at the week of the plan to start from.

Where are you now?

Tick what’s already true for you. Be honest; nobody sees this but you, and it stays in your browser.

Fundamentals
Context engineering
Agent reliability
Bug-class elimination
Security as a product
Securing agents

Tick a few statements and I’ll show you your gaps, what to focus on, and where to start in the plan.

The 90-day build plan

Twelve weeks, a few hours each. Every week ends with something you can show: that’s the point. Use public tools, an intentionally vulnerable app and any coding agent.

Weeks 1–4: Foundations, with an agent at your elbow

Build the judgment you’ll use to grade agents later.

  1. Week 1Fundamentals

    Break a real app by hand

    Run an intentionally vulnerable app locally and find three bugs yourself, with a proxy and no AI.

    Show for it: Three short write-ups: the bug, the root cause, the fix.

  2. Week 2Fundamentals

    Draw the system

    Draw a data-flow diagram of the same app with trust boundaries, then walk STRIDE over it.

    Show for it: A one-page threat model.

  3. Week 3Agent reliability

    Grade an agent

    Ask a coding agent to security-review the app. Compare its findings with yours: what did it miss, what did it invent?

    Show for it: A table of agent findings marked right, wrong or missed. That’s your first eval.

  4. Week 4Bug-class elimination

    Write your first skill

    Turn one bug class you understand into a markdown skill and rerun the agent with it.

    Show for it: The skill file, and before/after results.

Weeks 5–8: Build the reviewer

Ship an agent other people could use, and know how good it is.

  1. Week 5Context engineering

    Wire in context

    Write a short design spec for a feature that spans two small services. Build a design-review agent that reads the spec and both repos over MCP.

    Show for it: Reviews of the same spec with and without the extra context.

  2. Week 6Security as a product

    Make it callable

    Expose the reviewer as an MCP server or skill a non-security friend can run from their own tools. Watch them use it.

    Show for it: Their first unprompted review, and what you changed after watching.

  3. Week 7Agent reliability

    Build the eval set

    Collect ten specs or changes with known issues and five clean ones. Score precision and recall.

    Show for it: An eval script and a baseline score.

  4. Week 8Agent reliability

    Make it consistent

    Run the eval across two models and several runs. Take the union, cut the noise, and decide what gets escalated to a human.

    Show for it: A better score, and a written escalation rule.

Weeks 9–12: Close the loop

Make the system learn, then show your work.

  1. Week 9Bug-class elimination

    Retire a bug class

    Pick the class your reviewer catches most. Build a secure default or guardrail so it’s hard to write, and add regression cases.

    Show for it: The default, the guardrail and the new eval cases.

  2. Week 10Context engineering

    Watch for drift

    Change the app so it no longer matches the reviewed design, and make your agent notice on its own.

    Show for it: A drift alert with its reasoning.

  3. Week 11Securing agents

    Threat-model an agent

    Threat-model an agent you run, your reviewer from week 5 or the coding agent you use every day: prompt injection through what it reads, tool misuse, over-broad access. Fix the worst one with a tighter tool allowlist or a pre-tool hook.

    Show for it: An agent threat model and one hardening change you tried to get past.

  4. Week 12Security as a product

    Publish it

    Write it up with your eval numbers, including what didn’t work, and open-source the eval set.

    Show for it: A public post and repo. This is your portfolio.

Why I believe this

The after world isn’t hypothetical. These are numbers from experiments I ran and tools I build.

Evidence from my own experiments

Measured, not estimated. Every number links to the post where I published it.

In the workshop

Things I build that show the role in practice.

Projects in the workshop
No.ProjectWhat it isWrite-up
1SecureVibesOpen-source multi-agent scanner: assess, threat model, review, report.SecureVibes
2VulnVibesReview agent that investigates across services before it raises its hand.VulnVibes
3OpenClaw advisory benchmarkReal-world cases for scoring AI scanners honestly.A benchmark for AI scanners
4FlowRailA pre-tool hook that checks AI coding agents’ actions against policy before they run.Not written up yet
5RunSortieAn AI-assisted code-security bug-hunting CLI.runsortie.xyz

Drawn by Anshuman, revised as the job keeps changing.