How to Build an AppSec Program with Claude, Then Govern It

Your AppSec team closed 1,100 vulnerabilities last quarter. The board nods, then asks which of the open ones an attacker could use against your customers tomorrow. If the room goes quiet, the problem isn't your scanners.

That's the scene Perry Menezes, Cyber & AI Tech Risk and Advisory Exec and a former partner at KPMG, opened with at apisec|con 2026. Perry spent 15 years on what financial services calls the second line of defense, the risk and oversight side that asks security teams how they know what they're doing is secure. His session, How To Build an Appsec Program with Claude, is a blueprint for adding AI to the program you already run without losing control of it.

His core argument: most AppSec programs don't fail. They stall, on inventory, capacity, judgment, evidence and translation between teams. "So notice, of the five things that I mentioned, not one of them is a detection problem, right?" [10:43]

The board doesn't want closed tickets. It wants exploitability.

Perry's example is a hypothetical bank he calls Harborline. At the quarterly risk committee, the AppSec lead puts up a slide: 1,100 vulnerabilities closed, lots of green arrows, polite applause. Then a board member asks the question that matters:

"Which ones could an attacker actually use against our customers tomorrow?" [04:28]

The AppSec lead looks at the CISO, the CISO looks at the CRO, and someone says they'll get back to the board. As Perry puts it, they had all the data points but not "the connective tissue" between them.

Closed-ticket counts measure effort. Boards now ask about exploitability, and a volume chart can't answer that. The answer has to come from testing what an attacker can actually reach and use.

The inventory said 340 APIs. There were 412.

Perry's first step in any program is knowing what you have. In the example he shared, an inventory listed 340 services. Reconciled against what was actually running, the count was 412. One of the extras was a version one mobile banking API "that should have been retired two years ago but was still running account details." [24:04] No owner. Not tested in years.

His standard for every API in the inventory: a named owner, a data classification and a known exposure. Without them, the rest of the program has nothing to stand on. "You can't prioritize by exploitability if you don't even know exposure." [24:43]

This is the discovery problem in plain numbers. You can't find a weakness first in an API you don't know exists, which is why discovery comes before testing.

Your AI agent is a privileged identity now

The part of Perry's talk most AI sessions skip: once AI tools can read your repositories, write pull requests, run commands on developer laptops and connect to your gateways, they are no longer tools.

"Now it's actually Claude as a privileged identity, right? This is where most AI talks skip." [31:47]

They are in scope for security and risk, and they can be manipulated. Perry's example is a code comment that tries to talk the AI reviewer into approving the file. His controls are the ones you already use for service accounts: human approval for changes, no automatically applied patches, approved MCP servers only, sub-agents with only the tools they need, logging, and mapping to frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001. "It's not sexy, this is not exotic, and it's not supposed to be." [34:04]

Treat AI as capacity, then govern it

Perry's frame for AI is capacity, not another scanner: an analyst that reads code, specs, policies and tickets and reasons across them. His example prompt asks for every endpoint in an OpenAPI spec that returns customer data and where authorization is enforced, and asks the model to say when it can't find it. A person needs days. The model needs minutes. "But then the human checks the answer, right?" [14:32]

He is direct about the limits:

"Claude can be confidently wrong. It's not deterministic." [15:01]

That is the point defenders should hold on to. Models are useful for exploring. A security decision you report to the board needs a result you can reproduce, run after run, with evidence a person can check.

API flaws are logic problems, not syntax problems

Most of the OWASP API Top 10 are logic flaws. With Broken Object Level Authorization (BOLA), the code looks fine and the endpoint checks that you logged in. It just never checks that the record you asked for belongs to you. Excessive data exposure is the same: a well-formed response returning fields nobody should see.

"It's a reasoning problem, and that's exactly where we find that the scanners and some of the tools are at their weakest." [12:46]

These flaws live where the layers meet: authorization, data access and business logic. Finding them means understanding what each endpoint is supposed to do, then proving what it actually does.

When scanner and AI disagree, write it down

Perry's principle for adding AI is "blend it, don't replace it." [18:43] Keep your scanners for the deterministic work and add AI as a reasoning layer in the gaps. That creates a new problem: the scanner says critical, the AI says the code isn't reachable.

"Your scanner says critical, but Claude says, "I'm not reachable." What do you do then, right? Write it down." [21:53]

Decide up front whose severity wins, keep one source of truth, and record every disagreement. That record becomes your risk acceptance, the evidence auditors and examiners ask for.

What this means for your program

Perry's blueprint runs in five steps: know, set, find and fix, prioritize, and prove. His advice for the first 90 days is to start narrow, govern first and measure everything. In practice:

1. Reconcile your inventory against reality. Compare what your catalog says against gateway logs, code and runtime. Give every API an owner, a data classification and an exposure. The free, open-source apisec Surface tools map applications and APIs from code.
2. Run AI alongside your existing tools for 30 to 60 days. Same repos, same infrastructure. Compare overlaps, real issues only one side found, and false positives, then decide with data.
3. Write down whose severity wins before the first disagreement, and keep one source of truth in your ticketing system.
4. Register every AI agent as a privileged identity. Record its access, its autonomy, what could go wrong, its controls and its owner, and require human approval for anything that changes code.
5. Report exploitability, not volume. Answer the board's question with issues proven exploitable against the running application. apisec Exploit Testing runs the attacks against your live application and records what is confirmed, cleared or blocked.

One question to ask yourself today

Perry closed with a single ask: pick one critical API domain, write the one-page agent risk register, and ask your team which open issues an attacker could use against your customers tomorrow.

"If it takes more than a day to answer that question, now you know where you need to start, right?" [39:36]

That question is the board's mandate now: know the footprint, measure what model-powered attackers can do to it, and close the doors that can do the most damage first, with proof they're closed.

Watch the full session above, and see what's reachable in your own estate with the free apisec Surface tools.

FAQ

Should AI replace our existing AppSec scanners?

No. Perry Menezes recommends blending AI with the tools you already run, not replacing them. Scanners keep doing the deterministic work: rules, baselines and build gates. AI adds a reasoning layer that triages what the scanners produce and fills gaps between teams. Run both on the same repos for 30 to 60 days and decide with data.

Why do AppSec programs stall?

In Perry's experience, programs rarely stall for lack of tools. They stall on five things: an incomplete inventory, limited capacity, judgment calls where everything is rated high, missing evidence for boards and regulators, and translation gaps between engineering, security and risk teams. None of those is a detection problem, so buying another scanner rarely fixes them.

Why is an AI agent a security risk?

Once an AI tool can read repositories, write pull requests, run commands or connect to gateways, it is a privileged identity in your environment. It can also be manipulated through untrusted input, such as a code comment. Perry advises governing it like any service account, with human approval, least privilege, logging and a named owner.

What should a CISO report to the board instead of vulnerability counts?

Report exploitability: which open issues an attacker could actually use against customers, ranked by the damage they could do. Perry's test is whether your team can answer that within a day. In apisec's view, the answer should rest on issues proven exploitable against the running application, with evidence the fix worked.