Attackers Use Agentic AI to Scan GitHub Secrets and Breach Cloud Environments

What changed

Researchers describe threat actors using agentic offensive frameworks such as AntiFox and ARTEX to automate tasks that previously required skilled, hands-on operators. That includes scanning public code repositories for secrets, validating credentials, enumerating cloud resources, exploiting exposed services, and attempting data exfiltration.

The practical difference is workflow automation. Instead of a human moving step by step through discovery, validation, exploitation, and pivoting, the agent can take a goal in plain language and continue the chain on its own.

One reported case is especially stark: an attack path moved from scanning GitHub for exposed credentials to exfiltrating data from Azure Key Vault in as little as five minutes.

AntiFox and ARTEX are not just scanners

These frameworks are positioned more like autonomous operators than single-purpose tools. Based on the available reporting, they can combine multiple attack functions in sequence:

• Search public repositories for exposed credentials and API keys
• Validate whether those credentials still work
• Enumerate cloud services and permissions
• Access storage and secrets services
• Exploit web applications and deploy web shells
• Continue adjusting tactics based on results

That matters because each individual step is familiar to defenders. What is new is the speed and continuity between them.

Historically, tools such as Metasploit or Netcat still depended on an operator who understood the environment and interpreted results. With agentic systems, more of that interpretation appears to be built into the workflow.

What researchers observed in the wild

The reporting points to two attack patterns worth watching closely.

First, researchers observed AntiFox-linked activity against web applications and associated AWS environments. In some cases, attackers reportedly used valid IAM users and even assumed EC2 roles to validate credentials and enumerate services. Not every call succeeded, but the failed requests did not stop the workflow. Successful requests were mixed into the same sequence, eventually leading to secret access.

Second, a separate line of research described attackers using agentic tooling to scan public GitHub repositories for exposed secrets across applications and cloud services. From there, the system could analyze results and launch follow-on actions without much manual intervention.

This is an important operational detail. Attackers do not need every permission to be available at the start. They only need enough access to keep probing, adapt, and find the one path that works.

Why GitHub secrets are becoming a faster path to cloud compromise

Public repositories have long been a source of accidental exposure: hard-coded API keys, connection strings, cloud credentials, service tokens, and configuration files copied into commits. That is not new.

What appears to be changing is the economics of exploiting those mistakes.

An agent can scan many repositories faster than a human, sort useful from useless credentials, test which ones are live, and then immediately attempt cloud access. If a token opens an S3 bucket, an IAM path, or a secrets manager, the tool does not need to stop and wait for instructions.

For security teams, that means the window between exposure and abuse may be shrinking sharply.

The cloud angle: AWS and Azure are both in scope

The incidents described span multiple cloud environments, which is a reminder that the underlying problem is not tied to one vendor. Exposed credentials, over-permissioned identities, accessible metadata, weak secret hygiene, and publicly reachable app infrastructure can all become entry points.

In the AWS-related observations, attackers reportedly performed actions involving IAM validation, service enumeration, and access to secrets and storage. In other examples, valid credentials were used to interact with S3 objects.

On the Azure side, the notable detail is the speed at which exposed secrets could reportedly lead to Key Vault data exfiltration. The cloud provider is not the story by itself. The story is the agent’s ability to connect exposed developer artifacts to high-value cloud targets very quickly.

Autonomy has limits, but that should not reassure defenders too much

One useful nuance in the reporting is that autonomous attack systems are not perfect. Researchers noted that some campaigns made mistakes, misread results, or failed to produce the attacker’s intended payoff.

That is worth keeping in mind. Agentic AI does not make every attacker effective.

But imperfect automation can still be dangerous when it is cheap, fast, and persistent. Defenders do not need the agent to be brilliant for it to cause damage. They only need it to find one valid secret, one over-privileged role, or one exposed service before detection and response catch up.

What this means for defenders right now

The immediate lesson is that secret exposure should be treated as an active intrusion risk, not a passive hygiene issue.

A practical response starts with shortening the time between exposure, detection, and revocation. If attackers can move from public code to cloud secrets in minutes, cleanup processes measured in hours or days are too slow.

Teams should revisit a few areas first:

• Secret scanning across source code, commits, logs, and configuration files
• Removal of long-lived credentials from application code and repositories
• Least-privilege IAM design for users, roles, and workloads
• Tighter controls around secrets managers and key vaults
• Monitoring for unusual credential validation, enumeration, and object access
• Hardening of web apps and cloud-connected servers that can expose config files or metadata

This is also a case for reducing credential usefulness. Even if a secret leaks, its blast radius should be small, its privileges limited, and its lifetime short.

Related governance concerns also appear in AI Governance for Agencies: 4 Security Priorities.

Why this matters beyond security teams

For founders, operators, and AI adopters, this is another example of AI changing the cost curve of a task. In this case, the task is intrusion.

The broader implication is straightforward: any workflow that can be decomposed into repeatable steps is a candidate for agentic automation, including offensive security work. That does not mean every AI security tool is equally capable or every attack is fully autonomous. It does mean the distance between “exposed secret” and “real breach” may continue to shrink.

The useful takeaway

If your organization publishes code, runs cloud workloads, or stores production secrets in connected environments, assume that exposed credentials can now be discovered and acted on at machine speed.

The smartest near-term move is not to debate whether agentic attacks are overhyped. It is to reduce the number of secrets that can be found, reduce what they can do, and reduce how long they remain valid when they leak.