Banks lock AI agents out of accounts, an SBOM that could not scope a Shai-Hulud incident, passkeys that do not close identity, how long to keep logs, and a 2.7 flaw that switched them off.
In this edition
- 01Banks are locking AI agents out of customer accounts.
- 02The SBOM did not tell them what had actually run.
- 03Passkeys close the password problem. They do not close identity.
- 04Your SOC wants every log forever. Your DPO wants six months.
- 05A flaw scored 2.7 switched the logs off, and nobody would have patched it.
Get the next GRC Brief in your inbox.
Subscribe to The GRC BriefBanks are locking AI agents out of customer accounts.
Axios reported on 22 October that major US banks are detecting third-party AI agents operating inside customer accounts, usually because the customer handed over their username and password. JPMorgan's chief executive said letting arbitrary outside agents in would be too risky for clients and for the bank. Bank of America has reminded customers that if they share their credentials, they are responsible for whatever follows. Many banks are moving towards read-only access instead. A dissenting view, from Bianco Research, is that retail banking profits from customer inertia, and an agent that moves idle cash into a money market fund costs the bank money.
Source: Axios · 22 Oct 2026
My take
Both explanations can be true at once, and the thing underneath them is more interesting than either. A retail customer has no way to grant an agent limited authority, so they hand over the entire credential. That is the machine identity problem I wrote about in September, one identity per agent with credentials scoped to a task, except the account holder has none of those tools and the bank cannot tell your agent from a thief. Read-only fixes one half. An agent that can read your statements can still disclose them when it is compromised or manipulated, and stopping a transfer and protecting confidentiality are two different jobs.
The SBOM did not tell them what had actually run.
At the ISC2 Security Congress, Atlassian product security manager Deepam Kanjani walked through a real Shai-Hulud response. The malicious package sat three dependency levels down, invisible to top-level scanning. When the incident started the team's SBOM was already stale and there was no runtime telemetry, so they could not establish what had executed across more than 400 services. His recommendation is specific: keep deployed SBOMs under 72 hours old across more than 98 percent of production services, and detect unknown module loads at runtime.
Source: Dark Reading · J. Vijayan, 27 Oct 2026
My take
I have told you twice this year to treat the SBOM as a live inventory rather than an audit artefact. Here is the number I did not have. Seventy two hours. If yours is generated at build time and your last release was in September, it describes a system you are no longer running. And notice which half is missing almost everywhere. The bill of materials records what you shipped. Nobody is watching what loaded. During an incident the only two questions are what executed and where it reached, and a dependency list answers neither of them.
Passkeys close the password problem. They do not close identity.
A caveat first, this one is a vendor-side expert column rather than reporting. The argument stands anyway. Passkeys remove the reusable secret and resist phishing, which closes most of the credential attack surface. What they do not touch is everything around the authenticator: whether the account was legitimately established in the first place, what happens when a device changes, what your recovery path accepts as proof, and whether a session can be hijacked after a perfectly clean login. As organisations remove passwords, attackers move to those edges.
Source: SecurityWeek · T. George, expert column, 30 Oct 2026
My take
You have already seen the concrete version of this twice. In August, a phishing kit that enrolled its own passkey on the victim's account and survived the password reset. Last month, a rogue external MFA provider that satisfied the check while the second factor never happened. Neither attacked the cryptography. Both went straight at enrolment and recovery. So deploy passkeys, they remain the right move. Then answer the two questions that decide whether they hold: who is allowed to enrol one on an account, and what does your service desk accept as proof when somebody calls to say they have lost their device.
Your SOC wants every log forever. Your DPO wants six months.
I wrote this one up this week. When PHP2Shell went public on 21 October, Amazon's threat intelligence team told responders to investigate from at least 17 October, four days earlier. If your web server logs rotate weekly, you will never find out whether you were hit before anyone announced anything. Ask your data protection officer how long to keep those same logs and you get a different answer, because they are full of addresses, identifiers and sometimes entire request bodies. Five regulatory sources give five different numbers, and not one of them gives you a universal one.
Source: My full breakdown · cyberacademy.net
My take
What all five ask for instead is the same thing: a period tied to a purpose, written down with a reason. The usual mistake is setting retention per tool, because "the SIEM keeps 90 days" is a licence decision wearing a security badge. Set it per purpose instead, detection, investigation, accountability for privileged access, legal floor, and let the most demanding one you can actually justify win. Then use the two dials nobody touches: log the event without the record itself, and tier the storage so fewer people can reach the older data. One pattern I see in nearly every audit I run, the DPO was never asked. Article 38 says they should have been.
A flaw scored 2.7 switched the logs off, and nobody would have patched it.
Broadcom rates CVE-2026-41709 at 2.7 out of 10. It is an insufficient logging flaw in VMware ESX that lets someone who already holds administrator access on a host carry out certain operations without them appearing in the logs. On 28 October CrowdStrike revealed that the China-linked group Warp Panda had used it as a zero-day in early 2026, during espionage intrusions against US law firms, specifically to cut down what the audit trail would show. Broadcom shipped a fix on 29 July. CISA added it to the known exploited catalogue the same day CrowdStrike published, with a federal deadline of 11 November.
Source: CrowdStrike · 2026 Legal Threat Landscape Report, 28 Oct 2026
My take
Read this against the item above and the pair is the whole issue. You can calibrate your retention perfectly, consult your DPO, document the purpose and the period, and still be blind, because somebody turned the recording off underneath you at the hypervisor. Then look at what your own process would have done with it. A 2.7 sits below the floor of most patch policies, so it would never have been queued at all. Broadcom fixed it in July and nothing moved until a threat intelligence report named the group three months later. Worth one more check: the public sources do not even agree on the score, and some list it at 7.6. A five point spread on the same CVE decides whether your policy ever sees it.