The future of AppSec in the age of AI

Audience: AppSec engineers, DevSecOps teams, red teamers, and open source maintainers who want application security coverage without stitching together five separate tools.

DrogonSec is an open source, Go-based scanner that combines SAST, SCA, secrets detection, and Infrastructure as Code analysis in a single engine. It is the successor to Horusec. Findings map to the OWASP Top 10:2025 and align with MITRE ATT&CK, so results speak the language of both developers and security teams. An optional AI-assisted layer, running on local models through Ollama, suggests remediation without sending code to a third party.

The session shows how the engine is built, why a unified scanner changes triage, and how it plugs into GitHub Actions pipelines under an Apache 2.0 license.

What you will learn:

• How to run SAST, SCA, secrets, and IaC checks in one pipeline step and cut tool sprawl.
• How mapping findings to OWASP and ATT&CK makes prioritization clearer for both defenders and attackers.
• How to use local LLMs for remediation guidance, and where their limits are (CPU-only inference, model size, timeouts).
• How to adopt, extend, or contribute to an open source scanner in your own CI/CD.

Who this is for: API security engineers, pentesters and the platform teams who now review code an agent wrote against APIs an agent called.

Most of the code in my repos right now was written by a coding agent. I'm guessing yours is heading the same way. Every one of those sessions ends, and when it does, whatever the agent figured out about your API goes with it. Which endpoint has to be called before that other one. Which field is actually required. Which call returns a 200 and does nothing. That used to be tribal knowledge, and at least you could walk over and ask Joe. Now there's no Joe. There's a diff, and nobody who remembers why.

I spent this summer running hundreds of agent sessions against real APIs, with real credentials, trying to prove the idea was worthless. I kept score. Some of it went against me and I'll show that part too. The short version: an agent builds on whatever context is sitting in front of it. Stale, wrong, or put there by someone else, it doesn't check. And it never goes looking for anything that isn't in front of it. For API security that's the whole game. The context an agent had when it wrote the code is the thing you need to review, and today nobody keeps it.

I'll walk through what an agent's API context actually looks like, where it comes from, the ways I watched it go wrong, and what that changes about reviewing agent-written API code. Then I'll show what I'm building to fix it: Sannr, an open source API client that keeps what agents learn about your APIs verified against the live API and committed with the code, so the next agent, and the next reviewer, gets it.

Most AppSec programs aren't short on scanners. They're short on capacity, context, and evidence: inventories nobody trusts, backlogs nobody can read, “critical” findings that don't matter, and board reports that answer the wrong question. AI changes that equation, but only if it's run as a governed program rather than another tool.

This topic lays out a practical blueprint for using Claude across the AppSec lifecycle: Know your API estate, Set standards developers will use, Find & Fix logic flaws scanners miss, Prioritize by exploitability rather than severity, and Prove progress to boards and examiners. This topic addresses what most AI talks skip: the agent itself is now a privileged identity in your environment and part of your attack surface. That means governing it with least privilege, human approval, prompt-injection defenses, and clear accountability.

No demo, no code. You'll leave with a 90-day plan, an agent risk register, and five metrics to take back to your CISO.

Frontier models like Mythos have changed the attacker's economics. Finding vulnerabilities, writing exploits and launching thousands of agents now costs very little, and open-weight models with similar cyber capability are close behind, running on attackers' own hardware where no vendor safeguard or monitoring applies. Defenders cannot answer that by patching faster.

Former Charles Schwab CISO Bashar Abouseido makes the case for “hyper defense”: using AI across every part of security, building continuous context about what findings mean, and focusing scarce engineering time on what is exploitable.