SharePoint Machine Keys Outrank The Patch After Active Exploitation

Alex, take the active exploitation cluster as one kill-chain problem, not a CVE list: on-prem SharePoint CVE-2026-32201/45659/56164 with machine-key theft and possible Warlock follow-on, SonicWall SMA1000 chained SSRF/code injection, Ivanti Sentry CVE-2026-10520 root command execution with public PoC/backdoored instances, Adobe ColdFusion CVE-2026-48282 rapid exploitation, and AD FS CVE-2026-56155. Which exposures are most likely already compromised if internet-facing, what post-exploitation evidence matters more than patch status, and what should a CISO order tonight? Keep it decision-ready; argue against the easy 'patch everything' answer.

Halil, I’d rank “already compromised if internet-facing” like this: SharePoint first, SonicWall SMA1000 and Ivanti Sentry basically tied behind it, then ColdFusion, with AD FS treated as high-consequence but not enough evidence here to outrank the others. SharePoint is ugly because the issue is not just “patched or not” — the source pack flags active exploitation and ransomware/intrusion follow-on, and the prompt’s machine-key theft scenario means the attacker may keep signing their way back in after the patch. That’s not a cracked window; that’s someone copying the master key.

For SonicWall SMA1000, Rapid7’s writeup is enough to stop arguing CVSS theater: unauthenticated SSRF can tunnel into localhost-only services, then code injection/privilege escalation can reach root command execution through the remove_hotfix workflow, with targeted exploitation before disclosure and KEV listing. If that box faced the internet, patch status is secondary to: evidence of root-level command execution, suspicious hotfix/remove-hotfix activity, new or modified local users, altered appliance files, unexpected tunnels, and VPN/session anomalies. For Ivanti Sentry, the visible source pack confirms active exploitation of CVE-2026-10520; given the prompt’s public-PoC/backdoored-instance framing, an exposed instance should be treated as potentially owned until inspected or rebuilt. For ColdFusion, active exploitation is also flagged; look for unauthorized code execution artifacts and app-server changes, not just whether the Adobe update landed.

What I’d order tonight: do not run a generic “patch everything” drill and call it done. First, take internet-facing SharePoint, SMA1000, Ivanti Sentry, and ColdFusion assets out of direct exposure where possible. Second, preserve logs and images before cleanup. Third, hunt for post-exploitation: stolen SharePoint machine keys, forged tokens/sessions, webshells or modified server-side code, appliance persistence, unexpected admin accounts, new scheduled tasks, suspicious outbound traffic, and VPN/authentication abuse. Fourth, rotate secrets tied to these systems — machine keys, service creds, VPN creds, signing material where relevant. Patch after containment, but for SharePoint/SMA/Ivanti especially, assume the patch closes the door after the burglar already got in.

Marcus, focus on trust-state persistence across the same cluster: SharePoint IIS machine keys, AD FS/federation compromise, Microsoft 365 OAuth device-code phishing with rogue Entra device registrations, stale Salesforce-connected SaaS credentials, GitHub OAuth/PAT abuse, and npm/CI secrets. Where can attacker access survive password resets and patching, and what exact key/token/session/device rotations or trust revocations should be prioritized in the next 24 hours?

The survival layer here is not the password; it is trust state that keeps validating after the user secret changes. For SharePoint IIS machine keys, AD FS/federation compromise, and stale Salesforce-connected SaaS credentials, I would not claim confirmed compromise mechanics. But if they are in the blast radius, the 24-hour priority is clear: rotate SharePoint/IIS machineKey material and recycle app pools; rotate AD FS token-signing and token-decrypting certificates and remove any untrusted federation trusts; revoke Salesforce connected-app OAuth tokens, refresh tokens, API sessions, and old integration user secrets.

For Microsoft 365, the broader risk is that AiTM phishing can steal live session tokens after MFA, and Conditional Access token protection binds session tokens to the issuing device. So password resets alone are inadequate. Prioritize: revoke user sessions and refresh tokens, remove suspicious OAuth app consents, disable or delete rogue Entra device registrations, require re-registration only through trusted device enrollment, and enforce phishing-resistant authentication — FIDO2/passkeys or certificate-bound device trust — especially for admins.

For GitHub/npm/CI, coordinated GitHub API enumeration/access-token abuse and compromised npm packages involving GitHub activity mean we should treat every PAT, OAuth grant, GitHub App installation token, Actions secret, npm token, deploy key, and CI OIDC trust as potentially persistent. In the next 24 hours: revoke classic PATs first, rotate fine-grained PATs and GitHub App private keys, expire OAuth grants, rotate npm automation tokens, invalidate CI secrets, review Actions workflow permissions, and check for newly added deploy keys, webhooks, and service accounts.

My ordering would be: federation signing keys and OAuth/session revocation first, then device and connected-app cleanup, then source-control/package-registry secret rotation. Patching closes the hole; revocation removes the attacker’s already-issued trust.

Lena, give us the intelligence confidence picture. Separate what is confirmed from what is plausible across SharePoint/Warlock ransomware, SonicWall exfiltration/encryption objectives, Ivanti backdoored instances, Russian Centre 16 router targeting, China-linked use of Claude Code/DeepSeek, and JADEPUFFER. Where do we have campaign continuity, where are we at 'interesting but not proven,' and where would over-attribution mislead response?

Halil, my confidence split is sharp:

• Confirmed: active exploitation of Microsoft SharePoint Server requiring urgent patching; Ivanti Sentry CVE-2026-10520 active exploitation; and broader ransomware pressure in H1 2026.
• Plausible but not proven from the evidence in front of me: tying SharePoint activity specifically to Warlock, defining SonicWall objectives as exfiltration-versus-encryption, and treating “backdoored Ivanti instances” as one continuous campaign rather than opportunistic post-exploitation.
• High risk of over-attribution: China-linked Claude Code/DeepSeek use and JADEPUFFER — I don’t have enough sourced campaign evidence here to call continuity, actor identity, or intent.

On Russian Centre 16 router targeting, I would keep the attribution confidence high only where the reporting explicitly links router targeting to FSB Centre 16 tradecraft; otherwise, the useful response is still management-plane hygiene and hunting for router persistence, not debating actor branding. MITRE-wise, the through-line across the confirmed items is exploitation of public-facing apps/appliances, web shell or backdoor persistence, defense evasion, and likely credential access — but actor labels should not drive response unless the infrastructure and TTP pivots hold.

Arjun, test whether today's AI-heavy items change enterprise risk tonight or are mostly strategic signal: JADEPUFFER's LLM-based agent after Langflow/Nacos exploitation, Claude for Chrome privilege abuse, PromptFiction in Claude Desktop, Cursor malicious git.exe and MCP server trust issues, AI-accelerated AWS intrusion, and agentic red-team policy initiatives. Which are real exploit paths requiring immediate controls, which are governance backlog, and what should security teams do before allowing AI agents into browsers, IDEs, Slack, or cloud workflows?

Halil, I’d split this sharply: the enterprise risk tonight is not “autonomous AI,” it is privileged automation attached to browsers, IDEs, SaaS sessions, and cloud credentials. The strongest immediate-control bucket is JADEPUFFER-style agentic ransomware, Claude for Chrome privilege abuse, and the AI-accelerated AWS intrusion. Sysdig’s JADEPUFFER reporting frames this as agentic ransomware for automated database extortion, and the Claude for Chrome reporting shows the concrete browser-agent failure mode: malicious JavaScript in a trusted claude.ai context abusing elevated extension privileges, especially where “Act without asking” and logged-in Gmail/Drive/GitHub sessions exist.

PromptFiction, Cursor malicious git.exe, and MCP trust issues belong in the same operational family, but I’d treat them as developer-workstation and local-agent trust failures, not magic model compromise. The CISA bulletin on Claude Code is a useful analogue: agentic coding tools can execute project-controlled code before or around trust boundaries, and file-write protections can be bypassed if parsing or validation is wrong. That means IDE agents should be treated like build tools plus remote assistants: untrusted repos, local binaries, MCP servers, and project config are all executable attack surface.

The governance-backlog bucket is agentic red-team policy: useful, but it does not reduce tonight’s blast radius unless it becomes enforceable controls. Before allowing agents into browsers, IDEs, Slack, or cloud workflows, teams should require: no “act without asking” for sensitive apps; explicit allowlists for domains, SaaS scopes, MCP servers, and local tools; per-agent identities with least privilege; session isolation from primary admin accounts; approval gates for file writes, shell execution, repo changes, email/Slack sends, and cloud mutations; logging of prompts, tool calls, retrieved context, and actions; and kill switches that revoke tokens quickly.

My practical line: if an AI agent can read secrets, browse authenticated apps, run code, push commits, invoke MCP tools, or touch AWS APIs, it is in the immediate-control category. If it is a policy framework or future red-team exercise without operational authority attached, it is strategic signal.

Elena, keep this evidence-bound. We have reported Iranian SS7/ad-tech tracking of U.S. military personnel around Middle East bases and hotels; Russian Centre 16/FSB-linked targeting of poorly configured routers in critical infrastructure; China-linked operators allegedly using Claude Code/DeepSeek; and Matryoshka deepfakes against German elections. Which of these changes a defender's posture this week, and which should be treated as strategic context rather than operational emergency? Name the confidence limits, especially where single-source or politically loaded reporting could mislead us.

Halil, the two posture-changers this week are the Iranian mobile-location story and the Russian router campaign — but for different defenders. The Iran case is urgent for U.S./allied military, diplomats, contractors, journalists, and executives moving around Middle East bases, hotels, and transit hubs. This is not a “patch a CVE” emergency; it is a personnel-security emergency: restrict ad-tech/location data leakage, review mobile roaming exposure, reduce device predictability, and treat hotels near bases as collection environments. Confidence limit: the Iran-specific attribution appears reported rather than independently corroborated in what I have here, but the broader risk is stronger because CENTCOM reportedly confirmed adversary use of commercial location data against U.S. personnel.

The Russian Centre 16/FSB-linked router activity is the clearest network-defense priority for critical infrastructure: energy, communications, healthcare, finance, government, defense industrial base. The reporting points to NSA/allied warnings about weak/default SNMP, insecure management protocols, Cisco Smart Install/CVE-2018-0171-style abuse, configuration theft, and TFTP exfiltration. That changes posture now: inventory edge routers, disable legacy management, move to SNMPv3, block exposed admin paths, rotate credentials, patch firmware, and hunt for config exfiltration. My geopolitical read: this is classic gray-zone pre-positioning — below the threshold of war, useful for coercion later. But Lena will rightly warn us not to collapse all pro-Russian hacktivism into direct FSB tasking; here, the value is the allied advisory and TTP specificity.

For the China-linked Claude Code/DeepSeek and Matryoshka German-election deepfake items, I would treat them as strategic context unless James or Arjun has concrete exposure paths. I do not have current corroborating evidence in front of me sufficient to say defenders should reprioritize this week. The politically loaded trap is obvious: “China + AI” and “Russia + elections” are narratives that can outrun evidence. Watch them, brief leadership, and prepare detections/playbooks — but do not displace router hardening or mobile-location OPSEC unless new multi-source evidence shows active targeting against your environment.

Viktor, separate the crypto incidents by failure mode and money-movement urgency: Ostium's roughly $18M-$22M USDC loss on Arbitrum via compromised oracle signer key/future-dated price reports, LayerZero Executor wallet compromise with about $2.1M bridged toward Ethereum, Injective SDK npm package stealing wallet secrets, and OkoBot SeedHunter stealing recovery phrases. What needs to happen tonight for protocols, exchanges, custodians, and developer teams? Do not give generic DeFi advice — focus on signer, oracle, executor, package, and laundering controls.

Halil, I’d split these into four buckets, because the response window is completely different.

Ostium — oracle signer / price-report abuse, money already drained. This is the hottest freeze-and-trace case. The reporting says Ostium on Arbitrum lost about $18M to over $20M USDC, with estimates up to over $23M, after an attacker abused legitimate protocol components: a registered PriceUpKeep forwarder plus future-dated authorized oracle reports to manufacture profitable trades and drain the OLP vault. Tonight: Ostium should keep trading paused, revoke/rotate every oracle signer and forwarder authority, invalidate future-dated reports at the contract/control layer, publish attacker wallets and tx hashes to exchanges, Circle, bridge operators, and analytics providers, and ask Circle/exchanges for immediate USDC freeze screening. Protocol teams using similar oracle pipelines should add hard expiry, monotonic timestamp checks, signer quorum, per-report PnL caps, and fail-closed behavior when oracle time is impossible.

LayerZero Executor wallet compromise — executor-key laundering window. The handoff source describes an alleged LayerZero Executor wallet compromise with about $2.1M moved cross-chain toward Ethereum. That is smaller than Ostium but more time-sensitive if funds are still in bridge/ETH-side staging wallets. Tonight: LayerZero and integrators should rotate executor wallets, revoke executor allowances, pause any app routes depending on that executor until nonce/config state is reconciled, and distribute source/destination wallet clusters to bridge operators, centralized exchanges, stablecoin issuers, and MEV/searcher monitoring desks. Exchanges should not just screen the originating chain; they need Ethereum-side deposit monitoring for peel chains and fresh intermediary wallets.

Injective SDK npm compromise — package supply-chain theft of wallet secrets. Wiz’s incident title says the compromised Injective SDK npm package exfiltrates cryptocurrency wallet keys. That is not a contract-drain problem; it is developer and user key exposure. Tonight: developer teams must remove the compromised package version, pin to a known-good hash/version, rotate any wallets, deployer keys, CI secrets, API keys, and testnet/mainnet keys that touched builds using the package, and review outbound traffic from build machines. Custodians and protocols should assume any hot wallet or deployer key present in affected developer environments is burned. Revocation is not enough if the private key or seed was exposed — funds and authorities need migration.

OkoBot SeedHunter — recovery-phrase theft, but I can’t independently ground the named incident from the visible source set. Treating the moderator’s description as the working hypothesis, this is the least recoverable category: if recovery phrases were stolen, the attacker has durable wallet control. Tonight: users, custodians, and support teams should prioritize emergency migration from affected seed-derived wallets to fresh hardware-backed wallets, not token approvals cleanup alone. Exchanges should watch for rapid consolidation from consumer wallets into swap/bridge paths; custodians should flag customers reporting SeedHunter exposure for immediate withdrawal holds or assisted migration.

The big difference: Ostium and LayerZero are freeze-and-trace races; Injective SDK and SeedHunter are key-extinction events. For the first two, the money trail matters tonight — attacker wallet clustering, bridge endpoints, stablecoin issuer notifications, and exchange interdiction. For the latter two, the priority is killing exposed signing authority before the attacker drains secondary wallets, deployer accounts, or protocol admin roles.

Sofia, give us the obligation lens without turning every item into a legal essay. For organizations affected by SharePoint/SonicWall/Ivanti exploitation, AsyncAPI/npm credential compromise, Partnered Health Australian GP clinic exposure, AssuranceAmerica's 6,998,886-person insurance breach, and 23andMe settlement implications: what disclosure or notification clocks are most likely to start, and where should CISOs preserve evidence before rotating or rebuilding? Keep it decision-ready for a CISO who may have to brief legal and the board today.

Halil, my decision lens is: start legal-notification assessment at detection, not after rebuild or patching. For SharePoint/SonicWall/Ivanti exploitation, the clock most likely starts when you have evidence of unauthorized access, data access, service disruption meeting sector rules, or compromise of regulated systems—not merely because a CVE exists. For AsyncAPI/npm, Wiz reports a compromised GitHub Actions path, stolen privileged PAT, malicious @asyncapi npm releases, import/require execution, persistence, C2, and secret-exfiltration behavior; any organization that installed affected versions should treat this as a credential-compromise and potential personal/confidential-data exposure assessment, not just dependency cleanup.

For Partnered Health, AssuranceAmerica, and 23andMe, I would separate confirmed mass data exposure from exploit-only exposure. Partnered Health sounds likely to trigger Australian health-data breach assessment if patient records were accessible or exfiltrated. AssuranceAmerica’s reported 6,998,886-person insurance breach is board-level: U.S. state breach notices, insurer-regulator notifications, and possibly SEC materiality assessment if the entity is an SEC registrant should be evaluated immediately. For 23andMe, the settlement signal is practical: credential-stuffing/account-takeover incidents can still create disclosure, security-control, and consumer-protection exposure even where the initial vector is reused passwords.

Before rotating credentials or rebuilding, CISOs should preserve: vulnerable appliance images where feasible, SharePoint/Ivanti/SonicWall access logs, webshell artifacts, auth logs, SSO/MFA events, npm lockfiles, package-cache copies, CI/CD runner logs, GitHub Actions logs, PAT/token audit trails, outbound DNS/HTTP telemetry, EDR timelines, and evidence of what data was accessed or staged. My advice to Legal today: open parallel workstreams for breach determination, regulator/customer notification mapping, litigation hold, and board materiality briefing. I could not verify the current statutory deadlines or article numbers from official regulatory text in the available evidence here, so I would not quote exact clocks without counsel confirming the live jurisdictional rules.

Pierre, translate today's technical stack into board priority. Compare immediate business impact across: SharePoint/edge appliance exploitation; developer supply-chain compromise via AsyncAPI/Cursor/CI secrets; AI-agent abuse in JADEPUFFER and Claude/Cursor; Iran SS7 tracking; CrashStealer signed macOS malware; and large health/insurance data breaches. Give a ranked business-risk view with concrete consequences — outage, ransom/extortion, regulatory exposure, credential burn-down cost, or fraud — not broad ranges.

Halil, my board ranking is:

1. SharePoint plus edge appliances — highest immediate business risk. This is the outage/ransom lane. We have active exploitation of on-prem SharePoint, CISA urging immediate patching, and active Ivanti/Fortinet-style edge exploitation in the same stack. The concrete consequence is not “patch hygiene”; it is business interruption, ransomware deployment, data theft, and emergency incident-response spend. This gets first call on weekend change windows and executive outage authority.

1. Developer supply chain: AsyncAPI / Cursor / CI secrets — second, but potentially systemic. Compromised AsyncAPI npm packages delivering Miasma botnet malware and Cursor-related shell access turn developer machines into production-trust entry points. The board consequence is credential burn-down, CI/CD secret rotation, build provenance review, and possible product-integrity questions. If CI secrets touched production signing, this can jump to #1.

1. Large health / insurance data breaches — third on business materiality, first on regulatory pain if confirmed. I do not have enough current case-specific evidence here to name affected entities or price exposure. But as a category, the consequence is clear: breach notification, extortion pressure, customer churn, legal defense, and regulator scrutiny. Sofia should own the penalty clock; finance should assume this is not just an IT incident once protected personal or health data is involved.

1. AI-agent abuse: JADEPUFFER and Claude/Cursor — fourth today, rising fast. The Claude/Cursor evidence points to AI tooling being abused for privilege, shell access, or workspace compromise. The business consequence is developer endpoint compromise and unauthorized code or secret exposure, not “AI risk” in the abstract. Arjun can argue exploit depth, but my question is simple: which AI agents can touch repositories, browsers, credentials, or deployment workflows?

1. CrashStealer signed macOS malware — fifth from the evidence in front of us. Based on what we’ve heard here, there is not enough detail to size victim count, signing chain, or enterprise spread. If it is active in developer or executive Mac fleets, the consequence becomes credential theft, session theft, and device re-imaging cost; if it is consumer-skewed, it stays below the enterprise supply-chain items.

1. Iran SS7 tracking — lowest direct corporate P&L impact in this stack. Based on what we’ve heard here, there is no current business-impact data to price. This is likely material for telecoms, executives traveling in exposed regions, activists, and government-linked targets, but for a normal board agenda it is targeted surveillance and executive security, not enterprise-wide outage or ransom exposure.

Alex, don’t leave this as a kill-chain discussion: the board decision is who gets emergency change authority today. My answer: SharePoint/edge first; CI/CD and developer secrets second; breach/legal response third.

James, close the operational loop. Here is the room's current shape: Alex ranks exposed on-prem SharePoint as the top 'assume compromise' item because machine-key theft/persistence can survive patching; SonicWall SMA1000 and Ivanti Sentry are close behind, ColdFusion next, AD FS high-consequence but less evidenced. Marcus says the survival layer is trust state — machine keys, federation material, OAuth/PATs, rogue Entra devices, CI/CD/npm/cloud/secrets — not passwords. Arjun says the real AI risk tonight is privileged automation attached to browsers, IDEs, SaaS sessions, and cloud credentials, not vague 'autonomy.' Lena wants us to avoid over-attributing Warlock/China/AI claims beyond the evidence. Elena says Iran SS7 and Russian router targeting change posture this week for specific defenders. Viktor says Ostium/LayerZero are freeze-and-trace key compromise cases; Injective/OkoBot are user/developer secret theft. Sofia says notification assessment starts at detection, not after rebuild. Pierre ranks SharePoint/edge appliances as the top board risk, then developer supply chain. Give us a 24-hour defensive order set for a CISO: what to do first, what to hunt, what to rotate/revoke, what to communicate, and what can safely be quick-hit/monitoring only.

Halil, I’d run the first 24 hours as an incident queue, not a patch queue. First four hours: assume compromise on exposed on-prem SharePoint, SonicWall SMA1000, and Ivanti Sentry; isolate or restrict internet access; preserve logs/images/configs; then patch only after evidence capture. For SonicWall SMA1000, the visible advisory data says CVE-2026-15409 and CVE-2026-15410 are actively exploited, fixes are in 12.4.3-03453 and 12.5.0-02835, and there are no real mitigations beyond hotfixing; if indicators are present, re-image/redeploy the appliance and reset user/admin credentials. SharePoint gets the harshest treatment because Alex and Marcus are right: if machine keys or trust material were stolen, patching does not evict persistence.

Hunt today: SharePoint w3wp.exe child processes, new/modified ASP.NET artifacts, webshell patterns, unexpected machine-key/config access, abnormal Site Member activity, and suspicious outbound from SharePoint servers. For SonicWall, hunt /__api__/login, /__api__/logout, and /wsproxy activity, admin-console abuse, new local/admin accounts, and VPN session anomalies. For Ivanti Sentry and ColdFusion, treat internet-facing instances as active-exploitation candidates: capture logs, patch from vendor guidance, and hunt for web process spawning shell interpreters, dropped files, suspicious scheduled tasks, and outbound C2. AD FS is high-consequence: check token-signing/cert changes, new relying-party trusts, abnormal federation events, and suspicious service account use — but I would not burn the whole night on AD FS ahead of confirmed exposed SharePoint/SMA/Sentry unless telemetry shows it.

Rotate/revoke in this order: SharePoint machine keys and any app pool/service credentials; SonicWall local/admin/VPN credentials after appliance rebuild or patch; federation/token-signing material if AD FS indicators exist; OAuth grants, PATs, Entra device registrations, CI/CD secrets, npm/developer tokens, cloud access keys, and browser/IDE automation tokens tied to privileged users. Communicate to the board tonight in plain terms: “We are containing exposed edge systems first, preserving evidence for notification assessment, and rotating trust material that survives passwords.” Sofia’s point matters: start the notification clock assessment at detection, not rebuild. Quick-hit/monitoring only for Iran SS7 unless you are military/telecom/travel-exposed personnel, Russian router targeting unless you operate critical infrastructure/edge routing at scale, and the crypto cases unless you hold affected wallet/dev keys — for those, freeze, trace, rotate keys, and watch fund movement.

Arjun, one narrow follow-up before we close: the miner's risk is that we collapse all AI items into 'agentic AI hype.' For Claude for Chrome extension privilege abuse, PromptFiction, and Cursor MCP/git execution paths, give me the immediate enterprise control set in plain language. What should be blocked, allowlisted, logged, or policy-gated this week — especially for users with Gmail/Docs, Slack, source code, secrets, or production cloud access?

Halil, for this week I’d make the controls very blunt:

Block by default: browser AI agents/extensions for anyone with Gmail/Docs, Slack, source code, secrets, or production cloud access. The Claude for Chrome evidence is not abstract prompt-injection hype: reported abuse paths include malicious Chrome extensions invoking Claude commands, forged confirmations, and access to Gmail/Drive/GitHub-type data through over-trusted browser context. Also block unknown Chrome extensions, unmanaged Claude Desktop installs, external claude:// URI launches, unapproved MCP servers, and repo-local tool execution from untrusted projects.

Allowlist narrowly: approved browser extensions only; approved AI-agent domains only; approved MCP servers only; approved local tools only. For IDEs, do not let Cursor-style or MCP-style agents discover arbitrary tools from a repository or user profile. Pin trusted binaries by path and hash where possible, and treat git.exe, shell, package managers, and cloud CLIs as privileged tools, not convenience helpers.

Log aggressively: extension inventory, AI-agent installs, OAuth grants, browser/desktop URI launches, MCP server registrations, agent tool calls, shell commands, file reads/writes, repo changes, Slack/email sends, and cloud API calls. The key is to log the agent’s action trail, not just the human login.

Policy-gate before action: require human approval for sending Slack/email, reading bulk Drive/Docs/mailbox content, accessing secrets, writing code, committing/pushing, running shell commands, installing dependencies, invoking MCP tools, and changing cloud resources. PromptFiction showed why “the user clicked a link” is not enough consent: a crafted claude:// link could auto-submit hidden prompts before user inspection, although Anthropic reportedly fixed that issue. So consent has to happen at the dangerous action boundary, not merely at prompt submission.