AI security: Put the check where the action happens

1. AI-assisted credential theft puts cloud identities on the clock

New reporting · November 5 · Observed activity began earlier

Microsoft Threat Intelligence and Microsoft Security Research reported that attackers used the ARTEX agentic framework to search public GitHub repositories for exposed secrets. Microsoft observed successful sign-ins using application identities as early as October 28, including access to downstream tenants through a compromised multitenant application credential. In one case, Microsoft reported about five minutes between repository scanning and data exfiltration from Azure Key Vault. That timing describes one observed case.

What concerns me is the gap between the team that owns the credential and the teams that inherit its permissions. I’d prioritize blocking known secret patterns before a push and replacing long-lived credentials with short-lived ones where practical. Rotation can interrupt workloads, which makes ownership and a tested revocation path essential. After revocation, I’d ask for service-principal sign-in and resource-access evidence, including affected downstream tenants. Deleting the exposed secret from the repository cannot answer what it already unlocked.

Source: Microsoft: Threat actors use agentic AI tooling to find and abuse exposed secrets.

2. A web agent can read a page without letting it rewrite the plan

New research · November 4 · Preprint and benchmark

In a November 4 preprint, Annabella Chow and colleagues describe Baya, a prototype that compiles a user request into a program before seeing live page content. The researchers designed page data to supply values or select predefined branches without generating new operations at runtime. On the WASP benchmark, they report a 0% attack success rate for Baya, versus 16.2% for an API-enabled reactive agent and 25.5% for a browser-only reactive agent. The result is bounded by the benchmark and design assumptions.

I like the distinction between letting content inform a decision and letting it grant new authority. A fixed plan can still pass a bad recipient or destination to a permitted tool. I’d prioritize validating those arguments at the tool boundary and asking for fresh approval if the plan needs a new destination. That reduces flexibility; for workflows that send sensitive data or change production state, I think the tradeoff is worthwhile.

Source: Chow et al.: Securing Web Agents with the Compile-Then-Execute Paradigm.

3. More capable cyber models raise the bar for authorization

New vendor evaluation · November 5 · System card

OpenAI’s GPT-6 Cyber system card reports stronger cybersecurity capabilities and improved alignment relative to GPT-5.6 Cyber in the company’s evaluations. OpenAI designates the model Critical in cybersecurity under its Preparedness Framework and describes restricted access through Daybreak Red. The designation concerns evaluated capability; the card is a vendor evaluation and deployment disclosure.

I see the appeal of a model that can help triage a vulnerability and develop a reproducible case. I also see a risk that a convincing exploit narrative gets treated as evidence, or that a permitted assessment quietly extends to an adjacent system. I’d favor an isolated environment with authorized targets, identities and network destinations enforced outside the model. Before escalating a finding, I’d ask for a reproducible artifact; before closing it, I’d ask for separate evidence that the fix works on the deployed version. That slows some handoffs, but those are two different decisions.

Source: OpenAI: GPT-6 Cyber System Card.

4. WordPress: A patch release and an exploitation alert answer different questions

New exploitation designation · November 3 · Follow-up to an October 28 release

WordPress maintainers released 7.1.4 on October 28 with a fix for a staged installer race during upgrades that could allow code execution. The maintainers also updated the bundled root certificates because of the eMudhra revocation discussed in the previous edition. On November 3, CISA added the installer flaw, CVE-2026-119977, to its Known Exploited Vulnerabilities Catalog based on evidence of active exploitation. The alert date is when CISA announced the listing.

I’d treat that change in evidence as a reason to split the work. One track should verify the running version and, where relevant, the trust bundle the application actually loads. The other should review available logs for suspicious activity during the exposure window, especially on internet-facing sites. Emergency rollout takes capacity away from other work; here, I’d reserve some of it for investigation. A patched site can still have a history that matters.

Sources: WordPress: WordPress 7.1.4 release notes; CISA: November 3 exploitation alert (archived copy).

5. Keycloak shows why verification and processing must agree

New maintainer release · November 5 · Potential impact

Keycloak maintainers listed a fix for CVE-2026-117691 in version 26.8.2 on November 5. Red Hat Product Security explains that signature verification and message processing handled percent-encoded SAML parameter names differently. Red Hat says successful exploitation could allow account takeover for federated users; the advisory describes potential impact and does not report observed attacks.

To me, the failure is that the security check and the login flow could reason about different inputs. I’d identify which realms actually use the affected federation path and confirm the fixed build for each distribution in service. I’d ask for a regression test that rejects ambiguous parameters alongside a normal federated login test. Federation downtime carries its own cost, so I’d stage the rollout with both results visible to the identity owner.

Sources: Keycloak: 26.8.2 release notes; Red Hat Product Security: CVE-2026-117691.

The question I’m carrying forward

My takeaway: I want independent judgment at approval time and an enforceable check where the action happens. The next question is how to prove that check holds when a workflow takes an unexpected path. Which would you verify first: that an agent cannot exceed its scope, that a stolen credential can be revoked quickly, or that a fix reached every exposed instance?