1. The experiment

With the recent hype surrounding Mythos and its autonomous vulnerability discovery capabilities, the question of what AI can do for security research is hard to ignore. Most of that conversation centers on fully autonomous systems — multi-agent frameworks operating at scale with large budgets. I wanted to try something way simpler: what can one person accomplish with a single AI agent and a modest budget?

I came in with five things: familiarity with the target as a practitioner, enough Python and Django knowledge to steer the agent, years of application security experience, an evening to experiment, and a $20 Claude subscription with Cyber Verification Program approval.

Photo by Archive Photos/Getty Images — © 2012 Getty Images. (cropped image)

2. The hypothesis

My target is a Django-based web application enforcing a role-based access model — controlling who can see which resources, data, and system settings, at what level of detail. The access control model is the interesting surface.

I asked Claude to map the REST API — URL patterns, associated models and views — and report back on any gaps in URL parameter validation. It flagged something it thought looked interesting: a parameter responsible for fetching related objects alongside the primary response. My intuition when I saw it: likely a WebUI-driven performance optimization added on top of the existing API functionality, making the authorization model a potential target for logical flaws. Features like this get tested for functionality — does it return the right data? — but access control testing of this specific path may not have received the same attention as the core endpoints. Performance shortcuts and abstraction layers are common places where authorization logic gets underspecified, because they’re added later and the direct-endpoint tests don’t exercise them.

Whether it would lead anywhere was an open question.

3. How the research ran

From that exchange — Claude surfacing the parameter, me recognizing the authorization angle — we had a hypothesis. I asked Claude to examine how the feature works internally. It traced the relevant source files and identified the core gap: when the feature resolves a related object, no check is made against whether the requesting user is authorized to see it. The access controls on the direct API endpoints are simply not invoked in this path.

From there: local Docker instance, Claude calling the application’s own REST API with admin credentials to provision test accounts and settings, then switching to an unprivileged account to test the hypothesis. The test pattern was clean — confirm the direct endpoint returns 403, then show the same data returns through the bypass. Seeing both in the same output is unambiguous.

The first two bypass paths were straightforward once the root cause was clear. I then asked Claude to think more broadly about the attack surface, prompting it to consider how Django’s data model exposes direct and reverse object relationships. It identified three additional paths, including one through internal notes that users can mark private — the bypass returns their full content regardless, circumventing the visibility restriction the UI enforces.

Five exploitable paths in total, all from the same root cause — Missing Authorization (CWE-862) across the board, with Exposure of Sensitive Information (CWE-200) sprinkled in. Network-exploitable via the REST API by an authenticated user with read permissions, accessing admin-only data. Drafted to CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (4.3 Medium).

4. Chasing the escalation

The core bypass came together quickly. What followed was the natural next move for any researcher: try to chain it, escalate severity, turn a Medium into something bigger. That’s where most of the dead ends lived. Some of the vectors we tested:

• Could the bypass leak API authentication tokens (full account takeover)? Blocked.
• Could it be flipped into a write path? Read-only by design.
• Could unusual parameter values expose internal state or crash the app in a useful way? One 500 error, no data.
• Could object traversal chain across multiple hops to reach higher-value targets? Limited to one level.
• Could the attack surface extend beyond the object relationships already mapped? Explored and found nothing new reachable.
• Could reading related data trigger a server-side request — an SSRF via this feature would have been a significant escalation. Nope.

Thorough analysis of every relevant code path found nothing exploitable. At some point Claude even made a comment that the codebase outside the bypass appeared well-hardened — the dead ends weren’t just unlucky angles, they were genuinely blocked.

The dead-end analysis likely consumed more tokens than the core bypass itself. Each candidate path required the agent to load and reason over significant amounts of source context before concluding it was blocked. At some point I made a call to stop — it was getting late, and it was clear the token burn rate on escalation paths was outpacing any realistic chance of a meaningful outcome.

5. Division of labor

Across the full session, the process looked like this:

Target selection was mine. The application is open source with a commercial offering, backed by OWASP, and used in production by security teams — that’s how I knew about it. Hundreds of releases and thousands of GitHub stars; it runs a HackerOne bug bounty program for many years with a good number of submissions behind it.

Attack surface discovery was Claude’s. Asked to map the REST API — URL patterns, models, and views — it flagged a specific parameter as worth investigating: one responsible for fetching related objects alongside the primary response. That observation became the hypothesis we tested.

The hypothesis was joint. I directed the exploration and recognized why the parameter Claude surfaced was worth pursuing — that features like this tend to be undertested for authorization completeness. That judgment comes from years of looking at application security. An autonomous agent starting from scratch has no basis for it.

Reading and tracing source code across a large, unfamiliar codebase — holding relevant context across many files simultaneously — was Claude’s most consistent contribution. Work that would take a human hours of careful reading took Claude minutes. That’s where LLMs really shine.

Environment setup was handled by Claude directly against the live application. The agent called the target’s own REST APIs with admin credentials to provision the test accounts and configuration needed to validate each vector — then switched to an unprivileged account to confirm the bypass. No manual setup required and it knew the APIs already from reading the codebase.

PoC development and live validation was Claude’s. It wrote the test scripts, ran them against the live Docker instance, interpreted the results, diagnosed problems and iterated to completion.

Steering was mine throughout. When the initial finding was confirmed, I directed Claude to expand the search along a specific axis: how Django models expose object relationships, and where those traversal paths might reach objects the requesting user shouldn’t see. That framing produced three additional bypass paths.

Boundary analysis was Claude’s. When I asked whether the initial finding could be chained or escalated, Claude systematically traced each candidate path and explained whether it was viable or blocked and why.

Impact assessment was mine. One of the five bypass paths exposes internal security notes that teams mark private. Characterizing what that means in a real-world application requires understanding how those notes are used in practice, not just what the access model technically permits.

Structured reporting was Claude’s — CVSS scores, impact analysis, affected-code tables, and remediation recommendations for all five findings in a single consolidated report, with live response examples for each confirmed vector.

6. Numbers and disclosure

What led to this session was a failed attempt with one of the open source autonomous frameworks. I pointed it at the same target, let it run, and watched it burn through 2.5 million tokens — mostly attempting to set up its own environment, failing to start the target application it didn’t need, and exhausting its budget before reaching the actual testing phase. That experience prompted the question: what could a different approach produce?

Our session — hypothesis to five confirmed findings, with live validation, dead-end analysis, and a full structured report — consumed 1.4 million tokens at a total API cost of $25. That gap is partly explained by the hypothesis: starting from a well-formed idea of where to look is a significant multiplier on what a given budget can produce. Autonomous tools trading specificity for breadth need proportionally more tokens to work through open-ended reconnaissance before they converge on anything. It’s also worth noting that Anthropic’s model is arguably more capable than what the open source framework was running — and more expensive per token — so the human-agent configuration does double duty: it keeps the effort targeted, and that targeting matters more when the model you’re running costs more to use.

After the core research wrapped, I asked Claude to analyze the git commit history and map when the vulnerable feature was introduced. It traced the initial commit to January 2021 — identified the exact PR that introduced it and confirmed the authorization gap was present from the start — then mapped the feature’s expansion across subsequent releases. The finding had been in production for over five years across multiple major version milestones, including a significant expansion of the attack surface in 2023 that added it to roughly twenty additional API endpoints.

I submitted the findings to the vendor’s HackerOne bug bounty program — public, improvement-oriented, no monetary bounties. The report covered all bypass paths with confirmed live responses, CVSS scoring, and root cause analysis. A follow-up post with the full technical details will go up once the disclosure process is complete.

Final thoughts

Looking at the flow diagram, the natural question is: can the human node be replaced with another autonomous agent? Yes — projects like Mythos and Shannon demonstrate that fully autonomous security research is viable, and companies operate at scale doing it. The cost is higher: an autonomous agent has to discover through exploration what a human researcher brings as context, and that shows up in the token count.

All in all, a Medium severity authorization bypass with five confirmed network vectors, in a reasonably hardened codebase in a single evening — that’s a good result in my book, and it took way less effort than comparable research I’ve done solo. Happy bug hunting!

My professional career in network security started in 2005 when I joined Juniper Networks’ IDP team — which is probably why, when thinking about how to detect a misbehaving agent, my mind went straight to a technique from that era.

The IDS world solved an analogous problem decades ago. A network intruder probes hosts and services they have no business touching; a honeypot sits in those places looking like an attractive target — an exposed SSH server, an unprotected admin console — but it’s a decoy, and it alerts when anything interacts with it. Honeypots are traps, tripwires — there’s no legitimate use for a fake host, so the false-positive rate is near zero.

The same idea can be applied to AI agents: plant bogus credentials where a rogue agent would look, and treat any access as a signal. Rather than trying to define what legitimate agent behavior looks like — which is hard, because legitimate agents do a lot of things — it defines what illegitimate behavior looks like: touching credentials that were never surfaced as part of the task. That’s a tighter definition, and it maps well to the threat model.

1. The threat

An AI agent running on a developer machine or in CI has access to everything its process can read: ~/.aws/, ~/.ssh/, ~/.kube/, ~/.config/, environment variables, dotfiles, every file in the project directory. That access is usually not scoped to what the agent actually needs to do its job — it’s scoped to the developer’s own permissions, because that’s how agents tend to run inside an IDE.

There are three failure modes this matters for, in increasing order of intent.

• Overprivileged agents. A legitimate, well-behaved agent still runs with the developer’s full filesystem permissions. It may passively sweep up credential files while reading context, or actively reason that credentials it found are relevant to the task — either way, not out of malice, just because nothing stops it. The agent’s judgment about what it’s authorized to do is not the same as what it’s actually authorized to do.

• Prompt injection. A malicious instruction embedded in content the agent processes — a README, a web page, a database row — redirects the agent to look for credentials and exfiltrate them. The agent is not compromised; it’s following instructions that were smuggled into its context. It tops the OWASP Top 10 for LLM Applications as LLM01:2025, and for good reason — it exploits the design of LLMs rather than a flaw that can be patched.

• Compromised agents. A model that has been fine-tuned adversarially, or a scaffolding layer with a supply-chain compromise, probes the environment deliberately. Skills and MCP servers install from the internet with no signing and no scanning — malicious ones are a real and active delivery mechanism, not a future concern. The emergence of dedicated skills security solutions is evidence enough that this threat is already being taken seriously.

The distinguishing behavior is the same in all three cases: the agent accesses resources it was never explicitly directed to use.

2. Why defenses fall short

What makes this more dangerous is how creative agents get in pursuing their goals. Anthropic’s agentic misalignment research stress-tested models in simulated corporate environments and found that agents would pursue their assigned goals through unexpected means when straightforward paths were blocked: leaking sensitive information to competitors, attempting to influence their own evaluation, sabotaging research they disagreed with. The models weren’t broken; they were doing what they were optimized to do, just not in the way their operators intended.

This creativity makes naive defenses, such as blacklisting certain paths, blocking specific tool calls, or simply instructing the agent not to touch certain things — largely moot. A sufficiently motivated agent will reason around them, find an indirect path, or reframe the task in a way that makes the restricted action seem justified.

This compounds with a structural problem on the human side: agents increasingly run with minimal oversight. Skip-permissions modes bypass approval prompts. Long-running background tasks accumulate hundreds of tool calls nobody reviewed. Users experiencing approval fatigue click through without reading. The result is an agent with broad local access, a disposition to find creative paths to its goals, and nobody watching closely.

Simon Willison coined the lethal trifecta as a framework for exactly this risk: private data access, exposure to untrusted content, and exfiltration capability. When all three are present, an attacker who can inject instructions into the agent’s context has essentially won. It has become a widely accepted shorthand for why agentic deployments require a different security posture than traditional software.

3. Existing tools

Network honeypots have been around since the early 2000s. The idea is unchanged across thirty years: deploy something that looks real but has no legitimate use, and alert on any interaction. A low-interaction honeypot like Honeyd emulates network services; a high-interaction one like Cowrie runs a full fake SSH daemon. Either way, any connection is anomalous by definition — legitimate users don’t hit the honeypot.

Canarytokens applied this to credentials and files rather than network services. You generate a fake AWS access key or a Word document with a beacon embedded; when someone uses the key or opens the document, you get an alert. The AWS canary creates a real IAM user and monitors CloudTrail — there’s a lag of minutes, and it requires external AWS infrastructure.

Snare is a newer honeypot built specifically for the AI agent threat model, with a few meaningful differences from Canarytokens. It covers 18 credential types in one shot — including AI-native ones like OpenAI, Anthropic, and MCP server configs that Canarytokens doesn’t have — placing canaries in all the standard locations an agent would probe. The AWS canary fires at credential-resolution time via a local shell hook, before any API call is made, which is faster and doesn’t require external AWS infrastructure. Alerts include the SDK user agent and ASN, with a “Likely AI agent” flag when the request originates from cloud infrastructure — context that Canarytokens doesn’t surface.

The conceptual lineage runs from Honeyd to Canarytokens to Snare with the same core insight at each step: if you can define what legitimate access looks like, anything outside that definition is a signal.

4. Limitations

It detects, it doesn’t prevent. The agent already misbehaved by the time you get the alert. These are detection controls, not prevention controls. Knowing an agent touched a credential is useful — it’s not the same as stopping it. That said, detection data has value beyond the alert itself: observing what agents actually reach for in practice — even legitimate ones — tells you where the real access boundaries need to be. That’s useful input for building guardrails, scoping permissions, or writing policies grounded in observed behavior rather than guesswork.

Placement is manual. Canaries live where tools naturally look for credentials. If an agent is directed to a custom config path or a non-standard environment variable, the canary won’t be there. Coverage is bounded by where you planted the wires — the same fundamental limitation as any tripwire-based detection.

Detection confidence varies. Precision depends on the canary design and how deeply it hooks into the agent’s execution environment. Not all credential access paths are equally observable.

Shared machines. The low false-positive guarantee relies on the canary being invisible to legitimate users. On a machine shared by multiple developers, someone may stumble across a planted credential and use it for a real task — generating an alert that has nothing to do with a misbehaving agent. Dedicated agent environments sidestep this; shared workstations require more care.

Conclusion

The IDS-era idea is simple: legitimate users only access resources they have business accessing — so any interaction with a decoy is a signal by definition. What’s new is the target — an agent running under your own account, following instructions that arrived via a file you never meant to treat as executable, in a world where the line between “following instructions” and “going rogue” is invisible to a monitoring system that only observes API calls.

The tools are already there. Snare in particular caught my attention — built specifically for the AI agent threat model, it covers the credential surface an agent would probe and fires faster than any CloudTrail-based approach. An old technique that still holds up in the agentic age.

References

• LLM01:2025 Prompt Injection — OWASP Top 10 for LLM Applications
• Agentic Misalignment: How LLMs Could Be Insider Threats — Anthropic
• The lethal trifecta for AI agents — Simon Willison
• Snare — honeypot canaries for AI agents