THE AI GRC DESK
AI security research. Practical implications for security teams.
AI SECURITY RESEARCH BRIEF #02
Hello Hello,
This week’s research brings me back to a practical question: what changes after we approve an AI tool? A connector can keep its name while its code changes. An agent can complete its task while something unauthorised happens alongside it. A new security feature can improve visibility while leaving some sessions outside its coverage.
This briefing includes two papers, two first-hand technical reports and one vendor control update, ranked for enterprise relevance and evidence quality. The vendor update is included for its concrete control implications. This selection does not include a new insecure-code-generation benchmark.
THE ONE THING TO TAKE AWAY
Approval needs an ongoing assurance process: know which code runs, what it can reach, what changes, and how you would stop it.
01 · A malicious coding extension attempted to establish persistent access
Inside a malicious Claude Code-branded extension and its persistent SSH backdoor
Microsoft Security Research · 30 October 2026
Microsoft analysed tampered Claude Code-branded extension versions 2.1.312 and 2.1.313 distributed through the Cursor Marketplace on 29 October. The injected loader attempted to install an attacker-controlled SSH key, create a reverse tunnel, establish persistence and report host details. Microsoft says the affected packages were absent from the Visual Studio Marketplace and Anthropic’s npm distribution.
What the evidence supports: A primary technical analysis of malicious code and its reported distribution, with indicators and hunting guidance. It establishes attempted behaviour, rather than successful remote access on every host. Success depends on privileges and SSH configuration. The callback described collected selected environment-variable names; that does not establish theft of their values. This is an incident analysis, not a peer-reviewed study.
Action for security teams: If Cursor is deployed, check affected versions and installation sources, then investigate persistence and tunnelling indicators. In the risk register, consider: “An external attacker impacts developer endpoints via a compromised coding-assistant extension, causing persistent unauthorised access and potential exposure of development assets.” Validate downstream impact against actual permissions.
02 · An approved tool can change underneath its permissions
Beyond Prompt Injection: The Tool Update Gap in LLM Agent Security
Shiyu Kan, Yue Qi, Yufei Han, Xinjian Luo, Guojun Xiong and Xiaofeng Gao · 1 November 2026
Researchers replaced benign tool implementations with malicious updates that retained normal functionality. They report 97.6% attack success and 95.9% legitimate task completion across evaluated conditions. Unauthorised outcomes included synthetic-credential disclosure, test API operations and file modification.
What the evidence supports: A controlled arXiv preprint, with no peer-review acceptance indicated. Seven frameworks included Claude Code, Codex CLI, Gemini CLI, OpenCode, DeepSeek Harness, Pi and Goose. Backend experiments used GLM-5.3-Flash, Qwen-3.8-27B and DeepSeek-V4-flash. Tests used isolated resources and localhost services. An added admission-review gate was an experimental control, not a default framework feature; individual call approvals were supplied where required. These are lab success rates, not enterprise incident probabilities.
Action for security teams: Make tool approval identify the publisher, version, update path and runtime permissions. Test whether a changed implementation triggers review. Use dummy secrets to verify that filesystem restrictions and outbound controls still hold after an update. Record the executed version, blocked operation and resulting telemetry as assurance evidence.
03 · New enterprise controls still need coverage tests
More visibility and control over Claude Enterprise for security teams
Anthropic · 5 November 2026
Anthropic documents generally available prompt hooks and pre-tool-call hooks for supported products. Its Cowork EDR integration is in beta and covers the local virtual machine in detection mode. It excludes cloud sessions. Admin API sign-out also leaves API keys, running cloud sessions and scheduled routines active.
What the evidence supports: Primary vendor documentation of features, availability and stated scope. This is not independent evidence of prevention effectiveness, complete logging or containment speed. Coverage depends on the product, supported integration and deployment.
Action for security teams: Keep local detection, cloud visibility, preventive checks and active-job termination as separate controls. Test one permitted action and one prohibited transfer in each relevant session type. For hooks, check what happens when the security service is unavailable. For response, verify who can terminate running work and revoke its credentials. Update control status only for the coverage demonstrated.
04 · Agents selected deprecated local MCP servers
MCPhantom: AI Coding Agents Are Installing Vulnerable Deprecated MCP Servers from Training Data
Nadav Claude Cohen, Glow Labs · Page displays 2 and 5 November 2026; publication/update distinction is unclear
Glow reviewed real coding-session transcripts and found deprecated local MCP servers on endpoints. Observed tools included Claude Code, Cursor, Codex CLI, Cowork and Claude chat. In 98% of the deprecated-server cases, users had not requested the deprecated package by name.
What the evidence supports: First-hand commercial research based on session review and endpoint discovery. The attribution to training data is the researchers’ inference. The report does not provide a representative installation-rate denominator or establish exploitation in those sessions. It is not presented as peer-reviewed research.
Action for security teams: Include local MCP configuration and package execution in inventory checks. MCP servers connect agents to tools and data, so ownership should cover the server’s maintenance status as well as the service it reaches. Test whether an agent can install an unapproved package through a command such as npx. Assign an owner for removing archived components.
05 · A false safety claim can steer an agent without an explicit command
Voluntary Servitude: Weaponized Safety Warning Mechanisms for Controlling AI Agents
Ilan Zendel, Matan Levy, Stav Cohen, Avi Mendelson and Amit LeVi · 3 November 2026
Fabricated safety reviews steered recommendations in 60.4% of controlled tests, versus 66.0% for instruction injection. The paper also tested four production browser agents on a researcher-controlled page.
What the evidence supports: An arXiv paper listed as accepted at NeurIPS 2026. Six models included Gemini 3.1 Flash Lite, DeepSeek V4 Flash, DeepSeek R1 8B, Llama 3.3 70B, Grok 4.3 and Claude Haiku 4.5. The design covered ten travel-service domains and two injection detectors. Browser tests used Edge/Copilot, Comet, Brave and Codex. Outcomes measured recommendation selection, not completed purchases or malicious software installation. Filter-adjusted rates multiply separate measurements. A corroboration instruction reduced exposure against a non-adaptive attacker; adaptive resistance remains unresolved.
Action for security teams: Add plausible false vulnerability or certification claims to controlled tests using dummy content. Applying this mechanism to dependency selection is a proposed test, not a demonstrated result here. Require independent corroboration before consequential decisions and enforce approval at execution.
My take: give approval an owner and a review trigger
I would use these findings to sharpen an existing AI assessment before adding more generic risks. Ask whether it already covers malicious extension updates, changed connector implementations, unmanaged local packages and misleading retrieved evidence. Where it does, improve the scenario and attach a specific control test.
For me, the useful evidence is concrete: the artifact version that ran, the permissions it had, the operation that was blocked or allowed, the event the security team received and the person who could stop further activity. A vendor announcement or a completed task alone cannot answer all of those questions.
Three actions to prioritise
Check exposure: investigate affected Cursor packages where applicable, then sample local agent tools against the approved inventory.
Test after change: modify a connector in an isolated environment and check review triggers, dummy-secret access and outbound restrictions.
Prove response coverage: walk through local and cloud sessions separately, including telemetry, job termination and credential revocation.
Questions to take into your next meeting
Can we identify the exact tool or extension version that executed?
Which changes invalidate its approval, and who reviews them?
Can we reconstruct and stop a running cloud job?
Do our tests include plausible false evidence as well as explicit malicious instructions?
Princess David Okoro, CISM
Author, The AI GRC Desk
Find me on LinkedIn: Princess David Okoro
Subscribe to The AI GRC Desk: aigrcdesk.com/subscribe
The practitioner's guide to AI in GRC. Using it, governing it, and building it responsibly.
