All articles
agentic

Anatomy of an Autonomous Attack: How an AI Agent Chained 7 Vulnerabilities Without Human Intervention

Technical breakdown of an offensive AI-driven attack: recon, seven chained vulnerabilities, and final exploitation all without human intervention.

SentinelleChrisMay 21, 2026Updated May 23, 2026
3 min read3 reads
Anatomy of an Autonomous Attack: How an AI Agent Chained 7 Vulnerabilities Without Human Intervention

The cybersecurity industry talks about offensive AI agents like they are just another marketing buzzword. Here’s what that actually looks like, step by step, on a real target (a public bug bounty program I won’t name) where Sentinelle chained seven weaknesses into a single exploitation path without any human intervention between the initial scope and the final report.

Step 0 The Scope

The operator (me) submits a single line:

*.example-corp.com — public HackerOne program, scope defined by X.

Sentinelle verifies the scope through the program token (read-only access to the HackerOne API), confirms authorization, and starts. From this point on, I do not touch anything anymore.

Step 1 Reconnaissance That Sets Up Everything Else

Five minutes.

The agent enumerates 312 subdomains, fingerprints 28 distinct technology stacks, and identifies three exposed services that should never have been reachable in production:

  • a Grafana endpoint at /grafana-dev

  • an unauthenticated Elasticsearch instance behind a poorly segmented load balancer

  • a Jenkins instance with an accessible script console

None of these elements alone is critically dangerous. Their combination is.


Step 2 The First Leak

The agent notices that the Grafana instance is reachable but authenticated.

Instead of attempting brute force (which would have immediately triggered the rate limiter), it reads the exposed version directly from the HTML: 8.3.0.

It cross-references the version against its local CVE database and identifies CVE-2021-43798 the Grafana path traversal vulnerability allowing unauthenticated file reads through a vulnerable plugin.

HTTP 200.

The agent now has access to the system user list via /etc/passwd.


Step 3 The Information Pivot

Inside /etc/passwd, there is a user named jenkins-deploy.

The agent correlates that information with the Jenkins instance identified during Step 1.

It attempts to read the Jenkins configuration files using the same path traversal vulnerability. The configuration contains a Jenkins API token encrypted, but the master encryption key is stored in a neighboring file that the agent also retrieves (secret.key).

The token is decrypted locally.


Step 4 Jenkins Access

Using the token, the agent authenticates to Jenkins as jenkins-deploy.

It now has access to the Groovy script console.

System command execution confirmed.

At this stage, a human operator would usually stop and manually verify authorization boundaries. The agent does not hesitate. Its scope enforcement layer confirms that Jenkins belongs to the declared scope → continue.


Step 5 Quiet Lateral Movement

The agent does not deploy a reverse shell.

Too noisy. Unnecessary.

Instead, it extracts Jenkins process environment variables.

Bingo:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Both with deployment permissions.

Step 6 The Forgotten Elasticsearch

Using the AWS credentials, the agent enumerates S3 buckets.

It discovers:

example-corp-backups-prod

Readable.

Inside the bucket: daily Elasticsearch database dumps precisely the Elasticsearch instance identified during Step 1.

The agent downloads a sample, indexes it, and identifies the real impact:

  • 1.2 million customer records

  • emails

  • expired session tokens

  • metadata

This is the actual critical vulnerability.

  1. Not Grafana.

  2. Not Jenkins.

  3. The entire chain.

Step 7 The Report

Forty-two minutes after launch, Sentinelle generates an 18-page PDF report containing:

  • the complete attack chain, step by step

  • exact reproducible commands

  • evidence (HTTP responses truncated to avoid PII exposure)

  • combined CVSS scoring (9.1)

  • prioritized remediation guidance

I open the report, validate it, and submit it to HackerOne in under five minutes.

What Nobody Says About Offensive AI Agents

The power of this chain was not in any individual exploit every single step was already documented and publicly known.

The real strength was the reasoning between the steps.

The agent understood that the jenkins-deploy account extracted from /etc/passwd matched the Jenkins instance discovered 30 minutes earlier.

Traditional scanners never make that connection.

A human would.

But in forty-two hours, not forty-two minutes.

And somewhere along the way, fatigue would likely cause one of the seven links in the chain to be missed.

That is what agentic cybersecurity really is.

Not a buzzword.

A completely different class of problems that machines can now solve.

Did you enjoy this article?

Chris

Written by

Chris

Tech builder · Agentic AI & offensive security

A tech-obsessed builder, I'm building Sentinelle — an autonomous offensive-security AI agent. I write here about agentic AI, AI-assisted pentesting, and what I learn shipping offensive tooling.

Related articles