Session CRT-20260605 — 5 June 2026 · Afternoon Edition

Okay, I've got the empirical grounding. Let me address the moderator's three questions directly.

On architectural gaps in enterprise AI agent entitlement models:

The core problem is not OAuth scope over-provisioning per se — it's multi-hop delegation without capability attenuation. According to the WorkOS research from March 2026, the IETF OAuth mailing list is already debating "delegation chain splicing" where actors can insert themselves into legitimate hops. Claude Cowork exemplifies this: the Dispatch tool uses its own authentication tokens, not the user's native sessions, so SharePoint audit logs show "Claude Cowork Agent" as the actor — decoupled from the user's actual identity and intent.

Think of it like SQL injection, but the parser is a neural network with no formal grammar AND no privilege model. The gaps I see empirically:

1. Plugin bundling without transitive trust evaluation. Per Harmonic Security: "Plugins bundle together skills, connectors, and sub-agents into a single package, which means installing one can significantly expand Claude's scope of action." Each plugin introduces an attack surface, but enterprise governance typically reviews the primary plugin, not the sub-agents and connectors it spawns.

2. Absence of per-action authorization. The DTEX research shows Cowork can access "SharePoint corporate data, production documentation in OneDrive, Outlook email, Salesforce data, and any other files on the user's endpoint" through the same Dispatch interface. There's no step-up authentication for sensitive repositories — the agent gets the access once and can pivot across the entire data plane.

3. Governance exclusion. As PromptArmor documents: "Cowork activity is excluded from all three governance mechanisms: Audit Logs, Compliance API, and Data Exports." This is systemic — it's not a bug, it's an architectural decision to prioritize performance and availability over auditability.

On the DPRK insider weaponizing Cowork specifically:

This is where the kill chain timing matters. DTEX's Alex Desmond notes the operational kill chain has compressed from "roughly a couple of hours six months ago to as little as 10 to 30 minutes." A DPRK IT worker already embedded via a fraudulent employment scheme starts with advantages: they're provisioned legitimate credentials, have plausible work activity to mask their actions, and understand which repositories contain valuable IP.

What distinguishes their Cowork usage from legitimate activity is not in the native API telemetry — it's in the reasoning intent chain. As James just pointed out, without audit.jsonl ingestion and OpenTelemetry correlation, you won't see the prompt context that led to "summarize Salesforce records into an email draft and archive and transfer files." The native logs just show file access and email composition — activity that looks like a legitimate user performing their job.

The signature to hunt for: asynchronous tool invocation patterns. Cowork supports unattended task execution — "remote-control feature for unattended tasks" in the DTEX research. A legitimate user tends toward synchronous, interactive work with natural pauses and task switches. An insider exfiltrating at 2AM via unattended mode will cluster tool invocations: mcp_tool_use for Salesforce connector, bash_command for file staging, outlook_send or similar dispatch — all within a narrow time window, with elevated data volumes and cross-repository pivots that don't match the user's historical job function.

On realistic least-privilege scoping TODAY:

I'm not going to pitch a theoretical framework — here's what can actually be done based on the sources above:

Immediate (this week):

• Disable Cowork Dispatch for any user without explicit business need. Per Harmonic Security, there's a toggle (Team/Enterprise level).
• Enable OpenTelemetry for Claude Code/Cowork and ship audit.jsonl and main.log to your SIEM. Without this, you're flying blind per James's point.

Short-term (30 days):

• Implement plugin tiering: Classify plugins by blast radius (connector-only vs. sub-agent spawning vs. shell execution). Per the Harmonic NIST CSF mapping, this maps to ID.SC (Supply Chain).
• Map Cowork permissions to actual job functions. Salesforce access should be scoped to business units, not enterprise-wide. Use Anthropic Enterprise features: RBAC via custom roles controls "Cowork/Claude Code/web search/memory/code exec/fast-mode access per group."

Medium-term (90 days):

• Build telemetry correlation rules. The Monad research shows we can detect via tool_result events where we correlate tool_parameters.bash_command against full_command and mcp_tool_use for suspicious connector access patterns.
• Implement time-limited OAuth tokens for agentic workflows, per the WorkOS Pipes approach: "grant agents time-limited access to OAuth connections, scope tokens to specific tools, and enforce permissions so agents can only invoke what they've been authorized to use."

The reality: we do not have a reliable defense for prompt-driven exfiltration yet. The best mitigation is monitoring the reasoning chain, not the outcome. Most enterprises today have zero visibility into the former.

Based on my research and Marcus's input, here's the cloud identity architecture breakdown.

Current Enterprise IAM Architecture Gap

Look, the reality is most enterprises are treating AI agents as "just another application" in their identity inventory — and that is the root cause. What I found from the CSA research note is that AI agents authenticated via enterprise SSO often get OAuth grants scoped for full user impersonation, not workload identity federation. The Wiz blog notes that rather than exploiting vulnerabilities in the primary platform, these attacks rely on pre-authorized access and delegated permissions, enabling stealthy lateral movement and expanding the blast radius across multiple organizations that trusted the same integration.

Blast Radius Mapping

Let me draw this in cloud-native terms: the attack surface isn't the agent itself, it's the effective permission surface created when an agent bridges multiple systems simultaneously. According to the CSA research note, as AI platforms gain the ability to construct arbitrary agents that interact with users, the OAuth supply chain blast radius expands significantly. When an AI agent token is compromised, the lateral movement paths include:

• OAuth refresh token chaining: The attacker inherits the full OAuth scope originally consented — often Mail.Read, Files.Read.All, Calendars.ReadWrite across Exchange Online and SharePoint. That's not a bug, that's the intended design of OAuth consent.

• Supply chain propagation: The Wiz analysis of Context.ai found that compromised OAuth tokens enabled attackers to perform a supply chain attack via trusted SaaS integrations, exploiting the fact that these tokens granted access across connected environments.

According to Obsidian Security's analysis cited in my sources, the biggest SaaS breaches often start with compromised third-party apps, with attackers exploiting OAuth tokens to access downstream environments — the blast radius of such supply chain attacks can be significantly greater than direct platform breaches.

Production-Ready Controls Today

Here's the thing: there ARE controls, but they require architectural maturity most orgs don't have. The non-negotiables I'm seeing from the evidence:

1. Migrate to distinct service principal types — Marcus recommends distinct non-human identities with short-lived token lifetimes (4 hours max), separate from human user tokens.

2. Workload identity federation — agents authenticate via certificate-based auth or managed identity, not OAuth bearer tokens held in agent context. Marcus specifically calls out that workload identity federation with hardware-bound credentials would prevent breaches that started with stolen agent tokens.

3. Implement continuous access evaluation (CAE) for service principals — revoke tokens on risk signal, location anomaly, or token exfiltration detection.

But the production-ready reality check? Most enterprises are still stuck at step zero because their consent flows assume human OAuth patterns. The gap everyone is ignoring: there's no per-action authorization model in OAuth itself. Once you consent to Files.Read.All, that scope applies to every call. The fine-grained per-resource authorization you'd want (e.g., "this agent can only read files in /project-X, not /finance") requires implementing policy-as-code at the application layer — Entra's conditional access doesn't extend to granular resource-level decisions within a delegated scope.

So yes, it's a real gap. The identity provider secures the authentication boundary. What you do with that token once acquired — the actual resource-level authorization — that's on you, not the CSP.

Right, here's what I'm seeing.

Weaponization Timeline: Hours, Not Days

The public PoC went live June 4, and according to F5 Labs, we had active exploitation within hours for BlueHammer, RedSun, and UnDefend back in April. Look, these are not complex exploits. RedSun is directory junction abuse against Defender's cloud file handling — mechanically similar to things I was weaponizing in 2015. UnDefend just locks mpavbase.vdm to break Defender's signature reloading. These are simple primitives.

If it's not already in commodity crimeware, it'll be there by the weekend. We're talking about LPE to SYSTEM and complete AV degradation that runs as an unprivileged user. Malware authors love primitives that don't need elevation preconditions.

Detection Artifacts — Hunt These NOW:

Based on Huntress incident data and the GitHub detection repos, here's what's actually observable:

1. File paths in low-privilege directories:

   • C:\Users\*\Downloads\FunnyApp.exe, RedSun.exe, z.exe — original PoC filenames
   • C:\Users\*\Downloads\ks\undef.exe, C:\Users\*\Downloads\kk\undef.exe -aggressive — UnDefend variants

2. Parent-child anomalies: UnDefend running as a child of cmd.exe under Explorer.exe with the -aggressive flag. That's not normal.

3. RPC call patterns: Non-Defender processes making RPC calls to IMpService after Defender platform initialization.

4. File lock indicators: mpavbase.vdm locked by unexpected processes — signature database access attempts failing.

On "Assume Breach":

Look, it's not full assume-breach territory, but it's close. If you're unpatched and you have internet-facing endpoints with any interactive user access, start hunting now. The threat actor doesn't need to be sophisticated — the PoC is public, reliable, and works on fully patched systems. The triage path is: check those file paths, hunt for the parent-child relationships, and if you find the -aggressive flag execution pattern, that's smoking-gun compromise.

CISA's BOD deadline was June 3 — but that was just for federal agencies. Private sector? If you didn't patch by June 4, you're in the exploitation window.

James — what are you seeing in terms of EDR detection efficacy? Can most shops catch the RPC anomaly, or is this slipping through?

(1) Downstream Regulatory Exposure for Non-Federal Entities

Direct Answer: No BOD 22-01 obligation, but indirect regulatory exposure exists.

The CISA BOD 22-01 deadline of June 3 applies exclusively to FCEB agencies — the "Binding" in BOD means Federal Civilian Executive Branch only. CISA's explicit language: "Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to prioritize timely remediation of KEV Catalog vulnerabilities."

For regulated sectors, three independent compliance frameworks create downstream exposure:

The KEV catalog serves as evidence of "known, actively exploited" status. For HIPAA-covered entities, unpatched KEV-listed flaws in critical infrastructure (Defender is endpoint protection) arguably violate the "reasonable safeguards" standard under 45 CFR §164.312.

(2) Negligence Liability Landscape Post-Public PoC

Standard of Care Argument: CISA's KEV entry creates a rebuttable presumption that the vulnerability is "known and dangerous." Under tort law principles applied to cybersecurity, failing to patch a known-exploited vulnerability within a reasonable timeframe raises negligence exposure — though current industry-standard remediation timelines (often cited in the 30–90 day range) should be confirmed against applicable framework guidance for your sector.

Specific Risk Vectors:

• Healthcare (HIPAA): OCR enforcement considers unpatched critical vulnerabilities "willful neglect" in security risk analysis. Current penalty tier amounts should be confirmed against current HHS penalty schedules under 45 CFR §160.404.

• Financial Services: Under FTC Safeguards Rule §314.4(h), inadequate "technical controls" can trigger enforcement. Claims about specific recent FTC enforcement trends should be confirmed against current FTC enforcement actions before being relied upon.

• SEC Filers: Unpatched KEV status is now a material risk factor under Item 105 of Regulation S-K. If breached, the 4-business-day 8-K clock starts at detection — failure to disclose becomes securities fraud exposure.

A note on the June 4 PoC date: That date has not been independently confirmed here and should be verified before being relied upon in any formal analysis.

Assessment: The lapsed June 3 deadline itself creates no direct liability for private-sector entities. But the convergence of: (a) KEV-status = known active exploitation, and (b) Defender's critical security function = elevated duty of care, means post-deadline breaches via these flaws face heightened negligence scrutiny in any sector with a written cybersecurity framework.

Practical advice: Organizations in regulated sectors should document risk acceptance decisions if patching is delayed — "we're aware of CISA KEV but deprioritized" becomes Exhibit A in any subsequent litigation.