On 9 November 2026 Wiz, working with Sentra and Mandiant, reported that between 14 and 26 October an actor used IAM user credentials belonging to the AWS account Qubole runs its platform from. The actor called `sts:AssumeRole` against the integration roles customers had created to trust that account. Every attributed request included the External ID and every one succeeded. In most environments Wiz observed, these were the only role assumptions from the vendor account that month. The tooling was scripted rather than described as agentic. It used session names in a consistent format, ran the same sequence of actions in each environment, and validated harvested credentials in bursts lasting seconds. The actor then read Secrets Manager, SSM parameters, Lambda configuration and S3 data. Wiz says a source-IP condition in the trust policy would have blocked every observed assumption.

The component is cross-account IAM trust granted to third-party platforms. Data, analytics, security and, increasingly, AI-agent platforms all use the same mechanism to act inside customer accounts. The External ID is designed to stop the confused-deputy problem between a vendor's customers. It does nothing once the vendor's own credentials are in an attacker's hands, and it is logged in plaintext in CloudTrail. No AI was reported in this campaign. It is in this feed because it is the same standing delegation enterprises are now granting to agent platforms, and it failed open in production.

On 27 October 2026 Project Zero published production data for April to September 2026 from Chrome's V8 engine. In that period BigSleep, an LLM agent that reviews new commits once a day, produced 45 actionable vulnerabilities and Fuzzilli, a specialised JavaScript-engine fuzzer, produced 37. Only 20 of the 81 actionable vulnerabilities were found by both. A separate experiment that asked the agent to rediscover past fuzzer bugs put the overlap at roughly 60%. Fuzzilli usually picks up new code within hours, while BigSleep reports with a one- to two-day delay. Project Zero recommends that vendors run both and expects the agent share to grow, noting that the model it measured is already outdated.

This affects every product built on V8, including Chrome, Node.js, Electron desktop apps and embedded runtimes, and more broadly any supplier whose security testing claims rest on one discovery method. It gives a denominator to the volume question this feed tracks. On a target fuzzed for years, adding an agent did not replace the fuzzer. It added a separate stream of vulnerabilities that arrives a day or two later, so the number of fixes downstream consumers must take grows rather than moves around. Independent confirmation would need the same comparison on targets Google does not own.

On 28 and 30 September 2026 the Model Context Protocol maintainers published advisories for the Python and TypeScript SDK OAuth clients (CVE-2026-115563 and CVE-2026-104850, CVSS 7.5). A malicious or compromised MCP server could name its own authorization server, and the client would send it stored refresh tokens and client secrets without user interaction. The fixes are Python `mcp` 1.30.0 or 2.2.0, and TypeScript `@modelcontextprotocol/sdk` 1.31.0 or `@modelcontextprotocol/client` 2.2.0. Both advisories say that upgrading is not enough. Machine-to-machine providers must be given an explicit expected issuer, and credentials stored before the fix stay unbound until they are cleared or tagged with their issuer. In Python 1.30.0, the warning for a missing issuer is a `DeprecationWarning`, which Python hides by default. CSA's note today reads this as one of three related transport-trust defects in the SDKs.

The component is the agent runtime's MCP client, especially headless agents that use client-credentials or private-key JWT providers to reach internal tools. A team can pass a dependency scan on the fixed version and still send long-lived secrets to whichever server an untrusted MCP endpoint advertises. Dependency scanners report the version and do not see the configuration.

On 27 October 2026 NIST and MITRE authors published ten proposed design tenets for identity, authentication and authorization of AI agents. Agents get their own cryptographically verifiable identities, distinct from human and service accounts. Agents stay linked to whoever initiated them, and delegated authority can only narrow at each hop. Agents hold no standing privileges, and access is short-lived, audience-restricted and revocable at runtime. Human review should be triggered by risk and designed to avoid consent fatigue. The logic that decides what an agent attempts is separated from the systems that decide what it may do, and deterministic mechanisms make the primary access decisions. Actions are recorded in a tamper-evident, append-only log. NIST says the tenets will guide the NCCoE's agent identity demonstrations. They are not a standard, and NIST acknowledges current technology may not meet every tenet.

This covers the identity provider, the agent runtime and the policy layer between them. The first two items in this issue fail on exactly these tenets: a long-lived secret that worked for whoever found it, and a standing third-party role with no runtime check. This is the clearest federal statement so far of what agent identity should look like, and NCCoE demonstrations usually become the reference architectures that suppliers to government are measured against.