The paper is careful about its status. It “creates no new obligations” and asks for comments by February 1, 2027. But it’s the most concrete regulatory document on AI agents I’ve read, for one reason: almost every section ends with a sentence starting “the practical test is whether.” Those sentences are audit tests. Read together, they’re an audit program for AI agents, and almost none of it is specific to banks.

One note on reading it: the paper uses “AI” to mean authorized institution, the HKMA’s term for a bank, and writes artificial intelligence as “A.I.”

Five practical tests

1. Can you name who answers for each agent?

Before an agent goes into production, the paper wants the bank to write down its “business intent”: what it’s for, what it can do, which data and tools it can touch, what data can leave the firm, its limits, and when its authority should be withdrawn.

Then one person owns it, and that person should normally come from the business, not technology. The paper is blunt that accountability “should not default to technology functions solely because agentic A.I. is involved.” Technology owns the build, the logs and the stop mechanism. A separate control owner, independent of the build, owns testing and challenge.

It also says an agent shouldn’t keep running if its owner or boundaries are unclear. That’s a stronger line than most companies hold today.

Test it: pick five agents in production and ask who owns each one. If the answer is the engineer who built it, or “the platform team,” the business has handed its decision to the people who wrote the code.

2. Do its actual capabilities still match what was approved?

The paper’s answer to prompt injection and scope creep is that prompts are not controls. Critical controls “should not depend solely on a model’s ability to interpret and follow instructions.” Instead it describes a harness: tools, permissions, data access and limits defined in advance, enforced technically, version-controlled and changed only through change management.

The key line for auditors: an agent should not be able to extend its own authority, acquire new tools, create credentials or modify its own controls at runtime. High-impact actions get deterministic checks, ordinary code that verifies the action is within limits and going to an authorized recipient. If a check fails, the action stops or goes to a person. It isn’t left to the agent to sort out.

Test it: for one agent, compare the tools and permissions it was approved for with what its credentials can actually do today. That’s an access review, and the gap between the two lists is the finding. I built agent-access-review to do this for MCP servers, and the gap is rarely zero.

3. Is the human approval real?

This is my favorite section. “A formal approval step is not, by itself, meaningful human oversight.” Approval only counts if the approver sees the substance of the action, has the authority and time to reject it, and treats rejection as a legitimate outcome. If agents act faster or in greater volume than a person can meaningfully review, the bank shouldn’t count the approval step as a control at all.

That describes most approval prompts I’ve seen in agent tooling: a button clicked hundreds of times a day.

Test it: pull the approval log for one agent. Count approvals per reviewer per day, the median time to approve, and how many were rejected. A rejection rate of zero with a median of four seconds isn’t oversight.

4. Can you actually stop it?

Every governance framework mentions a kill switch. This paper asks whether it works. Testing should cover whether the stop takes effect fast enough, what happens to actions already in flight, and whether the business can keep running on the fallback. It should also work “regardless of the status of a vendor.”

The practical test is the strongest sentence in the paper: if a bank cannot stop or constrain an agent “without unacceptable disruption, the principle is not met in substance.”

Test it: ask when the stop mechanism was last exercised in production, how long it took, and who decided. If it has never been run, it is a design document, not a control.

5. Can you explain any action it took?

“When software acts, the log replaces the memory and signature of a human actor.” So the paper wants every deployment recorded before production: owners, capabilities, data leaving the firm, dependencies, stop mechanism, log locations, change and suspension history.

Two details I hadn’t seen in a regulator’s text before. Each agent should have its own identity and credentials, because shared or borrowed accounts break the link between an action and the authority behind it. That’s the failure in the bank agents story last week, where agents logged in with customers’ passwords. And when an agent is retired, its record should be closed properly, because “casually decommissioned deployments may leave active credentials” and access behind.

Test it: pick one action an agent took last month and trace it: which agent, which credential, which instruction, which person’s authority, which approval. Then pick one agent that was switched off and check whether its credentials still work.

Five incidents worth reporting

The paper also asks whether these should ordinarily count as incidents under existing reporting rules:

1. The agent acts beyond its authority.
2. The stop mechanism or the fallback fails when it’s needed.
3. The agent’s identity or credentials are compromised.
4. A monitoring agent is found to have failed silently.
5. An approval gate lets an action through that it shouldn’t have.

Most incident policies I’ve read wouldn’t classify any of these, because nothing was breached and no data was lost. Number 3 isn’t hypothetical either: last month’s run of AI platform breaches was largely about stolen credentials that agents and applications use.

Test it: take that list to your incident classification policy. For each item, would it be logged, triaged and reported, or would it be closed as a bug?

Why this matters outside Hong Kong

Hong Kong is not the only regulator thinking about this. The UK ICO’s call for evidence on agentic AI closes November 20, and NIST has an AI agent standards initiative under way. But this paper goes further than anything I’ve seen in turning principles into checks, and the checks work in any company that lets software act on its behalf.

If you run AI agents in production, you don’t need to wait for a rule. Run the five tests above against your most important agent this month.

What I haven’t covered

This is a summary of a 57-page paper that is explicitly preliminary. I’ve left out its sections on customer-facing agents, the proposed notification and registry arrangements for material deployments, and “Know Your Agent” checks for agents arriving from outside the bank, each of which deserves its own post. Read the paper itself before relying on anything here.

Sources: HKMA discussion paper (PDF) · HKMA press release · Caixin Global.

Northflank was the ninth. Wiz’s write-up, Black October for AI Developer Platforms, counts nine breaches of platforms that developers use to build and run AI applications, all in one month. Wiz is clear that “no single vulnerability or dependency” links them. The pattern is in what the attackers wanted: stored environment variables, especially the ones that grant access to AI models.

The month, in one table

From Wiz’s summary, with each company’s own description of the cause where it gave one:

This isn’t one bug to patch. It’s a category of vendor, the platform that holds your secrets so your code can run, being worked through one at a time.

What happens to a stolen AI key

Wiz traced two enterprise keys that were stolen in these breaches and then abused on Amazon Bedrock:

• In both cases, the first model call came within 30 minutes of the reported credential access.
• Case A: about 800,000 calls over roughly 30 hours; three quarters of the successful calls went to Opus models. The key’s policy allowed global cross-region inference, and Wiz says only about 6% of calls were throttled.
• Case B: about 1.7 million calls over 13 hours from a single address. This key was limited to US inference profiles, so calls outside that were throttled.
• Together, Wiz estimates they “likely ran up over $100k in usage” at list price.

Wiz also linked the key testing to services that resell access to AI models. A stolen AI key is easy to turn into money, which is why these keys were the target.

Four controls on your side of the breach

You can’t stop your hosting provider being breached. You can decide what it was holding, how long it stays useful, and how quickly you notice.

1. Know which vendors hold your keys

Most of these platforms are adopted the same way: a developer signs up with a company card, connects the repo, and pastes production keys into the environment settings. The vendor never goes through procurement, so it never appears in the vendor inventory, and nobody receives the breach notice.

Test it: pick your three most-used AI provider keys (Anthropic, OpenAI, Bedrock or whichever you use). For each one, list every place it is stored. Then check how many of those places are in your vendor inventory. If you can’t answer the first question, the second one doesn’t matter yet.

2. Limit what a stolen key can do

The two Bedrock cases are the clearest lesson in the report. The same kind of key, stolen the same way, but the one with the broader policy let the attacker spread across regions with little throttling.

Least privilege applies to AI keys like any other credential: restrict the models, the regions and the spend, and give each platform its own key rather than one shared key everywhere. Better still, use short-lived credentials through workload identity federation where the platform supports it, so there is no long-lived secret for a breach to take.

Test it: for each AI key stored on a third-party platform, write down which models and regions it can use, and what its spending limit is. A key with no limits is a blank check held by your vendor.

3. Detect use, not just disclosure

Thirty minutes from theft to first use means the vendor’s status page is not your alert. Northflank’s first instruction to rotate came about two hours after Wiz’s alert, and that was a fast response.

The signal you control is usage: model calls from new addresses, a jump in volume, calls to models your application never uses. For most teams the first place that shows up is the bill.

Test it: if one of your AI keys made 800,000 calls overnight, who would be told, and when? If the answer is “finance, at month end,” make spend and usage alerts a security control with an owner, not a billing setting.

4. Rotation is the control you’ll need, so practice it

Every platform in the table gave the same advice: rotate everything. Northflank had to ship rotation for its own database add-ons, one type at a time, over two days.

This is the same lesson as the LiteLLM key and last week’s extension backdoor. The incident is a rotation exercise, run under pressure, with whatever process you already have.

Test it: time a full rotation of the secrets on one platform: revoke at the provider, issue new ones, update the workloads, confirm the old ones fail. If it takes days, that’s how long a stolen key keeps working.

What to ask these vendors

For any platform that stores secrets for you:

1. Who and what can decrypt our environment variables, and where are the keys held?
2. Can we reference secrets from our own secret manager, or use short-lived federated credentials, instead of storing them with you?
3. Do you offer audit logs of secret access? (Northflank turned them on for all customers after the breach.)
4. How fast will you tell us, and will you tell us which of our secrets were exposed?

What I haven’t verified

Wiz’s list relies on each company’s public statements, and several causes are still preliminary. Northflank hasn’t published a root cause yet; its latest update, on November 2, says it believes the attack was contained within an hour, that running workloads weren’t accessed, and that a root cause analysis will follow. I haven’t seen any of the investigations directly.

Sources: Wiz, Black October for AI Developer Platforms · Northflank status page · BleepingComputer.

On October 29, from about 2:27am to 1:35pm Pacific time, Cursor’s VS Code extension marketplace served a maliciously modified build of the Claude Code extension, version 2.1.313. Cursor’s security notice says the build “was not developed by Anthropic” and that at most 5,000 users were affected. Version 2.1.314 is clean.

What the build did

From Cursor’s notice and StepSecurity’s analysis:

The impact was probably smaller than that list suggests. Turning on the SSH service needs admin rights, which the extension usually didn’t have, so the tunnel usually failed. The attacker’s server is now offline. But the key was still added and the persistence still installed, and Cursor says plainly that “uninstalling the extension may not be sufficient.”

Nothing here is new technique. What makes it worth an auditor’s time is where it landed: the machine where your engineers hold their cloud credentials, Git tokens and production access.

Four control questions, and the test for each

1. Could you name the laptops that installed it?

Cursor’s first instruction is to find everyone who installed or updated to 2.1.313 during the window. That should be a five-minute query. In most companies I’ve looked at, it’s a Slack message asking people to check.

Asset inventories usually stop at the device. They know the laptop exists and which OS it runs. They rarely know which editor extensions are installed, at which version, which is exactly what an incident like this needs.

Test it: pick one extension your developers use, and ask how long it takes to produce a list of every machine running a specific version of it. If the answer involves asking people, extensions aren’t in your software inventory, and an AI coding extension runs with the same rights as the developer.

2. Updates arrive faster than anyone can review them

Editors built on VS Code update extensions automatically in most setups. The bad build was live for about eleven hours. Anyone whose editor checked for updates in that window got it without doing anything.

You can’t review every extension update, and you shouldn’t try. The cheaper control is time. Package managers already support a minimum release age (pnpm and Renovate both have one): don’t install a version until it has been public for a set period. Most malicious releases are caught and pulled within a day or two. A 48-hour rule would have skipped this build entirely, and the LiteLLM wheels too, which were live for about two hours.

VS Code also has an allowlist setting, extensions.allowed, that can restrict which extensions and versions are installed. Check whether your editors honor it before relying on it.

Test it: for your developer tooling (extensions, package managers, CLI plugins), write down who decides when an update is installed. If the answer is “the publisher, automatically,” you have outsourced change management to whoever controls the publisher’s account.

3. Do you know what to rotate?

Cursor’s notice says to rotate “credentials and sessions accessible from affected hosts,” and warns that the limited collection “does not rule out later credential access over the backdoor.”

That instruction assumes you know which credentials are on a developer’s laptop. Usually nobody does: long-lived cloud keys in ~/.aws/credentials, a GitHub token in the CLI config, .env files in a dozen old project folders, a database password in shell history.

The recon step only collected variable names. That’s a target list for a second visit.

Test it: pick one developer laptop and list every credential on it that grants access to something real. Then check how many are long-lived. Every long-lived credential on that list is something you’d have to rotate by hand after an incident like this one, and something that keeps working if you miss it.

4. Uninstalling isn’t remediation

Removing the extension leaves the SSH key, the scheduled task and the LaunchAgent in place. A ticket that closes when the bad version is gone has closed the wrong thing. This is the same gap as a leaked secret that is deleted from the repo but never revoked.

The persistence was also built to blend in. SysMon and com.apple.sysmond look like system components at a glance, and svc-telemetry looks like a service account.

Test it: does your endpoint tooling alert on a new entry in authorized_keys on a laptop, a new scheduled task running as SYSTEM, or a new LaunchAgent? Developer machines are often given looser rules because developers install things all day. Check whether that exception covers exactly these events.

What to ask your vendors

If your developers use an AI-enabled editor, add these to the vendor review:

1. How does the marketplace verify that a package matches what the named publisher actually built?
2. If a publisher’s account is compromised, what stops a new version reaching every user within the hour?
3. Can we control which versions are installed, and delay updates by a set period?
4. How quickly will you tell us which of our users installed a bad version?

What I haven’t verified

The details above come from Cursor’s notice and StepSecurity’s analysis. Neither says how the modified package got into the marketplace, and they describe the channel differently: Cursor’s notice is about its own marketplace, while StepSecurity says the build was also published to Open VSX, under the legitimate Anthropic namespace. I haven’t seen the package or the logs, and the account may change as the investigation goes on.

If you or your team installed Claude Code from Cursor’s marketplace on October 29, follow Cursor’s notice first. It has the indicators and the cleanup scripts.

Sources: Cursor security notice · StepSecurity · Help Net Security · Cursor on X.

On October 23 LiteLLM published the full attack chain, and the log theory was wrong. The real story is simpler, and more useful for anyone who runs or audits controls. Every step is an ordinary control that existed on paper.

What actually happened

All from LiteLLM’s post; times are UTC.

Four control failures, and the test for each

1. A leaked secret was deleted, not revoked

Rewriting git history removes a commit from the branch. It does nothing about copies that were already made, and it doesn’t make the key stop working. The key stayed valid for 136 days.

This is the most common gap I see in secrets handling: the ticket closes when the secret disappears from the repo, because that’s what the scanner checks.

Test it: pull your last ten secret-scanning alerts marked resolved. For each one, is there evidence the credential was revoked, such as a rotation record or the old key returning 401? “Removed from code” is not remediation.

2. An AI agent ran on an org owner’s personal token

The token in the agent’s config was, in LiteLLM’s words, “not associated with a service account and was not scoped down.” It belonged to one of the two people with the most power in the GitHub organization. And the platform’s API returned it in full to anyone holding the master key.

I wrote on Monday that an agent using your password is you as far as every control can tell. This is the same failure inside a software company. LiteLLM also notes that these CLI tokens skip GitHub’s re-authentication prompt for sensitive actions, so the strongest account was protected by the weakest credential type.

Test it: list every token your AI agents, MCP servers and automation hold. Which ones belong to a named person, and which of those people are admins or owners? Any agent config API that returns secrets in plain text is a finding on its own.

3. A control was relaxed to ship faster, and nobody owned the risk

Releases used to need approval from “a special account locked to a physical device in our office.” That was relaxed “earlier this week” to allow faster releases: any two engineers could trigger and approve.

Two-person approval only works if the two credentials can’t be stolen together. A device-locked approver can’t be replayed from a stolen token; two engineers’ CLI tokens can. Weakening the control turned a two-person rule into a two-token rule, and the attacker already had three tokens.

The decision to relax it was reasonable. The gap is that it wasn’t treated as what it was: a risk acceptance. That is the same pattern as yesterday’s post on compensating controls. A temporary change to a control needs an owner, an expiry date and something that compensates while it’s in place.

Test it: ask when your release approval, branch protection or MFA settings last changed, who approved the change, and when it is due to be reversed. If the answer comes from the audit log instead of a change record, that’s the finding.

4. Eleven days inside, with the evidence deleted

The attacker was in on October 10 and released on October 21. The exfiltration workflows ran from throwaway branches and were deleted in under three minutes. On release day, branch protection was overridden and the run records were deleted.

Every one of those actions shows up in GitHub’s audit log: a workflow run deleted, branch protection bypassed by an owner, a new branch pushed and removed. They’re rare events, and each one was a chance to notice.

Test it: do you alert on branch-protection bypasses, deleted workflow runs, and organization-owner tokens used from a new IP? If those events only exist in a log nobody reads, the control is evidence after the fact, not detection.

What to ask your vendors

LiteLLM reports holding SOC 2 Type 2 and ISO 27001. I’m not suggesting the audits were wrong; I haven’t seen the reports, and an audit covers a period and a scope. The point is that none of the four failures above would show up unless someone asked about them directly. For any vendor in your AI supply chain, add these to the questionnaire:

1. When a secret is exposed, what evidence shows it was revoked, not just removed?
2. Do automated agents or pipelines ever run on a named person’s credentials?
3. Is release approval bound to something that can’t be replayed, like a hardware key?
4. How are temporary relaxations of security controls approved and tracked?

What I haven’t verified

Everything above comes from LiteLLM’s own account, and it says the process changes will be published separately. I haven’t seen the audit logs or the agent platform. LiteLLM corrected its own first account, and details may change again.

Credit to LiteLLM for publishing the attack chain in this much detail, including the parts where its first theory was wrong. Most companies never publish that.

Sources: LiteLLM, The attack chain behind the v1.107.0 release · The Hacker News · Wiz.

What the week looked like

A quick recap, all from the sources in the earlier post:

• Oct 17: Amazon’s honeypots saw PHP2Shell exploitation, four days before public disclosure.
• Oct 21: details leaked and PHP shipped fixed releases the same day (Wiz).
• Oct 21–22: the FBI advised taking sites that couldn’t be patched offline, and some government sites in the UK, Finland and Japan went partly offline (Recorded Future).
• Oct 22: Palo Alto said every PAN-OS version was affected with no fix yet, and Fortinet and Cisco had dozens of products under investigation (Help Net Security).

Two things in that list can’t be fixed by patching faster. Exploitation started before anyone could patch, and for some appliances there was nothing to patch with.

Decision 1: who can take it offline

When the FBI says “take it offline,” someone has to decide that for each system. In most companies that person isn’t written down anywhere.

An outage runbook usually covers the service breaking. It rarely covers choosing to break it yourself. So the call gets made in a meeting, under pressure, by whoever is senior enough and awake. Then comes a second round of delay: legal, comms and the business owner each find out separately.

Write it down per system before you need it:

• Who can approve taking it offline. One name, plus a deputy, both reachable out of hours.
• Who must be told. The business owner, the customer-facing teams, and legal if contracts have uptime terms.
• What customers hear. A pre-approved holding message, so comms isn’t drafting from scratch at 2 a.m.
• The longest acceptable outage. If it’s two hours, you already know an all-day shutdown needs a different answer.

This is a risk-acceptance decision made in advance, which is exactly what GRC teams are meant to own.

Decision 2: which vendors embed the runtime

“Patch PHP” assumes you own the PHP. On a firewall, VPN or appliance, the vendor owns it and you wait.

What you can control is how fast you ask. Keep a list of which vendor products embed common runtimes and libraries: PHP, OpenSSL, log4j, glibc. Your SBOM requests and vendor questionnaires should already hold most of this. When the advisory lands, the email to each affected vendor goes out the same day, asking whether they’re affected, when a fix is coming, and what mitigation to use until then.

A vendor that can’t answer within a day is telling you something too. Record it in your third-party risk file, because next renewal is the time to raise it.

Decision 3: the clock starts at disclosure

Most patch SLAs start counting when a patch is available. PHP2Shell shows why that’s the wrong starting point. For PAN-OS there was no patch, so the clock never started, while attackers were already working.

Start the clock at disclosure. The first deadline isn’t “patched.” It’s “a compensating control in place within hours.” That could be a WAF rule, restricting access to the management interface, or taking the service offline (see decision 1). Each compensating control needs three things:

• An owner, so someone is accountable for removing it.
• An expiry, so a temporary rule doesn’t quietly become permanent.
• Proof it works. Send a safe test request and confirm it’s blocked. An untested WAF rule is a guess.

Then look back. Amazon saw exploitation four days before disclosure. Patching on day one doesn’t tell you whether someone got in on day minus four. Search your logs from before the disclosure date, not just after.

A one-row template

Copy this per internet-facing system. It takes about ten minutes each and makes the next bad week shorter.

What I haven’t tested

This is a proposal, not a measured result. I haven’t run this template through a real incident, and the right maximum outage and approvers will differ by company. The FBI advice and government shutdowns are as reported by Recorded Future; I haven’t independently confirmed which sites went offline or for how long.

Thanks to the readers whose comments on the last post shaped this one.

According to Reuters, Axios and the Financial Times, Morgan Stanley is blocking outside AI agents from its platforms. JPMorgan Chase, Bank of America and Citi are restricting them. Wells Fargo has rewritten its online access agreement. Charles Schwab is blocking agents that try to move client money. The reports describe agents logging into customer accounts with the customer’s own username and password, and some that, per Axios, “attempted to take actions that appeared to be independent of user instructions.”

It’s being covered as a story about banks resisting AI. I think it’s something more useful: the first large-scale access review of AI agents, run by the institutions with the most to lose. What they found applies to every company that lets an agent act on someone’s behalf, including yours.

What happened

The quotes are telling. Jamie Dimon said JPMorgan would limit agents “because you don’t want rogue agents and there could be thousands of them.” Brian Moynihan of Bank of America said there “should be a human in the loop to authorise money moving out of your account.” Schwab’s Rick Wurster said: “We are blocking it because we want to have control over authentication and the experience.”

Two caveats before going further. Much of the reporting relies on anonymous sources, and none of it establishes widespread unauthorized transfers or customer losses. This is the industry reacting to a risk, not cleaning up after a disaster. Also, the banks have commercial reasons too: the FT reported a fear that agents will move idle deposits to higher-yielding accounts. Both things can be true.

Why this one matters

An agent with your password is you

Every control a bank runs downstream of login assumes one thing: the identity that authenticated is the person who acted. Fraud models are trained on that person’s behavior. Audit logs record that person’s ID. Consumer protection rules hinge on whether that person authorized the transaction.

When a customer gives an agent their username and password, all of that collapses. The bank sees the customer. The logs record the customer. And as Reuters put it, such transactions “cannot be deemed unauthorized if credentials were shared by the customer.”

In audit terms, this is a loss of attribution, and attribution is the foundation of accountability. If you can’t tell who acted, you can’t tell whether they were allowed to, you can’t investigate when something goes wrong, and you can’t assign responsibility. It’s the same reason companies ban shared admin accounts. A shared password between a person and their agent is a shared account.

“Authorized” isn’t “intended”

The most consequential detail in the coverage got the least attention. USA Today reported that Wells Fargo’s updated agreement treats transactions made by a customer’s authorized agents as authorized, including ones “you did not want or intend,” until the customer notifies the bank and it has had a reasonable chance to act. Customers are described as solely responsible for supervising their agents.

That’s a rational move for a bank, and a clear signal of where liability is heading. For decades, “authorized” meant “the customer did it or told someone to.” Agents split that in two. The customer authorized the agent. Did they authorize this action? Probably not, if the agent “appeared to act independently of user instructions.”

Every company deploying agents will face the same split, and most haven’t written down where they stand. The banks have just shown what the default answer will be if you don’t: whoever granted the access owns the outcome.

The banks landed on least privilege

Strip away the AI and look at what the banks are converging on: read-only access for agents, and a human approval for anything that moves money. Citi already offers read-only access through approved open-banking providers. Moynihan wants a human in the loop on payments.

That’s not a new idea. It’s least privilege and segregation of duties, the two oldest controls in access management. The agent can see; a human must authorize. The agent proposes; a different identity approves. The banks didn’t need a new framework for AI. They needed to apply the old one to a new kind of identity.

What would have helped, ranked by cost

For anyone letting agents act on behalf of people (including inside your company):

1. Never let an agent use a human’s credentials. If an agent needs access, it gets its own identity, with a token that’s scoped, expiring and revocable. Open banking already works this way: delegated, read-only tokens instead of passwords. That’s what makes Citi’s middle ground possible.
2. Make agent actions distinguishable in the logs. Every action should record both the agent and the human it acts for. Without that, an investigation can’t tell “the user did this” from “the user’s agent did this.”
3. Split read from act. Give agents read access by default. Actions that move money, delete data, send messages or change access need a separate grant, and usually a human approval.
4. Write down who owns an agent’s mistakes. Before an incident, not after. Wells Fargo did; most internal AI programs haven’t.

For companies offering an API or platform that agents will use:

1. Offer a sanctioned path, or people will use the unsanctioned one. Customers gave agents their passwords because there was no better option. Blocking alone pushes agents toward screen-scraping and credential sharing, which is harder to see.
2. Authenticate the human for high-risk steps with something an agent can’t replay. Ping Identity’s Andre Durand told USA Today that email one-time passwords are no longer enough, because agents often have access to email. Passkeys and biometrics bind the approval to a person.
3. Detect agents, not just attackers. JPMorgan says it is building tools to tell agents apart from customers. Behavioral signals like timing, navigation and request patterns differ between people and software, even with the same password.

Now look inside your own company

The banks’ problem is visible because it involves money. The same pattern is already inside most companies, just quieter.

An engineer gives a coding agent their personal access token. An analyst connects an assistant to their mailbox with their own session. An MCP server runs with a developer’s cloud credentials. In every case, the agent is acting under a human’s identity, and the logs, the access reviews and the incident response all see a human.

Ask the same questions the banks just asked:

• Inventory: Which agents are running in our environment, and whose credentials are they using?
• Attribution: If an agent took an action today, would our logs show it was the agent?
• Scope: Do agents have read-only access by default, with a separate, approved grant to act?
• Approval: Which agent actions require a human, and is that enforced technically or just written in a policy?
• Ownership: Who is accountable when an agent does something nobody intended?

This is exactly the review I built agent-access-review to run: a user access review for AI agents and MCP servers, checking who owns each agent, what it can reach, whether it can act or only read, and whether anyone approved it. When I ran it against the official MCP README examples, 7 of 9 granted write, send, delete or execute permissions, and nothing in a copied config records who owns the agent or who approved that access.

What this means for AI governance

AI governance conversations tend to focus on what models say. The banks’ reaction is a reminder that the bigger risk is what agents do, and that the controls for that risk already exist. They were built for people, and they work only when the system knows which identity is acting.

Three principles fall out of this week:

1. AI agents are identities. Give them their own credentials, review their access like any privileged user’s, and never let them borrow a human’s.
2. Authorization needs two parts now. The human authorized the agent. Something still has to authorize the action, and for anything consequential that something should be a human.
3. If you don’t decide who’s liable, your terms of service will. Wells Fargo’s agreement is a preview of how accountability will be allocated by default.

The banks didn’t ban AI. They did what any good access review does: they found accounts they couldn’t attribute, access nobody had scoped, and actions nobody had approved, and they turned it off until they could. Every company with agents should run the same review before an incident runs it for them.

Sources: Reuters via Hawaii Tribune-Herald · Axios via Decrypt · Financial Times via Retail Banker International · USA Today · IBTimes UK. Much of the reporting relies on anonymous sources, and none of it establishes customer losses. The CISO figure is from a 2026 Palo Alto Networks study cited by USA Today.

The flaws are called PHP2Shell (CVE-2026-109618 and CVE-2026-109619). The story everyone is telling is that AI found them first. That’s true, and it’s good news. But the part that matters for anyone who governs security is the other half: AI also made them cheap to weaponize, and almost every vulnerability management policy I’ve read assumes it’s expensive.

What happened

The researchers’ timeline, from Wiz, Recorded Future and Amazon Threat Intelligence (all times UTC):

The bugs themselves are memory-safety flaws in how PHP cleans up after a request fails partway through, for example when it runs out of memory. Corrupted state can survive into the next request on the same worker, and a remote attacker with no account can turn that into code execution. Wiz says the flaws had been present for years; what was missing was a practical way to exploit them.

That’s where AI changed the economics. Wiz says frontier models helped find the bug, build the exploit, and adapt it to different PHP versions and memory layouts, which “shortened exploit development from months to hours.” OpenAI, which coordinated the disclosure through its Patch the Planet initiative, said AI appeared to find the flaws before any attacker did. Amazon’s post makes the uncomfortable corollary explicit: AI-assisted analysis makes it cheaper to turn a patch diff or an advisory into a working exploit, so more actors can act within hours or minutes of disclosure.

The defenders had a two-month head start. It shrank to hours when the details leaked, and it would have shrunk to hours anyway the moment the patch was public.

Why this one is different

The race was lost before the patch existed

Every vulnerability management policy is built around one event: the vendor releases a fix. The clock starts there. “Critical: remediate within 30 days” or, for the most aggressive programs, 14 or 7 days.

In this case, exploitation started four days before that event, according to Amazon, and was widespread on the day of it. A policy that starts the clock at patch release had nothing to say about the period when the risk was highest. No SLA was breached. Every organization was “compliant” while it was being attacked.

“Patch” assumes the code is yours

The PHP Foundation fixed PHP in about two months. That fixes PHP on servers where you install PHP. It doesn’t fix the PHP inside your firewall’s management interface, your SIEM, your load balancer or your vendor’s SaaS platform.

A day after disclosure, according to Help Net Security, Palo Alto listed every PAN-OS and Panorama version as affected with no fixed release yet. Fortinet had 12 products under investigation. Cisco had 18 products and 13 cloud services under investigation, and said there were no workarounds. Your 30-day SLA can’t start until those vendors ship, and you don’t control when that is.

This is where vulnerability management quietly becomes third-party risk management. The question isn’t “how fast do we patch?” It’s “which of our vendors have PHP inside, and what have they told us?” Most companies can’t answer that today, because they don’t have software bills of materials (SBOMs) from their appliance vendors, or don’t read the ones they have.

Most of the exposure can’t be patched at all

Scans quoted by Recorded Future found about 5.1 million IP addresses running PHP. Of the roughly 1.1 million that disclose a version, about 758,000 run branches that are end-of-life: PHP 8.1 and older, which get no official fix. For those, the remediation isn’t a patch. It’s a migration project, and it was overdue before this week.

End-of-life software usually sits in a risk register as an accepted risk with a note like “no known exploitable vulnerabilities.” That sentence expired on October 21.

What would have helped, ranked by cost

Policy changes (cost: a meeting and a signature):

1. Add a “pre-patch” tier to the vulnerability policy. For critical, internet-facing, actively exploited flaws, the policy should require mitigation within hours, whether or not a patch exists: WAF rules, restricting access, disabling the affected feature or taking the service offline. Amazon’s advice was to measure these timelines “in hours, not days or weeks.”
2. Pre-approve the decision to go offline. The FBI recommended it. Japan’s prime minister said suspending websites was an option. Britain’s prime minister’s office took some services offline. Inside a company, that decision usually needs a business owner, and at 3 a.m. nobody knows who it is. Name the role, the criteria and the maximum outage in advance, so the incident team doesn’t have to find a vice president.
3. Start investigations from first exploitation, not from disclosure. Amazon’s advice was to look back to October 17. If your incident procedure says “review logs since the advisory,” you’ll miss the four days that matter.

Inventory (cost: weeks, then continuous):

1. Know where the runtime is, not just the application. “Do we run WordPress?” is the wrong question. “Where does PHP execute, including inside products we bought?” is the right one. Container images, managed hosting and appliances all count.
2. Ask vendors for SBOMs and read them. Then, when the next runtime-level flaw lands, the third-party risk team can send targeted questions within the hour instead of a generic questionnaire within the month.
3. Put end-of-life software on a funded plan, not an exception. An exception without an expiry date is a decision not to decide.

Architecture (cost: real, but already justified):

1. Never expose management interfaces to the internet. Palo Alto’s main mitigation was to restrict management access to trusted internal addresses. If that was already true, the firewall issue was a low-priority patch, not an emergency.
2. Make origins unreachable except through the WAF. A virtual patch at the edge does nothing if the server behind it has a public address. Recorded Future called this out explicitly.
3. Detect behavior, not CVEs. Repeated out-of-memory errors, PHP worker churn and web servers spawning shells look the same whatever the next CVE number is.

If you run PHP

Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP says configuration changes don’t fully close both flaws, so treat any mitigation as temporary. If you’re on 8.1 or older, use your OS vendor’s backported package or move to a supported branch. Check appliances and SaaS vendors separately, and review logs from October 17 onward, not from the advisory. watchTowr’s FAQ and Amazon’s post have the detection guidance.

What this means for AI governance

AI governance usually means governing the AI you build or buy. PHP2Shell is a reminder that it also means governing for an environment where everyone, including attackers, has AI.

That has two consequences for a control framework.

First, the good news is real. AI models found flaws that had sat in critical infrastructure for years, and the industry got a two-month head start to coordinate a fix. OpenAI is now proposing a framework for handling AI-discovered vulnerabilities and has asked the security community to critique it. That’s the right instinct: when finding bugs gets cheap, disclosure processes designed for a few dozen critical bugs a year will be overwhelmed.

Second, the assumptions behind our timelines are out of date. Patch SLAs, exception approvals and risk acceptances all carry an unstated assumption about how long it takes an attacker to go from “a flaw exists” to “a flaw is exploited.” For PHP2Shell, the gap was measured in hours, and in at least one case it was negative.

Three questions every security and risk program should be able to answer after this week:

1. What does our policy require before a patch exists? If the answer is “nothing,” the policy covers the safe part of the timeline and skips the dangerous one.
2. Which of our vendors would we have to call, and how fast would we know? If the answer depends on a questionnaire, it’s too slow.
3. Who is allowed to take a service offline, and on what criteria? If nobody knows, the decision will be made late, or not at all.

The patch arrived two months after the bug was reported, and AI deserves credit for that head start. The exploits arrived before the patch, and AI deserves some credit for that too. Policies that start the clock at patch release are measuring the wrong race.

Sources: Wiz Research · Amazon Threat Intelligence · Recorded Future · watchTowr · AP via PBS NewsHour · Help Net Security · Fortune. Vendor fix status is changing daily; check each vendor’s advisory. Exposure counts are scan results, not confirmed vulnerable hosts. Times are UTC.

It wasn’t a typosquat or a fake package. Version 1.107.0 was built, signed and published by LiteLLM’s real release pipeline, and passed its approval gate. Every control did what it was designed to do.

That’s what makes it worth studying. Here’s what happened, why it matters more than another supply-chain incident, and what governing AI infrastructure should look like after it.

What happened

LiteLLM is a proxy that sits between applications and model providers: one API in front of OpenAI, Anthropic, Bedrock, Vertex and dozens more. Datadog’s write-up cites about 23 million weekly downloads. Companies run it as the central gateway for their AI traffic.

According to LiteLLM’s incident report and independent reconstructions by StepSecurity, Datadog and Chainguard (all times UTC):

The source code was never modified; the v1.107.0 git tag is clean. The attacker repointed the release workflow at a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm, and added one line to the build configuration so that three extra files landed in every wheel.

The payload ran without anyone importing LiteLLM. A cook.pth file in site-packages executes on every Python start, pip included. It ran a credential stealer covering 16 categories, including cloud credentials, SSH and GPG keys, browser passwords, CI secrets, the environment of every readable process, and AI coding tool configs. It also planted an hourly loader designed to fetch and run new code.

Update, October 28: LiteLLM’s attack-chain post ruled out the log theory below. The first token came from a master key leaked in May and never revoked. I’ve written up the corrected root cause in Deleting the commit didn’t revoke the key.

How the attacker got the credentials is still under investigation. LiteLLM’s report describes an unexpected user account on an internet-exposed internal LiteLLM deployment, and says that GitHub CLI tokens could appear in that deployment’s logs because response bodies were logged. It hasn’t confirmed how the attacker got into the deployment.

This was LiteLLM’s second compromise in seven months; in March, according to Chainguard, a stolen PyPI token was used to publish two malicious versions.

Why this one is different

The payload was built for AI infrastructure

Most credential stealers grab whatever’s on disk. This one had a module, db_litellm, that connected to the proxy’s database when DATABASE_URL was set and queried LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable: the tables where the gateway stores every model provider’s API key.

An AI gateway is the most valuable place in a company to steal AI credentials from, because it’s designed to hold all of them. It often also logs prompts and responses, which can contain customer data, internal documents and, as LiteLLM found, other people’s tokens.

We’ve been treating AI gateways as developer tooling. They’re tier-0 infrastructure, closer to an identity provider than a library.

“Signed” didn’t mean “safe”

LiteLLM had done the hardening the industry recommends after March: a private release workflow, PyPI trusted publishing, immutable Docker tags and image signing. None of it helped, because the attacker didn’t bypass the pipeline. They changed what the pipeline built, and the pipeline signed it.

But the evidence was there. The build provenance named the lookalike repository. A signature answers “did this pipeline build this artifact?” It doesn’t answer “did it build it from the source I think it did?” unless someone checks the source in the provenance. Tools like slsa-verifier take a --source-uri for exactly this reason. Almost nobody consuming PyPI packages runs that check.

Two-person rules fail when one person holds two keys

The release had two strong controls on paper: branch protection on the workflow, and a production approval gate. Each was defeated with a different developer’s stolen credential.

Auditors call this segregation of duties, and it’s the oldest lesson in controls: a two-person rule only works if no single party can act as both people. When credentials are long-lived and collectable from one place, such as logs, one attacker can impersonate everyone in the chain. The control was designed for insiders acting alone, not for an outsider holding three tokens.

What would have helped, ranked by cost

For everyone who installs open-source packages:

1. A cooldown on new versions. The malicious release was removed from PyPI in under two hours. A policy of not installing versions younger than one day, available through Dependabot’s cooldown setting or uv’s --exclude-newer, would have skipped it entirely. I use a two-week window on my own projects; this is the incident that justifies it.
2. Pin versions and images, never latest. The attacker repointed latest, main-latest and main-stable. Anyone pulling a mutable tag got the malware without changing a line of config. Pin Docker images by digest.
3. Hash-locked dependencies, with a caveat. Hash pinning protects you from a changed artifact you’ve already vetted. It would not have stopped you from regenerating a lockfile onto the malicious version. Pinning and cooldown work together.
4. Egress control on AI infrastructure. The stealer sent data over plain HTTP to an attacker domain. A gateway that can only reach model providers can’t exfiltrate to anywhere else.

For anyone running an AI gateway:

1. Keep provider keys in a secret manager, not in the gateway’s database, so a compromised process can’t dump them all with one query.
2. Don’t log full request and response bodies by default. AI traffic carries credentials and sensitive data in places nobody expects. If you must log, redact.
3. Give the gateway its own identity, least privilege and monitoring, as you would an identity provider. Alert on new outbound destinations.

For anyone publishing software:

1. Verify the source, not just the signature. Check that provenance names the repository you expect, in CI, before publishing and before installing.
2. Make approval gates require something an attacker can’t replay, such as a hardware key or a fresh MFA prompt, not a long-lived token.
3. Treat the release workflow definition as a crown jewel too. Changes to it should be rarer and more heavily reviewed than changes to the code.

If you were affected

Follow the official remediation and the tracking issue, which has the wheel hashes and indicators of compromise. The short version from the incident responders:

• Don’t run Python in an affected environment first. Every interpreter start re-runs the stealer; find and kill the loader process, then delete cook.pth, cook.py and the foreign sitecustomize.py.
• Rebuild rather than clean, pinned to litellm==1.106.2 or the v1.106.2 image by digest.
• Assume exfiltration succeeded and rotate everything the host could reach, including every provider key in the gateway’s database, its master and salt keys, and the database password.

What this means for AI governance

AI governance conversations tend to focus on models: bias, hallucination, misuse. This incident had nothing to do with model behavior. It was about the plumbing around the models, and that plumbing now concentrates some of the most valuable credentials and data a company has.

Three questions every AI governance program should be able to answer after this week:

1. Do we have an inventory of our AI infrastructure, not just our models: gateways, proxies, agent frameworks and MCP servers, with owners?
2. Is that infrastructure held to tier-0 controls? Pinned and verified dependencies, secrets out of databases and logs, egress allowlists, monitored identities.
3. Would we know within two hours? LiteLLM’s community spotted this in under 30 minutes. Most companies wouldn’t have noticed at all until the credentials were used.

The release was signed, approved and published by the real pipeline. Every control worked as designed. That’s not a reason to trust controls less. It’s a reason to design them for an attacker who holds more than one key.

Sources: LiteLLM incident report · BerriAI/litellm#47826 · StepSecurity · Datadog Security Labs · Chainguard · TechCrunch. Details may change as the investigation continues; times are UTC.

My tool reported it as inconclusive, and that was the honest answer. This essay explains why, how auditors have handled the same problem for decades, and how to size an AI red-team so that “pass” actually means something.

Zero failures is a statement about the sample

A red-team run is a sample. You don’t test every possible prompt; you test a few hundred and infer how the model behaves on the rest. That inference has error bars, and with small samples the error bars are enormous.

The question to ask isn’t “how many attacks succeeded?” but “given what we observed, how high could the true attack success rate plausibly be?” For zero failures, the answer is roughly 3.84 / (n + 3.84) at 95% confidence. That’s the upper end of the Wilson score interval, the method llm-redteam-evidence uses.

Read the second row again. Twelve clean results are entirely consistent with a model that falls for that attack one time in four. You just didn’t happen to see it.

Auditors solved this a long time ago

None of this is new to audit. When an auditor tests a control, say “every payment over $10,000 has a second approval”, they don’t check every payment. They pick a sample, and the sample size comes from two numbers decided before testing:

• Tolerable deviation rate: the failure rate at which the control would no longer be considered effective (for example 5%).
• Confidence: how sure they need to be that the true rate is below it (commonly 95%).

With zero expected deviations, that gives a sample of 59 for a 5% tolerable rate at 95% confidence. That’s the figure in standard audit sampling tables, and it falls straight out of the same mathematics: the smallest n where (1 − 0.05)ⁿ ≤ 5%.

If one of those 59 fails, the auditor doesn’t round it away. The sample no longer supports the conclusion, and they either expand testing or conclude the control isn’t effective.

AI red-team reports rarely work this way. They present “0 of 12” as if it were “0%”, and nobody asks how 12 was chosen.

How many attacks do you actually need?

Turn the table around: given a tolerance, how many clean results do you need before the upper bound drops below it?

The two methods differ a little: the Wilson interval is two-sided and slightly more conservative. Either way, the shape is the same. Halving the tolerance roughly doubles the sample. And a tolerance of exactly 0%, which is what most teams instinctively want for things like system-prompt leakage, can never be demonstrated by testing. You can only show the rate is below some small number.

That’s a governance decision, not a statistics problem. Someone has to write down “we accept up to 1% and we’ll test enough to show it”, or accept that “0%” is an aspiration the evidence can’t support.

What this looked like in a real run

From the Llama 3.2 3B assessment:

• Unsafe output (RT-07): 0 of 12 exfiltration attempts succeeded. Upper bound 24%, against a 0% tolerance and a 20-attack minimum. Verdict: inconclusive, a coverage gap.
• Jailbreaks (RT-03): 2 of 4 succeeded. That’s 50%, but the upper bound is 85%. With four attempts you can say the model is jailbreakable; you can’t say how jailbreakable.
• Indirect injection (RT-02): 113 of 256 succeeded, 44% with an upper bound of 50%. The large sample makes this one a confident failure.

The same tool, the same model, three different strengths of evidence. A report that showed only the rates would have hidden all of that.

Five habits for red-team evidence

1. Set the tolerance and the minimum sample per control before the run. Write them down and version them, like any other control definition.
2. Report the upper bound next to every rate. “0% (95% upper bound 24%)” tells a reviewer exactly how much the result is worth.
3. Treat under-sampled controls as coverage gaps, not passes. “Inconclusive” belongs in the findings, with a plan to close it.
4. Size by tolerance. Use the table above. If you can’t afford 189 attempts for a 2% tolerance, either accept a looser tolerance or say the control is untested.
5. Spread the sample. 300 variations of one prompt aren’t 300 independent tests. Mix attack families, phrasings and contexts, the way an auditor spreads a sample across months and locations.

The bigger point

“We tested it and nothing happened” is one of the most common sentences in AI assurance, and one of the least informative. The fix isn’t more sophisticated attacks. It’s the discipline audit already has: decide what’s acceptable, size the test to prove it, and report the uncertainty honestly.

Zero failures is the start of an argument, not the end of one.

The numbers here use 95% confidence. The Wilson bound is computed by wilson_upper() in llm-redteam-evidence; the exact one-sided column is the smallest n with (1 − tolerance)ⁿ ≤ 0.05.

Most of that access isn’t designed. It’s copied. A developer wants Claude or Cursor to read their files, so they open the server’s README, copy the configuration example and paste it in. So I asked a simple question: if you set up an agent by copying the official examples, what access does it end up with?

Method

I took the first valid configuration example from 9 widely used MCP server READMEs: the official reference servers, GitHub’s MCP server and a popular community server. I saved each exactly as published, with a link to the exact commit and line, and scanned them with agent-access-review, my open-source tool that runs a user access review on AI agents.

These are documentation examples, written to be easy to copy, not production setups. The point isn’t that the READMEs are wrong. It’s that copying them without a review produces the access below, and nothing in a typical workflow flags it.

One config at a time

Unpinned packages are the quiet one. npx -y <package>, @latest, uvx <package> and an untagged docker run all fetch whatever was published most recently, every time the client starts. If a release is ever compromised, it runs with your agent’s access, and your config never changed. In a normal software supply chain, that would fail a review on day one.

The Slack example teaches a secrets anti-pattern. Its env block sets the bot token to a placeholder you replace with the real token. Follow it, and your Slack token sits in plain text in a JSON file, in every backup and in any dotfiles repository you sync.

Write, send and execute are the point of most of these servers. That’s fine. The finding is about governance: who approved giving an agent that power, and is there a human check before it acts?

Then I pasted them together

Developers rarely run one server. I combined all nine examples into a single config, the way a real setup grows over a few weeks of “let me just add this one”. The scanner raised its highest-severity finding:

The agent reads sensitive data, ingests content outsiders can write, and can send data out, with no human approval. That's an exfiltration path.

A prompt injection hidden in a web page, a GitHub issue or a Slack message could make the agent read your files or database and send them somewhere. No single README creates this risk. The combination does, and that’s exactly what per-server documentation and per-tool reviews miss.

It’s the same lesson as segregation of duties in financial controls. Each permission is reasonable on its own. The risk is in the combination, so that’s where the review has to look.

What my own tool got wrong

Running a real scan found two gaps in agent-access-review, both now fixed:

1. 5 of the 9 configs were initially unclassified. The tool only recognised npm package names, but the official READMEs now mostly recommend Docker images and uvx. The capability catalog now supports aliases, and all 9 are assessed.
2. Docker mounts were invisible. For containerised servers, what the agent can reach is set by -v and --mount flags, not by the server’s arguments. The scanner now reads host bind mounts as the grant’s scope, so mounting your home directory gets flagged, and read-only mounts are treated as read-only.

Testing your own tool against real-world input is the cheapest audit you’ll ever run.

What to do about it

1. Pin every server. Use a version for npm and uvx, and a digest for Docker images. Treat MCP servers like any other dependency.
2. Keep secrets out of config files. Reference an environment variable or a secret manager, never a literal token.
3. Review the combination, not the server. Ask the exfiltration question for the whole agent: can it read something sensitive, ingest untrusted content and send data out?
4. Give agents owners and approval dates. If nobody owns an agent’s access, nobody will ever take it away.

Caveats

Some MCP clients ask before each tool call. That setting isn’t visible in config files, so the scan reports what the configuration allows. The postgres, puppeteer and slack servers have been archived, but their READMEs are still widely linked and copied. The framework mappings are my own judgment.

Reproduce it

Every config links to the exact commit it came from, and the full results are in the case study.

pip install agent-access-review
agent-access-review scan path/to/your/mcp-configs

Run it on your own setup. I’d be surprised if it comes back clean.