DEF CON 34: Where AppSec, AI, and Bug Bounty Are Colliding

Autonomous hackbots are getting better. So are the attacks against them. DEF CON 34 showed why the next phase of AppSec will need both machines and human judgment.

Every year, DEF CON drops an absurd amount of security research at once. Trying to summarize all of it usually turns into a list of talk titles that nobody remembers a week later.

I took a different route with DEF CON 34. I followed one thread through the main conference, AI Village, Bug Bounty Village, Recon Village, and the OWASP challenges.

The same idea kept showing up: AppSec, AI security, and bug bounty are starting to overlap. Sometimes cleanly. Sometimes messily.

We now have agents that can map a target, choose tools, run tests, and adjust their approach based on what comes back. At the same time, those agents are becoming targets themselves. Give a model access to internal data, a browser, a shell, or a deployment tool and prompt injection stops being a weird chatbot trick. It becomes an application-security problem.

That tension was the interesting part of DEF CON 34.

AppSec defines the trust boundaries. AI expands coverage. Bug bounty supplies real adversarial pressure.

Security automation can make decisions now

Security teams have automated repetitive work for years. Feed a list of domains into a script, run the same checks against each one, collect the output. Fast, predictable, easy to audit.

Agents change one important part of that workflow: they can decide what to do next.

Give an agent a goal and it can observe the target, form a hypothesis, pick a tool, inspect the result, and loop. That is useful when the path is not known in advance. It also means scope, permissions, cost limits, and stopping conditions can no longer be treated as afterthoughts.

A script follows a route chosen in advance. An agent chooses its next step from the evidence in front of it.

HALctf made the distinction easy to see. The DEF CON contest listing described it as the conference's first autonomous-only CTF. Competitors submitted self-contained Docker agents built around open-source models. Humans did not directly work the targets; the agents had to scout, exploit, and pivot inside an isolated environment.

That is a much harder problem than asking a model for a payload. The agent has to remember what it already tried, separate signal from junk, recover when a tool fails, and recognize whether it actually made progress.

AI Village pushed on the same area from a teaching and research angle. Its DEF CON 34 material covered building agents from scratch as well as adversarial attacks against agentic systems.

The model gets most of the attention, but the surrounding engineering decides whether the system is useful. State management matters. Tool design matters. Validation definitely matters.

Hackbots need evidence, not confidence

Jason Haddix and Ryan Bonner's Hackbots session at Bug Bounty Village dealt with the practical side of building AI-powered penetration-testing bots. The agenda covered single-purpose and multi-stage bots, tool integration, output parsing, hallucination control, cost, and auditability. Their examples included asset discovery, endpoint analysis, and focused testing for issues such as XSS and SSRF.

XSS lets attacker-controlled content run in another user's browser. SSRF tricks a server into sending a request the attacker should not be able to make, sometimes into an internal network or a cloud metadata service.

Those tests depend on context. Not just a better prompt.

In this setting, context engineering means deciding exactly what the agent knows: program scope, authentication state, discovered endpoints, prior requests, tool output, rules, and evidence. Dump everything into one giant conversation and the agent eventually loses the plot. Give it too little and it repeats work or misses the relationship between two clues.

Albert Corzo's main-conference presentation, Taming the Swarm, took a deliberately constrained approach. Small specialist roles. Limited context. Deterministic execution. External validation. Preserved state. Human review.

I like that design because it separates ideas from proof:

A model proposes a test.
A specialist agent handles one narrow job.
A pipeline keeps the work in order.
Real tools touch the target.
A validator checks the evidence.
A person decides whether the result is worth reporting.

Agent consensus is not validation. Five agents can repeat the same bad assumption just as easily as one. A raw request, a response, and a clean reproduction are harder to argue with.

The agent can generate hypotheses quickly. Scope, replayable evidence, and human review keep those hypotheses honest.

RAG fits into this picture too. Retrieval-augmented generation gives the model a controlled source of extra information, such as API documentation, internal standards, or previously disclosed reports. Useful context, yes. Proof that the current target is vulnerable, no.

If I were introducing agents into an AppSec program, I would start with one boring, bounded task. Classify endpoints. Map JavaScript routes to APIs. Generate candidate test cases for one vulnerability class. Keep every network request visible and replayable, then measure whether the agent actually saves analyst time.

Bug bounty hunters should be just as strict. Let the machine chew through repetitive recon. Save the human attention for business logic, exploitability, impact, and disclosure.

The hackbot can be hacked

The offensive demos get the headlines, but the defensive problem may be bigger.

Once a model can call tools, read private data, or change a system, it is a privileged software component. The chat box is only the front door. Behind it may be system instructions, a RAG store, internal APIs, long-term memory, a browser, code execution, and credentials. Every connection is another trust boundary.

Prompt injection is the obvious entry point. Attacker-controlled text convinces the model to behave in a way the application did not intend. With indirect prompt injection, the attacker never touches the victim's chat. The instruction arrives inside something the agent later reads: a web page, support ticket, document, log entry, email, or retrieved record.

Reading hostile text is not automatically catastrophic. Reading it with one hand on a privileged tool is where things go sideways.

Barak Sternberg, Nevo Poran, and Ron Bobrov's remote agent-takeover research showed how legitimate agent features could be chained against the system. Attacker-controlled telemetry entered the agent's context without trustworthy provenance. Read tools and privileged write or execution tools lived in the same workflow. Their deck also documented a network-sandbox bypass reported to Anthropic and described as patched.

Strip away the AI terminology and this looks familiar: untrusted input steers a component that acts with somebody else's authority. A confused deputy, with an LLM in the middle.

The dangerous boundary sits between what an agent can read and what it is allowed to do.

The controls are mostly good AppSec hygiene, applied to a new kind of component:

Treat model output as untrusted data.
Track where retrieved content and tool results came from.
Separate read-only tools from tools that write, execute, deploy, or transfer.
Give each tool the smallest permission and scope it needs.
Validate tool parameters in code.
Require confirmation before high-impact or irreversible actions.
Log the context, tool call, result, and decision path.
Put hard limits on time, cost, requests, and target scope.

A system prompt that says "ignore malicious instructions" is not an authorization layer. Code-level checks, isolation, allowlists, typed tool contracts, and approval gates can fail closed. Natural-language guidance cannot.

AI will help bug bounty, and flood it with junk

Bug bounty is where the upside and the downside collide first.

The DEF CON 34 Bug Bounty Village CTF used a living web application instead of disconnected riddles. Participants looked for business-logic flaws, attacked APIs, tested AI chatbots, and sent findings to a live triage team. The organizers specifically recommended reviewing API security and prompt injection.

That mix makes sense. AI can surface suspicious endpoints and strange response differences quickly. It is much worse at proving what the difference means.

Take IDOR or BOLA. Both describe broken object-level authorization: change an identifier and the application may expose or modify another user's data. A tool can vary IDs and compare responses. It still needs account context, ownership boundaries, and a safe reproduction before it can claim a real vulnerability.

AI is already useful for:

Inventorying assets and classifying technologies.
Pulling routes, parameters, and API calls out of JavaScript.
Comparing authenticated and unauthenticated behavior.
Grouping similar endpoints and ranking odd responses.
Drafting tests for one vulnerability class.
Cleaning up notes and assembling evidence.

It should never fill gaps in that evidence with a confident paragraph.

The Bug Bounty Village agenda addressed the noise problem directly. One panel focused on AI-assisted submissions and triage bottlenecks. Another session described a multi-agent framework that modeled a target from JavaScript, API specifications, authentication flows, and documentation, then pushed every candidate finding through reproduction. A presentation from Google's AI vulnerability reward program drew a useful line between an actual security impact, such as unauthorized data access or action, and a jailbreak that only produces unwanted text.

That line matters. So do the old questions: Who can be harmed? Which trust boundary was crossed? Can somebody else reproduce it? Is the proof safe and inside scope?

AI does not answer those questions for the researcher. It gives the researcher more places to look.

Finding the bug is only half the job

One of the strongest DEF CON 34 ideas had nothing to do with autonomous offense.

The OWASP Secure Development CTF used six deliberately vulnerable applications, including Juice Shop, WebGoat, DVWA, Security Shepherd, VulnerableApp, and VAmPI. Participants found a vulnerability, patched the code in a fork, opened a pull request, and passed an automated regression test. The site listed 321 web and API challenges.

That is much closer to real AppSec than popping a flag and walking away.

AppSec Village carried the same idea into its Fix the Flag wargame. Exploitation mattered, but so did remediation and hardening.

Fixing a flaw without breaking the application is a separate skill. So is writing the test that keeps it fixed. If we want to evaluate AI security tools honestly, that should be part of the benchmark. Can the agent identify the vulnerable behavior, propose a small patch, explain the security rule being restored, and write a test that would catch a regression?

Finding a suspicious line is easy by comparison.

Recon is turning into target modeling

Collecting the largest possible pile of subdomains is not much of a strategy. The more interesting recon work at DEF CON 34 focused on turning discovery into a usable model of the target.

Recon Village's BBOT workshop covered recursive, event-driven discovery across subdomains, cloud assets, web content, and vulnerability scanners. The same schedule included "Groking the Kill Chain," which used an "agents on rails" approach. Specialist agents were tied to real tools, specific pipeline stages, prerequisites, timeouts, and sandboxes. Deterministic binaries made the network requests.

That separation is smart. Let the model reason over the evidence. Let narrow tools perform the action. Enforce scope underneath both.

A practical bug bounty pipeline might be:

Discover in-scope assets.
Classify the technology and confidence in ownership.
Extract endpoints, parameters, authentication flows, and JavaScript routes.
Choose a few vulnerability-specific tests.
Save the raw requests and responses.
Reproduce anything that looks real.
Hand the evidence to a human researcher.

More requests are not the goal. Better use of attention is.

What I would do with this now

If you run AppSec

Start by inventorying where agents already touch source code, tickets, logs, deployment systems, cloud consoles, and internal knowledge. Draw the trust boundaries. Label every tool that can read, write, execute, or approve.

Then attack the workflow. Try prompt injection, poisoned retrieval, cross-tenant access, excessive permissions, and unsafe chains of otherwise legitimate actions. Preserve the tool inputs and outputs so failures can be replayed.

If you hunt bugs

Automate one repetitive task before trying to build an autonomous hunter. JavaScript route extraction, asset classification, and request clustering are good places to begin.

Keep the raw traffic. Treat every model-generated claim as a lead, not a finding. Before submitting, try to prove yourself wrong.

If you lead an engineering team

Treat an agent like a privileged service account attached to an untrusted interpreter. It needs an owner, a threat model, narrow identity and authorization, logging, incident response, and a kill switch.

Measure the unglamorous things: validated findings, false-positive rate, analyst time saved, scope escapes, failed tool calls, and actions that needed rollback. Demo speed is not a security metric.

Where this is heading

I do not expect unsupervised agents to replace AppSec teams or bug bounty researchers. I do expect narrow agents to become normal parts of both workflows.

They will map attack surfaces, connect scattered clues, run focused tests, replay reports, propose fixes, and watch for changes. People will still define scope, recognize broken business logic, judge impact, choose a safe proof, and own the disclosure.

Meanwhile, those same security teams will have to defend the agents. Prompt injection, poisoned retrieval, weak tenant boundaries, overpowered tools, unsafe memory, and confused-deputy actions belong in the AppSec backlog now.

That is what I took from DEF CON 34. AI gives security work more reach. AppSec keeps that reach inside a trust model. Bug bounty tells us whether the model survives contact with a creative adversary.

The useful systems will not be the ones that sound the most certain. They will be the ones that can show their work.

A map of the overlap: agentic testing expands coverage, AppSec supplies the controls and remediation, and human researchers keep the work grounded.