They deleted the leaked secret. The attacker used it anyway.

Tom Elias — Wed, 30 Sep 2026 18:16:36 +0000

The Anatomy of Non-Human & Agent Access Drift in 2026

Most access reviews still start with a list of people. In 2026 that list covers the smallest part of the problem.

Every CI pipeline, service principal, API key, and AI agent is an identity with access to something. Unlike people, they don't leave the company, they don't get offboarded, and nobody notices when what they can reach quietly grows. That growth is access drift, and two incidents from the last week of September show exactly what it looks like.

Case 1: A secret that outlived its deletion

On 25 September Microsoft described an actor it tracks as Storm-3168 (also called JADEPUFFER). The attacker used two compromised Azure service principals. One spent about 15.5 hours on reconnaissance. The other made more than 100 attempts to delete storage accounts in about seven minutes, then pulled keys.

The likely entry point wasn't an exploit. It was a secret posted in a public GitHub issue. Someone deleted the text, but it stayed in the issue's edit history, and it was never revoked.

That's the first kind of drift: an identity whose credential nobody considers live anymore, but which still is. It has delete rights, and no human owns it.

Case 2: A client that trusts the wrong server

On 28 September, GHSA-qx49-fqc8-xw99 was published for the official MCP Python SDK, based on research by Cycode. A malicious MCP server responds with a 404, the SDK falls back to a discovery path that never validates the issuer, and the client sends its client secret, authorization code, and PKCE verifier to the attacker.

It's fixed in 1.30.0 and 2.2.0. For the server-to-server auth providers, where no human is in the loop, you also have to pass issuer= explicitly. Upgrading alone isn't enough.

That's the second kind of drift: an agent's tooling changes, or trusts something new, without anyone re-approving it.

Case 3: The document that says none of this can happen

The third link isn't a CVE. It's the customer security questionnaire. "Do you review machine credentials?" "Do you control third-party integrations?" Those answers are often written from memory by someone who has never seen the service principal list or the MCP config.

Put the three together and you get a chain:

secret that should be dead
  → MCP client that hands secrets to whoever asks
  → agent with wide scopes that trusts both
  → production
  + a signed document saying it's all controlled

What drift looks like in config

Illustrative examples of the patterns involved, not from any real org.

A CI workflow with more power than it needs:

on: pull_request_target        # runs with repo secrets on external PRs
permissions: write-all         # every scope, not the one it needs

An MCP client config that grew over time:

{
  "mcpServers": {
    "filesystem": { "command": "mcp-fs", "args": ["/"] },
    "github":     { "command": "mcp-github", "env": { "GITHUB_TOKEN": "ghp_..." } },
    "installer":  { "command": "npx", "args": ["-y", "quickstart-mcp"] }
  }
}

Three problems in eight lines: filesystem access rooted at /, a token pasted inline, and an unpinned package that runs whatever version is published today.

Checking it locally

I released three small Go CLIs that check each link. They're read-only, run offline against local files, and send no telemetry. The repo ships with testdata so you can see what they report before pointing them at your own config.

git clone https://github.com/tomelias10/orynval-labs.git
cd orynval-labs
make build

nhi-ghost looks for over-privileged, secret-bearing, or stale machine identities:

./bin/nhi-ghost internal/nhi/testdata
# nhi-ghost 0.1.0
# 7 findings: 4 high, 1 medium, 1 low, 1 info

On the testdata it flags a write-all + pull_request_target workflow, committed secrets (masked as sk_l****), a wildcard IAM policy, and a disabled service account that's still present.

mcp-drift compares MCP client configs against an approved baseline (.orynval/mcp-baseline.json):

./bin/mcp-drift internal/mcp/testdata
# mcp-drift 0.1.0
# 7 findings: 2 high, 2 medium, 3 info

It flags the /-scoped filesystem server, the inline GITHUB_TOKEN (masked), a server whose definition hash no longer matches its approval, the unpinned npx -y installer, and an unapproved remote endpoint.

trust-proof answers a questionnaire only from evidence:

./bin/trust-proof \
  --questions internal/trustproof/testdata/questions.csv \
  --evidence  internal/trustproof/testdata/evidence
# trust-proof — DRAFT (human review required; no claims auto-certified)
# Questions: 5   Answered: 3   Gaps: 2   Coverage: 60%

Every answer cites a file and line. Two questions come back UNKNOWN because nothing in the evidence supports them. A token found inside an evidence file is masked as ghp_**** instead of being copied into the answer.

All three tools support terminal, JSON, and SARIF 2.1.0 output (--format json|sarif), so they drop into CI.

What to do this week

List every service principal and API key with write or delete rights, and give each one a named human owner.
Rotate any secret that has ever appeared in an issue, PR, or chat, even if it was deleted.
Upgrade the MCP Python SDK to 1.30.0 or 2.2.0, and set issuer= on server-to-server providers.
Pin MCP server versions and re-approve them when the definition changes.
Before signing the next questionnaire, make every "yes" point to a file.

The tools are v0.1.0 and open source under Apache-2.0: https://github.com/tomelias10/orynval-labs

If you need this validated across a full production environment, that's what we do at https://orynval.com.