Run this AI agent permission audit to stop Unit 42-style breaches

Your agent can read the repo, call the API, and maybe rotate a token. Now ask what else it can touch.

An AI agent breach often starts with a small, boring permission: a token that can list a repo, a service account that can call an API, a notebook that can reach a database. Opening steps are easy. The following step is where the incident grows.

In the Unit 42 September 2, 2026 intrusion, AI agents completed the attack in under 10 hours, using more than 50 distinct techniques from MITRE ATT&CK, a catalog of attack methods.

A comparable manually run version of that intrusion would have taken roughly two weeks from first access to full network compromise.

The attacker entered the enterprise network through a compromised public API endpoint.

Secondary agents then mined enterprise code repositories for embedded tokens and service passwords.

Those tokens let the agents reach the victim's secrets-management platform and take master administrative credentials that gave root system access.

After the chain finished, the agents sent the victim an 80-page security audit listing dozens of exploited findings.

In the July 2026 JADEPUFFER incident, a single AI agent exploited a Langflow server missing patches and wiped a production database.

Credential sprawl is the attack path

Each step above needed a usable credential. A reachable endpoint gives a foothold. Repo access finds more tokens. Secrets-management access turns those tokens into broad control. The chain is a sequence of permissions that were already in place.

Hardcoded secrets are the quiet version of the same problem. They need a reader, not a new exploit. An agent that can read the repo can read the key. A key that can reach the vault makes the vault no longer a control.

Secrets management is supposed to be the boundary. It should decide which agent can read which key, for how long, and under what approval. An agent that can read the master key turns the boundary into a door with no lock.

The audit breaks the chain

Run this audit this week, and again after any change to an agent, its tools, or its credentials. The items are quick if your inventory is honest.

• Name every agent and subagent. An agent you cannot list with owner, purpose, and runtime is invisible.
• Check reachable systems. For each agent, list the repos, APIs, databases, CI/CD jobs, and SaaS apps it can call. Mark anything it can reach without approval.
• Scope credentials per agent. Tokens cover only the endpoints and actions the agent needs.
• Flag standing tokens. Tokens expire, do not sit in config files, and are not reused across environments.
• Search for hardcoded secrets. Repos, notebooks, scripts, and build artifacts contain no keys, passwords, or bearer tokens.
• Audit secrets-management access. No agent may read the vault, create keys, or grant admin rights.
• Test least privilege. Try to use each agent's credentials to reach a system outside its intended scope. Success means the scope is too wide.
• Record exceptions. Temporary broad access needs a reason and an expiry. An exception without a date is a standing token.

Keep the output short enough that someone will actually read it. A table with agent, owner, reach, credential, and expiry is enough. Put that table in the same place where the agent definitions live, so the next change to an agent forces a look at its reach.

Make the audit repeatable

Store the inventory where engineers can see it, not in a spreadsheet that dies in a shared drive. Tie each agent to a credential owner, a scope, and an expiry. A new agent should fail the audit until its owner, scope, and expiry are recorded. The audit then becomes part of the change process, not a once-a-year ritual.