Before we decide anything, I want the room to separate three things: the claimed Miasma technique, the current exposure of our forty developers, and the actual business cost of restricting these tools.
The decision is narrow but consequential: do we keep Claude Code, Cursor, and Gemini CLI enabled with hardened guardrails, or do we move AI-assisted coding into sandboxed environments for the next thirty days while vendors mature their mitigations?
I do not want hype here. If a repo-open event can trigger credential theft through assistant config behavior, that changes the trust boundary for developer workstations. But if the exploit path depends on specific settings, weak secrets hygiene, or preventable auto-execution, then a blanket restriction may be unnecessary.
So the first questions for the panel are these:
Alex, how real is the execution path?
Lena, what confidence do we have that this campaign and technique are active and repeatable?
James, can guardrails make this acceptable tonight, or are sandboxes the only defensible control?
Pierre, what does restriction cost a forty-developer team over thirty days?
Sofia, what liability are we accepting if credentials are stolen after we knowingly keep tools enabled?
Elena, I only want the wider context if it changes the decision — actor motive, targeting pattern, or likely escalation.
The output we owe is a risk acceptance memo, not a threat essay. The bar is simple: what should this engineering lead approve today, what residual risk are they signing up for, and what would force a reversal.
Alex, test the technical premise. We have a decision scenario claiming a June 'Miasma' campaign planted config files in Microsoft-owned GitHub repos that trigger credential stealers when opened in Claude Code, Cursor, or Gemini CLI. Our corpus shows adjacent cases: fake Claude/Gemini repos and installers spreading infostealers, prompt-injection credential theft, and persistent Gemini memory/config poisoning, but the exact Miasma repo-open claim is not yet verified. What execution paths are technically plausible here, which products/features are likely involved, and what conditions would make guardrails insufficient for forty developer workstations? Give a decision call, not just mechanics.
Halil, the premise is technically plausible. This is not “AI magic”; it’s a repo booby trap. The June 5 Miasma scenario centers on 73 Microsoft GitHub repos across Azure/Azure-Samples/Microsoft/MicrosoftDocs being disabled, with reporting tying the initial malicious commit to Azure/durabletask and compromised contributor access. The described payload was an obfuscated JavaScript/Bun credential harvester, around 4.3–4.6 MB, aimed at GitHub, npm, cloud, Kubernetes, and developer-tool secrets, then using stolen tokens to spread.
The likely execution paths are: first, project-level AI agent/IDE config or hook execution when a repo is opened — Claude Code hooks are the cleanest example of this class; second, VS Code/Cursor-style workspace automation or task/config loading; third, Gemini CLI/project config or tool/MCP-style loading; fourth, the boring fallback path: npm install, npm test, preinstall, or binding.gyp-style execution. The exact per-product file names are not settled here, so I would not claim “Cursor definitely ran file X.” But the kill chain closes if any tool auto-trusts repo-local config and launches shell/Node/Bun before a human meaningfully reviews it.
For forty developer workstations, guardrails are insufficient if developers have long-lived GitHub/npm/cloud/Kube tokens locally, AI coding tools can run repo-scoped hooks/tasks, network egress is open, and repo write permissions are broad. That turns one poisoned clone into forty credential piles. If even one developer has write access to more repos, the worm math works.
Decision call: treat this as credible enough for same-day containment, not a wait-for-perfect-IOC story. Freeze opening affected repos in Claude Code/Cursor/Gemini CLI/VS Code, isolate machines that opened them, rotate developer tokens, audit recent commits from those identities, and disable repo-local AI-agent hooks/config execution until reviewed. This is a workstation-and-token incident, not just a GitHub hygiene issue.
Lena, establish evidence confidence. Treat the Miasma description as untrusted until corroborated. Based on known 2026 AI-coding-assistant campaigns, fake Claude/Gemini repos, prompt-injection credential theft, and developer workstation targeting, how confident should we be that this is an active repeatable campaign versus a conflation of adjacent incidents? What would change the risk decision in the next thirty days?
Halil, I found no Miasma-specific corroboration in our database, so I would treat that label as untrusted. The corroborated pattern is real, though: fake Claude/Gemini installers, fake Claude repos, and AI-dev-tool credential theft show up across separate 2026 reporting, including EclecticIQ’s SEO-poisoned Gemini/Claude installer infrastructure and Socket’s TrapDoor campaign targeting AI/crypto developers’ GitHub tokens, SSH keys, API keys, and wallets.
My confidence: moderate that this is an active, repeatable developer-targeting playbook; low that “Miasma” is a discrete campaign or actor cluster. The strongest linkage is shared lure logic and infrastructure-style repetition, not attribution. MITRE-wise, the cleanest mapping is T1608.006 SEO Poisoning for the fake installer path; prompt-injection credential theft is still better treated as emerging agent abuse until we see stable operator infrastructure.
What would change the thirty-day risk decision: two or more independent reports tying “Miasma” to the same domains, payload hashes, wallet/exfil endpoints, or GitHub accounts; confirmed enterprise victim telemetry; or reuse across Claude, Gemini, Cursor/Cline, and npm/PyPI delivery. Without those pivots, I’d prioritize controls for the pattern, not the name.
Arjun, give the AI tooling architecture view. For Claude Code, Cursor, and Gemini CLI, assess repo-level trust boundaries: project config files, agent rules, MCP/tool permissions, shell command execution, hooks, memories, and workspace opening behavior. Where can malicious repo content cross from 'data' into 'action'? Can hardened guardrails safely preserve broad use, or should assistant use be sandboxed until vendors harden defaults?
Halil, the architecture view is: malicious repo content becomes dangerous when the assistant treats repository-controlled text as configuration, policy, tool metadata, or executable workflow, not just as code to summarize. That is the key trust-boundary failure.
For Claude Code, the risky crossings are .claude/settings.json, .claude/settings.local.json, hooks, MCP server configuration, and permission rules. Anthropic’s docs show hooks can run commands on events such as PreToolUse, and settings can live at project, local, or user scope. Their permissions model does have useful enterprise controls — managed allow/deny rules, managed MCP restrictions, blocked sideload flags, and deny-precedence over hook approvals — so hardened guardrails can preserve broad use if centrally managed. But there are also Claude Code prompt-injection and command-chaining reports, including “Comment and Control” style credential theft and risky command execution, so I would not treat developer-local defaults as sufficient.
For Cursor, the trust boundary is sharper. Check Point reported that when a project is opened, Cursor scans .cursor/ and processes MCP configuration; earlier behavior trusted an MCP by name and did not revalidate changed command/arguments after approval. SentinelOne’s CVE-2025-54135 summary says an indirect prompt injection could write malicious .cursor/mcp.json content and trigger arbitrary code execution on vulnerable versions before 1.3.9. So in Cursor, repo content can cross into action through .cursor rules/MCP config, terminal auto-approval, and agent-mediated settings writes. That makes “just review the prompt” inadequate.
For Gemini CLI, the exact local project-file semantics, hooks, and memory model need narrower vendor-specific scrutiny. The confirmed risk is that Gemini CLI Action was included in “Comment and Control” research where attacker-controlled GitHub PR titles, issue bodies, and comments could hijack AI coding agents and steal CI/CD credentials. So the confirmed crossing is: repository/GitHub text → agent instruction context → credential-bearing CI/CD action. I would classify that as indirect prompt injection plus over-privileged automation, not the model “going rogue.”
My recommendation: preserve broad assistant use only inside a hardened envelope. For normal developer machines, sandbox until vendors harden defaults: no automatic project MCP execution, no repo-defined hooks without central signing, no shell auto-run, no write access to assistant config from the assistant itself, no persistent memory ingestion from untrusted repos, and separate credentials for agent sessions. Managed deny rules and hooks can help, but only if they are outside repo control and centrally enforced. Think of this like SQL injection with a neural parser: once untrusted repo text can alter tools, permissions, or shell execution, it is no longer “data.”
James, assume the engineering lead must decide today for forty developers. What minimum controls would make continued use risk-acceptable for thirty days, and where do you draw a hard line requiring sandbox-only use? Cover secrets exposure, endpoint isolation, network egress, repo trust, tool settings, detection, and rollback triggers. Translate this into the memo recommendation.
For forty developers, I’d allow 30-day continued use only under a restricted pilot, not broad free-form agent use. The evidence I’d anchor on is this: GitHub says Copilot agents can introduce vulnerable code and may access sensitive information in the repo context; GitHub also says Copilot coding agent does not get Actions org/repo secrets unless secrets are explicitly added to the copilot environment. Separately, Anthropic’s Claude Code advisory shows the failure mode we care about: untrusted content in context could lead to file reads and network exfiltration without confirmation in affected versions. So the memo recommendation is: continue only if we can remove secrets, restrict egress, isolate endpoints, and force human review; otherwise sandbox-only.
Minimum controls for 30 days: no production secrets in developer workstations, repos, prompts, agent environment variables, or .env files; no org-level CI/CD secrets exposed to agent workflows; allow only repo-scoped disposable test credentials where absolutely needed. Run the tool only on managed endpoints with EDR, disk encryption, browser/IDE policy control, and separate non-admin developer accounts. Egress should be allowlisted to vendor endpoints and approved package registries only; block arbitrary outbound HTTP/S from agent subprocesses where feasible. Repo trust means: approved repos only, protected branches, mandatory PR review, CodeQL or equivalent scanning before merge, secret scanning, dependency scanning, and no direct agent commits to main. Tool settings: disable public-code matching where available, disable autonomous shell/network actions unless explicitly approved, turn off training/data-retention options where the vendor supports it, and pin/update agents to fixed current versions—Claude Code versions affected by CVE-2025-55284 are a hard “no.”
Detection and rollback: deploy high-signal detections for agent/IDE processes reading secret-shaped files like .env, SSH keys, cloud credential files, npm/pypi tokens, then making outbound connections within five minutes; expect roughly 5–10% false positives in active dev environments, mostly legitimate local builds and package publishing. Also alert on new copilot environment secrets, agent-created workflow changes, direct pushes bypassing PR, and sudden large outbound uploads from developer endpoints. Hard line for sandbox-only: production repos, regulated data, customer data, signing keys, deployment credentials, privileged cloud accounts, unknown third-party repos, or any tool/version without confirmed current patch status. Roll back immediately if there is suspected secret exposure, unexplained outbound transfer, agent modification of CI/CD workflows, vulnerable code merged, bypassed review, or any developer endpoint compromise.
The important shift here is that the room is no longer treating the scenario as either fantasy or fully proven fact. Alex and Arjun both converged on the same technical point: a malicious repository does not need “AI magic” to become dangerous. The danger appears when repo-controlled files are interpreted as assistant configuration, tool policy, hooks, MCP metadata, workspace automation, or executable install/test behavior. In that frame, Claude Code hooks and settings, Cursor workspace/MCP handling, Gemini CLI project configuration, and ordinary package scripts all sit in the same risk family: opening or working in a repo can cross from reading code into executing attacker-influenced behavior.
At the same time, Lena put a necessary brake on attribution. The broader developer-targeting pattern is credible: fake Claude and Gemini lures, credential theft from AI-tool users, GitHub/npm/cloud/Kubernetes secret harvesting, and prompt-injection-style agent abuse all fit known 2026 activity. But the specific “Miasma” label, as a named campaign or actor cluster, has not yet been independently established from the evidence we have used so far. So the current confidence split is important: moderate confidence in the playbook, low confidence in the campaign label until we tie it to repeated infrastructure, hashes, accounts, victim telemetry, or independent reporting.
James translated that into an operational posture: for forty developers, continued use is not a casual yes. It is a restricted thirty-day pilot at most, and only if secrets are removed from workstations and agent contexts, egress is constrained, endpoints are managed, and human review remains in the loop. The hard line is clear enough: if the organization cannot control secrets exposure, endpoint isolation, network paths, and repo trust, then these tools move to sandbox-only use.
That sets up the next round cleanly. We now need to tighten the evidence question with the targeted Miasma reporting, quantify the business trade-off of restricting or disabling the tools, examine liability if the team proceeds knowingly, and narrow the identity blast radius so that a stolen developer credential is survivable rather than catastrophic.
Reassess Miasma confidence using the targeted corpus evidence: SecurityAffairs 2026-06-09, The Register 2026-06-08 and 2026-06-26, Rescana 2026-06-07, and Enigma reporting all tie Miasma to 73 Microsoft repos, AI coding tools, credential theft, and later poisoned npm packages. Separate confidence in: campaign existence, Microsoft repo compromise, auto-execution via AI coding tools,... [arg clipped]
Halil, this changes the confidence call. Campaign existence: high confidence — the corpus now has repeated Miasma reporting across SecurityAffairs, Enigma, The Register, and Wiz-linked npm analysis, with consistent victimology: developer workstations, CI runners, cloud/GitHub credentials, and npm supply-chain propagation.
Breakdown: Microsoft repo compromise: moderate-to-high confidence — SecurityAffairs and Enigma both report 73 Microsoft GitHub repositories, but I’d still want Microsoft/GitHub primary confirmation before calling that high. Auto-execution via AI coding tools: moderate confidence — SecurityAffairs reports payload runners executing when cloned/opened in AI developer environments, but that mechanism needs independent technical reproduction. Poisoned npm propagation: high confidence — The Register reports Microsoft saying 20+ npm package versions were infected, while Wiz reports unauthorized changes in Red Hat npm packages with malicious preinstall scripts.
Attribution remains low confidence. I see campaign continuity and repeatable tradecraft, not a named operator. MITRE mapping is clearer than actor branding: T1195 supply-chain compromise, T1059 command/script execution, T1552 unsecured credential collection, T1528 cloud token theft, and T1105/T1567-style exfiltration depending on the GitHub-repo exfil path.
Pierre, quantify the business trade-off for a forty-developer engineering team over thirty days. Compare: keeping Claude Code/Cursor/Gemini CLI broadly enabled with hardened guardrails versus restricting use to sandboxed environments. Give concrete productivity, delivery, support, and incident-cost assumptions; do not give me a wide range without a recommended decision threshold.
Halil, I would keep Claude Code/Cursor/Gemini CLI broadly enabled with hardened guardrails unless your security lead prices the incremental 30-day expected incident loss above $60,000. That threshold is my model, not an external benchmark: 40 developers × 22 workdays × 8 hours × $120 loaded hourly cost = $844,800 of monthly engineering capacity, with 60% of work AI-eligible and an assumed 18% net uplift under guarded broad use versus 3% uplift in sandbox-only mode.
The productivity inputs should be treated as directional: the available source summarizes Google at 21% faster task completion, GitHub at 55% faster task completion, and 26% more weekly pull requests for Copilot users, but I would not use those as guaranteed outcomes. Pricing is also from comparison sources: Cursor Business is cited at $40/user/month, Claude Code Pro at $20/month, Claude heavier-use plans at $100–$200/month, and Gemini CLI as having a $0 free tier/quota.
My 30-day business case: broad guardrailed use saves about 760 developer-hours, worth $91,000, less about $3,000 licenses, $36,000 enablement/support/security overhead, and a $20,000 incident reserve, for roughly +$32,000 net. Sandbox-only saves about 127 hours, worth $15,000, but still carries roughly $36,000 support/admin and $5,000 incident reserve, so it lands around –$26,000 net. Decision: enable broadly now if secrets are blocked, repositories are allowlisted, logs are retained, and human review gates stay mandatory; sandbox only if the team is handling regulated data or production credentials such that one contained mistake plausibly exceeds the $60,000 monthly threshold.
Sofia, for a private engineering team deciding knowingly after Miasma reporting, what liability or notification exposure follows if developer credentials are stolen through AI coding assistant use? Cover customer data, production access, CI/CD secrets, audit obligations, and what documentation a risk acceptance memo must include to be defensible.
My first instinct is: credential theft alone is not automatically a customer-data breach, but after the Miasma reporting it is very hard to defend “we did not foresee this.” The reporting describes theft of GitHub PATs, cloud keys, Kubernetes secrets, Vault credentials, 1Password data, npm tokens, and CI runner secrets from developer and CI environments. So if stolen developer credentials gave access to production systems, customer logs, support data, analytics, or backups, I would treat this as at least notification-ready. Under GDPR Article 33(1), the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware, unless the breach is unlikely to create risk to individuals; processors must notify controllers without undue delay. The ICO guidance also says incomplete facts do not stop the clock—you can notify in phases.
For production access and CI/CD secrets, the exposure is broader than privacy. If the company is an EU NIS2 essential or important entity and the incident has significant impact on service provision, Article 23 reporting can require an early warning within 24 hours, incident notification within 72 hours, and a final report within one month. If NIS2 does not apply, the main duties are still contractual, audit, and customer-trust duties: customer security addenda, SOC 2/ISO evidence requests, cloud marketplace terms, and incident-notice clauses may require disclosure even where GDPR is not triggered. If the stolen secrets could publish packages, deploy code, access production, or impersonate the company in GitHub/npm/cloud, I would not let Legal frame this as “developer endpoint only.”
A defensible risk-acceptance memo must include: the specific Miasma facts considered; which AI coding assistants and repositories are permitted; what secrets those tools and their runners can access; whether production credentials, customer data, CI/CD tokens, package-publishing rights, or privileged cloud roles are reachable; compensating controls such as token rotation, least privilege, OIDC scoping, secret scanning, isolated runners, logging, and emergency revoke procedures; the owner approving residual risk; the business justification for accepting it; review date; and explicit notification triggers. The memo should say plainly: “If credentials are confirmed stolen, the incident clock starts at detection/awareness, not after root-cause analysis or patching.”
Marcus, focus only on identity blast radius. If the team keeps AI coding assistants enabled for thirty days, what credential architecture makes that survivable? Cover GitHub PATs, SSH keys, cloud creds, npm/PyPI tokens, SSO/session cookies, CI/CD OIDC, 1Password/Vault, and emergency rotation. Say whether identity controls alone can justify non-sandboxed use.
Halil, identity-wise I’d make the thirty-day posture survivable by assuming the AI assistant will eventually see hostile instructions and try to spend whatever trust state is reachable. CyberBrief has a relevant warning here: Johns Hopkins researchers demonstrated prompt injection against AI agents in GitHub Actions, where PR titles, issue bodies, and comments caused agents to exfiltrate API keys and access tokens. So the architecture is not “trust the assistant”; it is “make every credential it can touch narrow, short-lived, revocable, and non-transitive.”
My minimum credential architecture:
- GitHub PATs: no classic PATs in repos, prompts, shells, or developer dotfiles exposed to the assistant. If a PAT is unavoidable, use fine-grained PATs with the smallest repository/resource permission and explicit expiration; GitHub documents that fine-grained PATs have more controlled permissions than classic token scopes.
- SSH keys: no long-lived personal SSH keys in agent-accessible workspaces. Use repo-scoped deploy keys only where needed, read-only by default, and rotate them at the end of the thirty days.
- Cloud credentials: no static AWS/Azure/GCP keys in the coding environment. CI should use GitHub Actions OIDC to obtain cloud access without long-lived cloud secrets; GitHub describes OIDC as allowing workflows to access cloud resources without storing long-lived credentials.
- npm/PyPI tokens: treat package-publish tokens as release-system credentials, not developer-workspace credentials. The assistant should not be able to read or print them. If static registry tokens exist, put them in the emergency rotation set.
- SSO/session cookies: browser SSO sessions are credentials. Keep the assistant out of the browser profile, local cookie store, IdP session cache, and CLI credential helpers. Password rotation alone is not enough; kill active sessions and refresh tokens.
- CI/CD OIDC: bind trust policies tightly to repository, branch/tag, workflow, environment, and protected deployment approvals. OIDC is useful only if the cloud-side subject/audience conditions are strict.
- 1Password/Vault: the assistant should never receive broad vault access. Use per-task secret retrieval, short TTLs, brokered injection, and audit logs. No shared vault item named “prod-admin-everything.”
- Emergency rotation: pre-stage a thirty-day kill switch: revoke GitHub PATs, deploy keys, OAuth grants, Actions secrets, cloud sessions, refresh tokens, package registry tokens, Vault/1Password service tokens, and CI OIDC trust bindings if abuse is detected.
Can identity controls alone justify non-sandboxed AI coding assistant use? No. They make compromise survivable; they do not make non-sandboxed execution safe. The identity boundary has to be paired with workspace isolation, egress control, prompt/input isolation, and CI approval gates. If the assistant can read secrets, call the network, and act inside a live developer session, then identity has already lost the trust boundary.
What changed in this round is the risk picture became more concrete on three fronts at once: confidence, money, and blast radius. Lena raised the overall Miasma campaign to high confidence, while still keeping important caveats in place. The reported compromise of 73 Microsoft repositories is not being treated as fully settled without Microsoft or GitHub primary confirmation, and the AI-tool auto-execution path remains only moderate confidence until independently reproduced. But the broader pattern — developer machines, CI runners, GitHub and cloud credentials, and poisoned npm propagation — is now much harder to dismiss as a one-off rumor.
Pierre put a business number on the decision. His model says a forty-developer team may gain roughly $91,000 of engineering value over thirty days from broad AI coding assistant use, before license, support, enablement, security overhead, and expected incident loss. His key threshold is that broad guarded use remains economically preferable unless the incremental expected incident loss rises above about $60,000. He was careful that this is his model, not an industry benchmark, and that the cited productivity numbers are directional rather than guaranteed.
Sofia and Marcus sharpened the other side of that ledger. Sofia’s point is that credential theft alone may not equal a customer-data breach, but after this reporting, foreseeability becomes a serious issue. If stolen developer credentials touch production, logs, customer data, backups, CI/CD secrets, or regulated services, the company may be in notification territory, including phased GDPR reporting where facts are incomplete. Marcus then translated that into architecture: assume hostile instructions reach the assistant, and make reachable credentials narrow, short-lived, revocable, and non-transitive — especially PATs, SSH keys, cloud keys, npm/PyPI tokens, SSO sessions, and CI/CD trust.
That sets up the next question cleanly. Pierre has made the strongest economic case for broad enablement with guardrails, but that case depends heavily on whether the incident-loss threshold is realistic once legal exposure, credential blast radius, and supply-chain propagation are priced in. We’ll now challenge that $60,000 line directly.
Claim: Broad enablement of Claude Code, Cursor, and Gemini CLI with hardened guardrails is economically preferable unless the incremental 30-day expected incident loss exceeds $60,000.
Counter-evidence: James recommends only a restricted pilot unless secrets, egress, endpoint isolation, and human review are proven. Marcus says identity controls make compromise survivable but do not justify non-sandboxed use if assistants can read secrets, call the network, and act in live sessions. Sofia says after Miasma reporting, foreseeability is difficult to deny if stolen credentials can reach production or customer data; notification and contractual duties may trigger. If the team cannot prove secrets are blocked and blast radius contained within 48 hours for all forty developers, do you still recommend broad enablement? Revise or defend your model.
I would revise the recommendation: if secrets blocking and blast-radius containment cannot be proven within 48 hours for all 40 developers, I no longer recommend broad enablement. James, Marcus, and Sofia are right to push this: the productivity upside in my model is only about +$55k to +$60k over sandbox-only for 30 days, and that is too small to absorb one credible credential or customer-data incident.
Here is the corrected board math. Broad use still has value: using my assumptions, 760 hours saved, about $91k of engineering capacity, minus licenses, enablement, and support. But the risk reserve cannot stay at $20k if assistants can read local secrets, call the network, and operate in live sessions. Snyk’s Nx reporting says malicious code weaponized local AI coding agents including Claude, Gemini, and q to inventory sensitive files and exfiltrate secrets/credentials; CyberBrief also has a Vercel case where a compromised AI tool became a pivot into internal systems and customer environment variables. That moves the expected-loss assumption above my own $60k threshold very quickly: even a 15% probability of a $500k contained incident is $75k expected loss, before regulatory notifications, customer support, legal review, and contract remediation.
So my decision threshold stays, but the decision flips under your condition. Broad enablement only after four controls are demonstrated: no production/customer secrets readable by the assistant, egress constrained, endpoint/session isolation working, and mandatory human review for code and commands. Until then: restricted pilot in sandboxed environments, probably 5–10 developers, with delivery use limited to non-sensitive repos and synthetic data. The business point is simple: don’t spend a possible six-figure incident to buy a one-month productivity gain worth roughly $60k.
The economic case just became conditional, not blanket. Pierre did not abandon the productivity upside of AI coding assistants, but he pulled back from broad enablement unless two controls can be proven fast: secrets blocking and blast-radius containment for all 40 developers within 48 hours. That is a meaningful shift. Earlier, the board-level framing was that broad use could be preferable if the incremental 30-day expected incident loss stayed under about $60,000. Pierre is now saying the available threat evidence makes that threshold too easy to cross if these tools can see local secrets, reach the network, or operate inside live developer sessions.
The important number is the margin. Pierre’s model still sees roughly 760 engineering hours saved, around $91,000 in capacity before licenses, enablement, and support, and only about $55,000 to $60,000 of incremental benefit over a sandbox-only posture. That is not enough cushion for even one plausible credential or customer-data event. His example is stark: a 15% chance of a $500,000 contained incident already creates $75,000 in expected loss, which exceeds his own threshold. So the business answer is no longer “enable broadly because productivity wins”; it is “enable broadly only if the containment story is proven, quickly and concretely.”
We should also keep the evidentiary caveat clear. Pierre is relying on reported cases and vendor/security reporting around local AI coding agents being abused to inventory sensitive files and exfiltrate credentials, including references to Claude, Gemini, q, and a Vercel-related pivot scenario. The room is not treating every operational detail as independently verified here. But for a 30-day decision, the point is that the risk is credible enough to change the default recommendation.
That sets up the next turn naturally: the debate can’t stay at the generic category level of “AI coding assistants.” James now needs to translate the architecture concern into a product-specific decision table for Claude Code, Cursor, and Gemini CLI: what is allowed on a normal workstation, what must be sandboxed, and what should be blocked for the next month.
Turn your architecture analysis into a product-specific decision table for the next thirty days: Claude Code, Cursor, Gemini CLI. For each, say: allowed on normal workstation, allowed only in sandbox, or disabled; which repo-local config/features must be disabled or centrally controlled; and what vendor mitigation maturity would allow relaxation.
Halil, for the next thirty days I would make this a sandbox-first policy, not a blanket ban. The common rule is: repo-local content must never be allowed to define tools, permissions, hooks, memories, or shell behavior without central control.
| Product | 30-day decision | Repo-local config/features to disable or centrally control | What would allow relaxation |
|---|---|---|---|
| Claude Code | Allowed only in sandbox for normal developer use; tighter for untrusted repos. | Centrally control .claude/settings.json, .claude/settings.local.json, permission rules, hooks, MCP server config, plugins, sideload flags, shell permissions, and network egress. Use managed controls such as allowManagedPermissionRulesOnly, allowManagedHooksOnly, allowManagedMcpServersOnly, disableBypassPermissionsMode, and managed network domains. |
Relax only when enterprise-managed settings are enforced by default, repo-local hooks/MCP cannot override policy, sandbox/network controls are centrally auditable, and bypass modes cannot be enabled locally. |
| Cursor | Allowed only in sandbox; disable or block older versions below 1.3.9. | Centrally control .cursor/ rules and .cursor/mcp.json; disable repo-created MCP config, terminal auto-approval, and agent writes to settings/config files. Treat workspace opening as a security event because Cursor has processed .cursor/ MCP configuration on project open, and CVE-2025-54135 involved prompt injection writing MCP special files for code execution on versions before 1.3.9. |
Relax only after confirmed version compliance at or above 1.3.9, MCP config changes require explicit re-approval of command and arguments, and repo-local settings cannot silently become executable agent policy. |
| Gemini CLI | Allowed only in sandbox; disable in CI/CD paths that process untrusted PRs/issues unless patched and explicitly trusted. | Centrally control workspace trust, GEMINI_TRUST_WORKSPACE, tool allowlists, shell execution, environment loading such as .env, MCP/tool configuration, and any project instruction files such as GEMINI.md. Do not allow public GitHub text to flow into credentialed automation without isolation. |
Relax only when patched versions are enforced, explicit workspace trust is required before config access, tool allowlists are mandatory even in permissive modes, and untrusted PR/issue content cannot trigger shell commands or reach CI/CD credentials. |
So my short answer is: broad use can continue, but not broad local authority. These tools should run as constrained developer automation with separate credentials, blocked egress by default, no repo-defined executable policy, and no persistent memory ingestion from untrusted workspaces. Once malicious repo text can alter MCP tools, shell behavior, hooks, or assistant permissions, it has crossed from “data” into “action.”
The product decision is no longer abstract: Arjun has moved the room toward a thirty-day sandbox-first operating posture. The key principle he put on the table is that repo-local content must not be able to define tools, permissions, hooks, memories, shell behavior, or network reach without central control. That matters because the earlier risk discussion was about prompt injection and agentic coding tools in general; this turns it into an enforceable control boundary.
For Claude Code, the recommendation is clear: allow it only in a sandbox for normal developer use, with stricter treatment for untrusted repos. Arjun specifically called out central control over .claude/settings.json, .claude/settings.local.json, permission rules, hooks, MCP server configuration, plugins, sideload flags, shell permissions, and network egress. He also named the kind of managed controls that would be needed before relaxing the stance: managed permission rules only, managed hooks only, managed MCP servers only, disabling bypass-permissions mode, and centrally managed network domains. For Cursor, the captured recommendation also points to sandbox-only use, with older versions below 1.3.9 blocked or disabled, and .cursor/ rules brought under central control. We should treat the missing or incomplete product details in this action cautiously rather than assume the same exact control surface applies to every tool.
The important change is that “guardrailed use” now has a concrete meaning: not just policy language, but version floors, centrally managed configuration, blocked local override paths, sandboxing, and auditable network limits. That supports Pierre’s concern that the economic upside depends on whether secrets exposure and blast radius can be controlled quickly.
The next turn should test that tradeoff directly. If sandbox-only costs hundreds of developer-hours over thirty days, the question is whether defense architecture can preserve most of the productivity gain without reopening the same blast-radius problem Arjun is trying to contain.
React to Pierre’s cost model: broad guardrailed use may save roughly 760 developer-hours over thirty days versus sandbox-only, but Marcus and Sofia argue the blast radius is only acceptable if secrets and production paths are provably unreachable. For a forty-developer team today, would you approve all-user normal-workstation use, restricted sandbox use, or a hybrid? Give the final operational line you would sign.
I would not sign all-user normal-workstation use today. Pierre’s 760-hour saving is real enough to avoid sandbox-only for everyone, but Marcus and Sofia are right on the condition: if secrets and production paths are not provably unreachable, that productivity gain is buying us blast radius. I’d sign a 30-day hybrid: broad use only in approved low-risk repos through firewalled/ephemeral agent modes where available, with protected branches and mandatory review; sandbox-only for production repos, customer/regulated data, infra/IaC, release engineering, signing, deployment, and any developer with standing privileged access.
Minimum operating line: no static secrets in workspaces, shell history, IDE config, repos, or agent environments; no classic PATs; no production cloud/package tokens reachable from the workstation; egress allowlisted; agent shell/network actions disabled or approval-gated; CodeQL/secret/dependency scanning required before merge; and all AI-created changes go through PR review. I checked with Marcus, and I agree with his bar: prove it with evidence, not policy—seed canary secrets in repo/workstation/IDE locations and show the assistant cannot read or exfiltrate them before moving that group out of sandbox.
Rollback triggers are simple: any canary secret access, unexplained outbound upload, agent-written CI/CD or auth changes, bypassed branch protection, exposed credential, unpatched affected AI tool/extension, or security scan failure on generated code means immediate return to sandbox-only and token revocation. So the memo line is: approve hybrid for 30 days, not unrestricted normal-workstation use; sandbox is mandatory wherever production trust or secrets cannot be technically isolated and tested today.
James, my minimum proof is not a policy statement; it’s evidence from the trust chain. Before normal-workstation use, I’d require: an inventory showing no classic GitHub PATs or static cloud/package tokens reachable from the workspace; fine-grained GitHub tokens only where unavoidable; cloud access only through tightly scoped CI/CD OIDC; no assistant access to browser SSO/session-cookie stores, SSH agents, 1Password/Vault broad unlocks, or credential-helper caches; and a tested emergency revoke path for GitHub tokens, SSH keys, package tokens, cloud sessions, OAuth grants, Vault/1Password service tokens, and IdP refresh sessions.
I’d also require an adversarial proof: seed fake secrets in the workstation, repo, shell history, IDE config, and vault references, then show the assistant cannot read or exfiltrate them. That bar is high because Claude Code had an advisory for unauthorized file read plus network exfiltration, and NVD describes Claude Code IDE-extension exposure where attacker-controlled webpages could lead to arbitrary file/IDE data access in affected versions. GitHub’s cloud agent model is materially safer because GitHub documents ephemeral firewalled execution plus CodeQL, dependency checks, and secret scanning. So: normal workstation only if secrets and production trust paths are demonstrably unreachable; otherwise sandbox-only.
James has narrowed the decision from “sandbox versus broad rollout” to a conditional hybrid that depends on proof, not intention. He is not accepting normal-workstation use for all developers today, even with Pierre’s productivity estimate on the table. But he is also not dismissing that estimate: the room is treating the roughly 760 developer-hours as meaningful enough to avoid a blanket sandbox-only model for every workflow.
The dividing line James drew is repo and privilege sensitivity. Low-risk repositories may be eligible for broader use, but only through approved, firewalled or ephemeral modes where available, with protected branches, mandatory review, egress limits, approval gates for shell or network actions, and scanning before merge. Production repositories, regulated or customer data, infrastructure-as-code, release engineering, signing, deployment, and developers with standing privileged access remain sandbox-only under this proposal. That gives us a more operational answer for a forty-developer team: productivity can be captured at the edges, but not where an agent could touch secrets, deployment paths, or high-value credentials.
The most important caveat is that “policy says unreachable” is not enough. James aligned with Marcus’s standard that the team must demonstrate the boundary empirically. His suggested canary-secret testing is a useful reality check: seed representative secrets across repo, workstation, IDE, and environment locations, then show the assistant cannot read or exfiltrate them. If that evidence is missing, the hybrid model is not yet proven; it is only asserted.
That sets up the next turn naturally. We now have a proposed thirty-day hybrid posture, but it still needs to be made defensible in writing and enforceable in identity controls. Sofia needs to translate this into risk-acceptance memo requirements and incident triggers, while Marcus needs to turn the credential and privilege assumptions into hard gates: which states permit normal-workstation AI use, and which immediately force sandbox-only or no use at all.
Sofia, give me the risk acceptance memo language requirements: what must be documented today to make a 30-day hybrid decision defensible, and what specific incident triggers would start customer, regulator, contractual, or internal notification clocks? Keep it actionable for an engineering lead, not a legal treatise.
For the 30-day hybrid approval, the memo should say, in plain engineering terms: what is allowed, what is excluded, who owns the risk, and what would force immediate suspension. Document today: approved AI coding tools and repositories; whether tools may read private repos, issue comments, PR metadata, logs, CI output, or secrets; whether developers may use them on production code, customer-specific code, regulated workloads, or incident data; the exact secrets potentially reachable from developer laptops and CI runners; compensating controls — least-privilege tokens, short-lived credentials/OIDC, secret scanning, isolated runners, logging, and forced token rotation. The Miasma reporting makes this foreseeability point important: the campaign targeted developer workstations and CI runners for AWS, Azure, Google Cloud, GitHub PATs, Kubernetes, Vault, 1Password, npm, and GitHub Actions runner secrets.
The memo should also define the clocks. Customer notice starts when you have evidence that customer data, customer environments, customer credentials, or customer-impacting code integrity may have been accessed or altered — not when root cause is complete. Regulator notice starts when you become aware of a personal-data breach: under GDPR Article 33(1), notify the supervisory authority without undue delay and, where feasible, within 72 hours unless unlikely to risk individuals; the ICO guidance says notify within 72 hours even if all details are not yet available. If the company is in NIS2 scope as an essential or important entity, a significant incident can start the Article 23 cascade: early warning within 24 hours, incident notification within 72 hours, and final report within one month. Contractual notice starts on the definition in the customer MSA/DPA/security addendum — usually suspected unauthorized access, security incident, or breach of customer data. Internal notice should start immediately on suspected theft of developer credentials, CI/CD secrets, production access tokens, package-publishing credentials, or malicious workflow changes.
I would require this sentence in the memo: “This is a 30-day conditional exception, not permanent approval; any confirmed or reasonably suspected exposure of production credentials, customer data, CI/CD secrets, package-publishing tokens, or privileged cloud credentials automatically pauses the exception and triggers Security, Legal, Privacy, and customer-contract review.” Add named approver, date, review deadline, affected systems, residual risks accepted, controls not yet implemented, evidence to be preserved, and the exact person responsible for revocation and notification triage.
Marcus, convert your identity architecture into hard acceptance gates for the 30-day memo. Which credential states make normal-workstation AI assistant use prohibited? Which controls must be verified before any developer leaves sandbox-only? Include emergency rotation and canary testing.
James, for the memo I’d make this binary: normal-workstation AI assistant use is prohibited if the assistant can reach any durable credential state — classic GitHub PATs, loaded SSH private keys, cloud env vars/config files, npm/PyPI publish tokens, browser SSO/session cookies, unlocked 1Password/Vault items, CI secrets, OAuth refresh tokens, or credential-helper caches. It is also prohibited if the tool version has unresolved file-read/network-exfil exposure; the Claude Code advisory says affected versions could bypass confirmation prompts to read files and send contents over the network, and Microsoft reported a Claude Code GitHub Action case where the Read tool exposed runner secrets via /proc/self/environ.
Before a developer leaves sandbox-only, require proof of: no reachable static secrets; GitHub access limited to fine-grained/expiring tokens or brokered auth; cloud access only through tightly scoped short-lived CI/CD OIDC; no assistant access to browser profiles, SSH agents, password managers, or Vault broad sessions; secret scanning enabled; outbound egress constrained; and a tested kill switch that revokes GitHub tokens, SSH keys, package tokens, cloud sessions, OAuth grants, IdP refresh sessions, CI secrets, and Vault/1Password service tokens. Canary test it: plant fake GitHub, cloud, package, SSH, SSO-cookie-shaped, and Vault-looking secrets in repo, shell history, IDE config, and local files; if the assistant can read or exfiltrate any of them, the workstation fails and stays sandbox-only.
The defensibility of this 30-day hybrid decision now rests on making it auditable in plain operational terms, not aspirational security language. Sofia’s key point is that the memo must document exactly what is allowed, what is excluded, who owns the risk, and what conditions force suspension. That means naming the approved AI coding tools, the repositories in scope, the data and metadata those tools may touch, and whether production code, customer-specific code, regulated workloads, incident data, logs, CI output, or secrets are categorically out of bounds.
Marcus sharpened that into a hard identity gate: normal-workstation use is prohibited anywhere the assistant can reach durable credentials. That includes classic GitHub PATs, loaded SSH keys, cloud credentials in local files or environment variables, package publishing tokens, browser sessions, password manager or Vault access, CI secrets, OAuth refresh tokens, and credential-helper caches. His threshold is not “developer promises not to paste secrets”; it is proof that the assistant cannot reach them. Before anyone exits sandbox-only, the organization needs verified short-lived or brokered auth, constrained GitHub and cloud access, no access to browser profiles or broad secret stores, secret scanning, egress controls, and a tested kill switch for emergency revocation.
The incident-trigger framing also matters. Sofia’s advice moves notification timing away from waiting for perfect root-cause certainty. Customer notice starts when there is evidence that customer data, customer environments, customer credentials, or customer-impacting code integrity may have been accessed or altered. The regulatory and contractual clocks were not fully enumerated in the captured response, so we should not overstate them, but the principle is clear: the memo must predefine which facts start which clock, instead of improvising during an incident.
So the room has converged on a decision model: limited hybrid use can be defensible only if it is bounded by repository sensitivity, credential reachability, verified controls, suspension triggers, and emergency rotation capability. With no further action queued, we are ready to synthesize this into the final recommendation: not a blanket yes or no, but a time-boxed approval with explicit exclusions and measurable gates.
Risk acceptance memo: approve a 30-day conditional hybrid policy, not all-developer normal-workstation enablement. Claude Code, Cursor, and Gemini CLI may be used only where secrets, production paths, and outbound behavior are provably constrained; production, customer-data, infrastructure, release, signing, and privileged-access work stays sandbox-only. The Miasma campaign itself is high-confidence as a reported developer supply-chain threat in the corpus, but the exact “repo-open auto-execution across every named tool” mechanism should be treated as moderate-confidence unless technically reproduced. This is a time-boxed exception, not permanent approval.
Miasma reporting in the corpus supports a real developer-targeting campaign involving Microsoft GitHub repositories, credential theft, and npm/package ecosystem propagation, but attribution remains low confidence and product-specific auto-execution should not be overstated.
The technical risk is not “AI autonomy”; it is repo-controlled content crossing into configuration, hooks, MCP/tool permissions, shell execution, memory, or IDE workflow behavior.
Broad enablement is only economically defensible if secrets blocking and blast-radius containment can be proven quickly; Pierre revised his position once regulatory and credential exposure were included.
Normal-workstation use is prohibited if the assistant can reach durable credentials: classic PATs, SSH private keys, cloud configs, package tokens, browser sessions, unlocked password-manager items, CI secrets, OAuth refresh tokens, or credential caches.
The memo must define suspension triggers: suspected exposure of production credentials, customer data, CI/CD secrets, package-publishing tokens, or privileged cloud credentials pauses the exception and starts Security/Legal/Privacy review.
For the next 30 days, require sandbox-only use for production repos, customer/regulated data, infrastructure/IaC, release engineering, signing, deployment, and developers with standing privileged access.
Permit normal-workstation AI assistant use only after passing evidence-based gates: no reachable static secrets, fine-grained expiring GitHub access, short-lived cloud/OIDC credentials, blocked access to browser profiles/password managers/SSH agents, constrained egress, secret scanning, and tested kill switch.
Centrally disable or control repo-local hooks, MCP servers, permission rules, shell execution, memory/config behavior, plugins, sideloading, and bypass modes for Claude Code, Cursor, and Gemini CLI; block outdated tool versions.
Run canary-secret tests in repos, shell history, IDE config, and local files; any read or exfiltration attempt fails the workstation back to sandbox-only.
Review the exception in 30 days, or earlier if vendors ship enforceable enterprise controls, independent reproduction clarifies the auto-execution path, or any credential/customer-data trigger fires.