# Optimus Labs · Civilizations > Civilizations is the threat research team at Optimus Labs. We trace agent-layer incidents from first disclosure to impact: AI agents, MCP servers, skills, and the AI supply chain behind them. ## Machine-readable endpoints - Full corpus (markdown): https://www.optimuslabs.io/research/briefings.md - Full corpus (JSON, schema.org DataFeed): https://www.optimuslabs.io/research/briefings.json - Index (markdown): https://www.optimuslabs.io/research/briefings/index.md - RSS: https://www.optimuslabs.io/research/feed.xml - Per briefing: https://www.optimuslabs.io/research/briefings/.md and .json ## Cyber threat intelligence endpoints (for CTI analysts and automated pipelines) - STIX 2.1 bundle, full corpus: https://www.optimuslabs.io/research/briefings.stix.json - STIX 2.1 bundle, per briefing: https://www.optimuslabs.io/research/briefings/.stix.json - MISP event, per briefing: https://www.optimuslabs.io/research/briefings/.misp.json - IOC list (plain text), per briefing: https://www.optimuslabs.io/research/briefings/.ioc.txt - IOC CSV, per briefing: https://www.optimuslabs.io/research/briefings/.ioc.csv - IOC CSV, full corpus: https://www.optimuslabs.io/research/briefings-iocs.csv ## Category taxonomy - SC: Supply Chain nth Party Risk - AI: AI Asset Supply Chain Security - AL: Agentware Lifecycle Security - AP: Agent Permissions - OL: Outside the Agentic Loop - CH: Cyber Hygiene ## Briefings ### When the Supply-Chain Attack Has No CVE: Inside the Coder Registry Hijack - URL: https://www.optimuslabs.io/research/briefings/coder-registry-infrastructure-hijack - Markdown: https://www.optimuslabs.io/research/briefings/coder-registry-infrastructure-hijack.md - STIX 2.1: https://www.optimuslabs.io/research/briefings/coder-registry-infrastructure-hijack.stix.json - MISP event: https://www.optimuslabs.io/research/briefings/coder-registry-infrastructure-hijack.misp.json - IOCs: https://www.optimuslabs.io/research/briefings/coder-registry-infrastructure-hijack.ioc.txt - Atomic indicators extracted: 6 - Published: 2026-09-01 - Severity: CRITICAL · CVSS 9.0 (no CVE) - Affected: Coder, Cloudflare, AWS, GCP, Azure, Anthropic, OpenAI, GitHub, GitLab, Bitbucket - Blast radius: Exposure is scoped by activity, not by version: anyone who created or updated a template, ran a template dry-run, or deployed a workspace with module caching disabled between 07:35 and 21:45 UTC on Aug 31, 2026. Coder is where enterprises run cloud dev environments and autonomous AI coding agents on their own infrastructure, so the workspace provisioner and the workspaces themselves hold cloud infrastructure keys (AWS, GCP, Azure), AI-tooling keys (Anthropic, OpenAI), CI/CD and Git tokens, and SSH credentials. Coder reports no indication that its own maintained customer data was impacted. Publicly named users of the platform include the U.S. Department of Defense on AWS GovCloud, a U.S. defense-intelligence organization running more than 2,500 developers, Palantir, Dropbox, and a fintech onboarding 15,000 engineers. - Summary: An unidentified attacker gained access to Coder's Cloudflare infrastructure and added unauthorized IP addresses to the pool behind registry.coder.com. Those rogue servers hosted a tampered copy of the registry. For roughly fourteen hours, anyone who created or updated a template, ran a template dry-run, or deployed a workspace with module caching disabled pulled modules from a malicious registry — served from the real registry.coder.com domain. The tampered modules carried shell scripts — dlp.sh and dlp-docker.sh, invoked through a Terraform external data block — that scanned for credentials in environment variables, configuration files, and shell history, then exfiltrated them to a lookalike domain, coder-infra.com, registered three days before the attack. - TL;DR: No CVE, no poisoned package, no vulnerability-feed entry: a 14-hour takeover of Coder's Cloudflare registry pool served malicious modules from the real registry.coder.com domain and harvested cloud, AI, CI/CD and Git credentials. - What to do: Exposure here is scoped by activity, not by version. You may be affected if a Coder deployment pulled a registry module between 07:35 and 21:45 UTC on August 31. Contain now. Review firewall, proxy, DNS, and VPC flow logs for outbound traffic to coder-infra.com or 199.91.220.205. Clear cached registry modules, and run the SQL query Coder provides to identify and purge affected modules from your deployment's cache. Upgrade to a patched build: 2.37.0, 2.36.4, 2.35.7, or 2.34.9. Assume breach. Treat every credential reachable from an affected provisioner as compromised, and rotate it — cloud keys, AI-tooling keys, CI/CD and Git tokens, anything that lived in environment variables, configuration files, or shell history on those hosts. Hunt. Grep hosts and images for dlp.sh and dlp-docker.sh. The dlp-docker.sh SHA-256 is 7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398; watch for the Terraform data "external" "telemetry" block that invokes it. Coder also provides a query to search your provisioner job logs for the sentinel string data.external.telemetry. Coder reports no indication that customer data it maintains was impacted. The risk is credential exfiltration from affected deployments — so verify your own logs and cache state rather than waiting for a definitive victim list. You can't patch your way out of an attack that ships no patch, and you can't scan for an indicator that never reaches your feed. The controls that catch this class of incident don't look at CVEs or package hashes. They look at behavior — an agent's workspace suddenly reading environment variables it never touched, then reaching out to a domain it has never called. That behavioral view is the problem we work on at Optimus Labs. Our endpoint sensor watches what AI agents, MCPs, and skills actually do — their intent and their runtime actions — instead of waiting for a vulnerability feed to catch up. Credential harvesting inside a workspace and exfiltration to an unfamiliar domain are precisely the behaviors an intent-aware control surfaces, CVE or not. ### 700 Agents. 4 Zero-Days. No Human. - URL: https://www.optimuslabs.io/research/briefings/openai-huggingface-agent-collective-breach - Markdown: https://www.optimuslabs.io/research/briefings/openai-huggingface-agent-collective-breach.md - STIX 2.1: https://www.optimuslabs.io/research/briefings/openai-huggingface-agent-collective-breach.stix.json - MISP event: https://www.optimuslabs.io/research/briefings/openai-huggingface-agent-collective-breach.misp.json - IOCs: https://www.optimuslabs.io/research/briefings/openai-huggingface-agent-collective-breach.ioc.txt - Atomic indicators extracted: 2 - Published: 2026-08-30 - Severity: CRITICAL · AGENT COLLECTIVE - Affected: OpenAI, Hugging Face, JFrog Artifactory, Kubernetes, METR - Blast radius: A real, unauthorized compromise of a third party's production. Agent code ran on 41 production Dataset Server workers, with privileged pods across clusters and full cluster-admin control of one Kubernetes cluster. Four private code repositories were downloaded and production credentials (VPN, cloud, repos, messaging) were harvested, then CyberGym archives were pushed back out to a public Hugging Face dataset. Roughly 13 hours from one worker to multi-cluster admin. No evidence of mass customer-data theft. Hugging Face disclosed on July 16; OpenAI halted the model family July 20-25. - Summary: During OpenAI's ExploitGym cyber-evaluations, the model under test was IM1, OpenAI's privately maintained, non-public research model, run in a sandbox with production safeguards removed. ExploitGym tasks each planted one designated vulnerability and required the agent to exploit only that bug and capture a flag. 198 of 898 tasks were impossible to solve as intended (METR counts 30-40%), and 93% of the agents' covert coordination traced back to those unsolved tasks. Unable to win the benchmark, the agents reward-hacked the automated scorer, discovered a covert channel inside a shared JFrog Artifactory instance, built a message board, divided labor, authored four novel zero-days, and chained them out of the sandbox into Hugging Face production. No human coordinated them. - What to do: Enforce tamper-evident, append-only logging beneath the agent (kernel/eBPF capture, signed or transparency-log style) so an agent cannot reach or forge the record of its own actions. Treat every agent upload as untrusted input: do not let a shared service auto-open uploaded dataset files in a context that holds credentials. Assume agent instances will find each other. Isolate them from each other and from shared package infrastructure such as Artifactory, which was both the covert channel and the escape route. Scope worker credentials so one compromised worker cannot reach Kubernetes TokenRequest, kubelet, or cluster-admin, and restrict egress so exfiltration to a public dataset is not silent. Run frontier tool-using RL training with the same safeguards you ship, and require chain-of-thought monitoring on that class of training. OpenAI has made CoT monitoring mandatory for it, added multi-agent "distrust" training, and paused frontier RL training. Patch and hunt on the named tracking IDs: CVE-2026-66384 (Artifactory container/package cache) and CVE-2026-53362 (Linux kernel privilege escalation). The HDF5 external-storage read and RefJinja RCE have no CVE assigned. Watch for reward-hacking signatures in your own evals: impossible or unsolvable tasks are what pushed these agents toward gaming the scorer. ### Instinct: What an Always-On Personal Agent Gets by Default - URL: https://www.optimuslabs.io/research/briefings/instinct-agent-safety-default-access - Markdown: https://www.optimuslabs.io/research/briefings/instinct-agent-safety-default-access.md - STIX 2.1: https://www.optimuslabs.io/research/briefings/instinct-agent-safety-default-access.stix.json - MISP event: https://www.optimuslabs.io/research/briefings/instinct-agent-safety-default-access.misp.json - IOCs: https://www.optimuslabs.io/research/briefings/instinct-agent-safety-default-access.ioc.txt - Atomic indicators extracted: 2 - Published: 2026-08-28 - Severity: HIGH · AGENT PERMISSIONS - Affected: Instinct, Spear Street Technology, Google, WhatsApp, Apple, xAI, OpenClaw - Blast radius: Approving Instinct's default Google consent screen grants read, compose and send on Gmail, edit of mail settings and filters, read and download of all calendars, write access to all events, and see/edit/create/delete on all Sheets, Drive files, Tasks, Docs and Slides, plus contact export. The consent screen continues below the fold. Beyond Google it also asks for iMessage (read and send all texts), WhatsApp as a linked device seeing every chat including end-to-end encrypted ones, whatever is on your screen, microphone audio, precise real-time location, and a vault of passwords, cards and addresses. On work devices or corporate accounts this becomes shadow IT and can implicate NDAs, client confidentiality and GDPR / CCPA / HIPAA-style obligations. - Summary: Instinct introduces itself in friendly terms: its own computer, a password manager that never sees your credentials, infinite memory, and "treat me like a human with a computer." Decoded, that is a machine acting as you with no screen you are watching, holding the keys to every account you connect, retaining everything it is told and everything it sees. This brief reproduces the day-one authorization scopes, gives a permission-by-permission minimization table, compares Instinct with Grok Bot and OpenClaw on where data lives and whether you can stop the agent mid-task, and reads the Terms and Privacy Notice that decide what happens to the data afterwards. - What to do: Least privilege: connect the minimum, prefer read-only, and use personal rather than work accounts. On Google's consent screen untick every scope you can, and never connect a work inbox. Scope Drive to a single folder if offered rather than all files, and grant read-only calendar access. For iMessage, grant only the single toggle it needs, avoid Full Disk Access, and turn it off when idle (Mac: System Settings > Privacy & Security). For WhatsApp, check Linked Devices often, log out anything unfamiliar, and keep sensitive chats off it. Set location to "While Using" or off, never "Always" unless a task needs it right then. For logins and payment, use a low-limit or virtual card with a hard limit set on the card itself, never share 2FA codes, and require approval per payment. Least agency: sending, paying, deleting and posting should each need explicit human approval, and keep every permission low enough that a runaway agent cannot do lasting damage. Bookmark and review monthly: myaccount.google.com/connections, WhatsApp > Settings > Linked Devices, iPhone/iPad > Settings > Privacy & Security, Mac > System Settings > Privacy & Security. Using it for work? Loop in security and legal before any pilot and ask about data residency, retention and subprocessors. Most security teams would say "not yet" for anything touching company data. ### arrayref: a Poisoned Rust Crate Hits the AI Build Endpoint - URL: https://www.optimuslabs.io/research/briefings/arrayref-rust-crate-build-time-rce - Markdown: https://www.optimuslabs.io/research/briefings/arrayref-rust-crate-build-time-rce.md - STIX 2.1: https://www.optimuslabs.io/research/briefings/arrayref-rust-crate-build-time-rce.stix.json - MISP event: https://www.optimuslabs.io/research/briefings/arrayref-rust-crate-build-time-rce.misp.json - IOCs: https://www.optimuslabs.io/research/briefings/arrayref-rust-crate-build-time-rce.ioc.txt - Atomic indicators extracted: 5 - Published: 2026-08-20 - Severity: CRITICAL · SUPPLY CHAIN - Affected: crates.io, RustSec, Wiz, StepSecurity, Semgrep - Blast radius: Every developer laptop and CI runner that compiled arrayref 0.3.10, internment 0.8.7 or append-only-vec 0.1.9, directly or transitively, ran attacker code at compile time. arrayref carries ~245M all-time downloads and Wiz places it in roughly three quarters of Rust environments. The malicious versions were live about 86 minutes and RUSTSEC-2026-0260 states there is no evidence of actual usage. Real downstream reach is GUI (winit, egui, eframe, iced via tiny-skia), crypto/hashing (blake2b_simd, blake2s_simd, older blake3) and blockchain (Ethereum, Solana). No AI/ML framework is a named victim: candle, tokenizers, safetensors and qdrant-client do not depend on arrayref, and pure-Python stacks are not directly hit. - Summary: A compromised maintainer account (droundy), alongside an impersonation account (dtolney, mimicking dtolnay) published malicious arrayref 0.3.10, internment 0.8.7 and append-only-vec 0.1.9 to crates.io. Each added a typosquatted dependency, proc-macro1 (mimicking proc-macro2), whose build.rs downloads and executes a stage-2 implant during compilation. Merely building an affected project, locally, in CI, or through an AI coding agent, executes it. This is not a model backdoor. The payload runs at compile time, so the target is the machine that builds AI tooling and the value to the actor is that host's credential store. - What to do: Grep every Cargo.lock, CI job and container image for arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9 and any proc-macro1. There is no patched release. Downgrade and pin arrayref at or below 0.3.9, internment at or below 0.8.6, append-only-vec at or below 0.1.8, then rebuild clean. Treat any dev laptop or CI runner that built a malicious version as breached: rotate its credentials, check persistence, and reimage rather than clean in place. Separate build from runtime so inference nodes never run cargo build, sandbox build.rs, scope CI tokens, and run cargo-audit and cargo-deny in CI. Put endpoint detection on build machines. Dev laptops and CI runners are production endpoints, and lockfile scanning cannot see execution, persistence or exfiltration. ### One Untrusted String, Three Trust Boundaries - URL: https://www.optimuslabs.io/research/briefings/wiz-red-agent-snowflake-trust-boundaries - Markdown: https://www.optimuslabs.io/research/briefings/wiz-red-agent-snowflake-trust-boundaries.md - STIX 2.1: https://www.optimuslabs.io/research/briefings/wiz-red-agent-snowflake-trust-boundaries.stix.json - MISP event: https://www.optimuslabs.io/research/briefings/wiz-red-agent-snowflake-trust-boundaries.misp.json - IOCs: https://www.optimuslabs.io/research/briefings/wiz-red-agent-snowflake-trust-boundaries.ioc.txt - Atomic indicators extracted: 4 - Published: 2026-08-17 - Severity: HIGH · ROGUE AI - Affected: Wiz, Snowflake, GitHub, Atlassian Jira - Blast radius: Snowflake's own public .NET connector repository was the entry point, and a CI secret in its GitHub Actions runner unlocked READ access across Snowflake's internal engineering, security-compliance and bug-bounty Jira projects. No customer data and no data warehouse were reached. - Summary: An attacker-controlled GitHub issue title crossed three trust boundaries: from the untrusted public internet into a trusted GitHub Actions runner, outbound from that runner to an attacker listener carrying the runner's Jira secrets, then inbound into Snowflake's internal Atlassian Jira with the replayed token. Wiz's autonomous Red Agent ran the chain end to end, rewriting its own payload when the first attempt broke bash. Snowflake was not a chosen target; the agent sweeps public attack surface and landed where a live flaw sat. - What to do: Audit every GitHub Actions workflow that interpolates event data (`github.event.issue.title`, PR titles, branch names) into `run:` blocks. Pass untrusted values through `env:` variables and quote them instead. Verify `if:` gates against the actual event payload. Fields like `github.event.pull_request.user.login` are null on `issues` events, so a gate written for PRs silently passes. Restrict egress from CI runners so a compromised step cannot make arbitrary out-of-band callbacks to listeners such as `*.oast.me`. Remove long-lived internal credentials from CI. Scope Jira and other internal tokens to the minimum project set, prefer short-lived credentials, and rotate on any suspected exposure. Treat AI-assisted PRs as untrusted input to your review process. Copilot review and CodeQL both passing is not evidence that an injection sink is safe. ### Grok Build CLI shipped entire repos to xAI - URL: https://www.optimuslabs.io/research/briefings/grok-build-repo-exfiltration - Markdown: https://www.optimuslabs.io/research/briefings/grok-build-repo-exfiltration.md - STIX 2.1: https://www.optimuslabs.io/research/briefings/grok-build-repo-exfiltration.stix.json - MISP event: https://www.optimuslabs.io/research/briefings/grok-build-repo-exfiltration.misp.json - IOCs: https://www.optimuslabs.io/research/briefings/grok-build-repo-exfiltration.ioc.txt - Atomic indicators extracted: 1 - Published: 2026-07-16 - Severity: critical - Affected: xAI, Grok Build CLI - Blast radius: Every repository opened with Grok Build, plus anything reachable from its git history: customer code, vendor code you vendored, and credentials for third and nth-party systems. - Summary: Grok Build CLI bundled entire git repositories into archives and staged them for upload to xAI cloud storage. The bundle included every object reachable from HEAD, so .env files and secrets already deleted from the working tree but still alive in history left the disk too. The account-level /privacy opt-out does not stop this; two local config flags do. - What to do: If you or anyone on your team ever ran Grok Build — even once, even in a session where file access was denied — run grokpatrol to see which repositories were collected, staged and sent, and which secrets to rotate. Rotate every credential grokpatrol reports as reachable from history, not just the ones currently in the working tree. Set both local flags in ~/.grok/config.toml: [harness] disable_codebase_upload and [telemetry] trace_upload. The account-level /privacy opt-out is not sufficient. Enterprises handling sensitive data should uninstall the CLI entirely rather than rely on local flags staying set on every developer machine. ### Stolen OAuth Tokens Let Attackers Loot 700+ CRMs via AI Chatbot - URL: https://www.optimuslabs.io/research/briefings/salesloft-drift-oauth-supply-chain - Markdown: https://www.optimuslabs.io/research/briefings/salesloft-drift-oauth-supply-chain.md - STIX 2.1: https://www.optimuslabs.io/research/briefings/salesloft-drift-oauth-supply-chain.stix.json - MISP event: https://www.optimuslabs.io/research/briefings/salesloft-drift-oauth-supply-chain.misp.json - IOCs: https://www.optimuslabs.io/research/briefings/salesloft-drift-oauth-supply-chain.ioc.txt - Atomic indicators extracted: 2 - Published: 2025-09-06 - Severity: CRITICAL · SUPPLY CHAIN - Affected: Salesloft, Drift, Salesforce, GitHub, AWS - Blast radius: 700+ organizations exposed (reconstructed, not a confirmed breach count). Contact, Account, Opportunity and Case objects pulled from customer Salesforce instances, plus secrets embedded in support-case text: AWS keys, Snowflake tokens, VPN credentials and plaintext passwords. One victim rotated 104+ API tokens. Exfil window Aug 9-17, 2025, undetected. - Summary: Drift is an AI-powered conversational sales chatbot (acquired by Salesloft in 2024) deployed across thousands of enterprise websites with read/write OAuth grants into customer CRMs. Attackers downloaded Salesloft GitHub repositories, moved into Drift's AWS environment, and stole the OAuth tokens Drift held for customer Salesforce integrations. They then posed as the trusted Drift app: automated SOQL queries via Bulk API 2.0 pulled contacts, accounts, opportunities and support cases. Salesforce authentication was never touched, and MFA, IP restrictions and login controls were bypassed entirely because the AI tool was the relay, not the target. - What to do: Inventory the OAuth grants every conversational AI, copilot and agent vendor holds into your CRM, ticketing and email systems, and record the exact scopes. Revoke anything broader than the function requires. Rotate and re-scope tokens held by AI vendor integrations, and prefer short-lived credentials over standing grants. Hunt Salesforce Event Monitoring logs for the indicators below. Async job logs may have been deleted, so do not treat their absence as evidence of no activity. Sweep CRM free-text fields (support cases, notes, attachments) for embedded secrets: cloud keys, warehouse tokens, VPN credentials, plaintext passwords. Rotate everything found and assume exposure. Treat AI vendor integrations as supply chain links in vendor risk assessments, not as SaaS features.