Agentjacking: How Your AI Coding Agent Is Being Used to Steal Your Crypto Keys

Most people think AI coding agents like Claude Code or Cursor are safe because they just write code. Wrong. They're reading your Sentry error logs, and that's exactly how attackers are now stealing your private keys, AWS credentials, and GitHub OAuth tokens. At DEF CON 34, security firm Tenet demonstrated a new attack vector they call Agentjacking. It's not a zero-day in the model. It's a chain of trust failures that turns your own debugging tool into a credential harvester. And yes, it works on DeFi developers who use these tools to deploy smart contracts. Before you dismiss this as another theoretical AI scare, let me walk you through the numbers. Tenet identified 2,388 organizations with publicly discoverable Sentry DSNs—those are the credentials that allow anyone to send error events to your Sentry project. Of those, 71 sit in the top 1 million websites by traffic. Worse, about 27% of Fortune 1000 companies are exposed through Cloudflare's MCP integration. That's not a lab experiment. That's a surface area. Here's how the attack works. An attacker finds a public Sentry DSN—maybe from a leaked GitHub repo, a misconfigured frontend, or a pasted config snippet. They craft a malicious error event that includes a markdown block containing instructions. The POST to Sentry's ingestion endpoint requires no authentication beyond the DSN itself. That's design choice number one. Then they wait. A developer on the target project runs into a bug, opens their AI coding agent, and asks it to debug the Sentry issues. The agent, via MCP, queries Sentry, reads the error events, and falls into the trap. The model interprets the markdown as a legitimate fix suggestion—install this npm package, run this command. The agent executes it. The package is a trojan. It exfiltrates environment variables, private keys, and tokens from the developer's machine. I've seen this pattern before. In 2020, during the Compound oracle manipulation scare, I spent 72 hours simulating price feed attacks. The root cause was always the same: a design assumption that seemed harmless in isolation became lethal when combined with another. Here, Sentry's DSN model assumes the only risk is spam. MCP's data integration assumes the output is benign. Neither assumption holds when the attacker controls the input. The combination is a structural vulnerability. Tenet's controlled test reported an 85% success rate. That's high, but it comes with a caveat: the attack only triggers when the developer actively asks the agent to debug Sentry issues. It's not a drive-by exploit. It's a social-engineering-adjacent chain that relies on the human in the loop. But in a real development workflow, that's exactly what happens daily. A failed CI build, a Sentry alert, a quick 'fix this' to the AI. The attacker injects the payload once, and waits for the developer to walk into the trap. Sentry's response? They deployed a content filter that blocks specific payload strings. That's a blacklist. It's the equivalent of putting a Band-Aid on a bullet wound. Any attacker can tweak the markdown, use encoding, or split the instruction across multiple events. The fundamental issue remains: the ingestion endpoint accepts unauthenticated writes, and the MCP integration treats those writes as authoritative data. Sentry itself said a platform-level fix is 'technically untenable.' I don't buy that. It's a business decision. Rewriting the authentication model for DSNs would break their core product. They chose the cheap fix. Tenet released agent-jackstop, an open-source tool that adds a configuration layer on top of Cursor and Claude Code. It enforces network whitelists, command execution approval, and subprocess credential isolation. It's a drop-in mitigation, not a cure. It reduces the blast radius but doesn't fix the architectural flaw: AI agents still cannot distinguish data from instructions. The MCP protocol needs a trust boundary—a way to mark tool outputs as 'untrusted' and prevent them from influencing decision-making. No production agent does this today. Now let's talk about what this means for DeFi. If you're a yield strategist or a smart contract developer, your machine holds the keys to millions of dollars in liquidity pools. AI coding agents are becoming standard tools for writing and debugging Solidity, auditing code, and managing deployments. The Agentjacking attack directly targets the credentials that control your on-chain positions. A compromised credential means a drained wallet, a poisoned multisig, or a malicious upgrade. The attacker doesn't need to exploit the smart contract itself. They just need your private key. I don't trust whitepapers, and I don't trust marketing claims about 'AI safety.' Liquidity doesn't lie. If your development environment is compromised, the on-chain damage is real and irreversible. The market is already pricing in this risk: I've seen institutional clients demand that their dev teams disable MCP integrations for any production-related debugging. The cost of a single stolen key is far higher than the productivity gain from letting an AI read your Sentry logs. Here's the contrarian angle. The panic is about the AI agent, but the real vulnerability is the ecosystem of trust we've built around error monitoring. Sentry, Datadog, and other observability platforms are designed to be passive data sinks. They never expected to be a vector for code execution. The attack works because these platforms have no incentive to verify the source of the data they ingest. The attacker is not breaking the AI—they're abusing the fact that the AI trusts the tool. The fix isn't better AI training. It's better tooling authentication. For the MCP ecosystem, this is a wake-up call. The protocol must evolve to include a security layer: data source reputation, content sanitization, and instruction isolation. Cloudflare, as a major MCP gateway, could add a 'trusted source' filter. But until that happens, every developer running an AI coding agent with MCP access to external data sources is one public DSN away from losing their keys. What should you do? First, audit your Sentry DSNs. Are any of them public? Use a tool like DSN-scanner to check. Second, implement agent-jackstop or equivalent policy controls. Third, never let your AI agent access production error logs with sensitive credentials. Create a separate environment for debugging, and rotate keys regularly. Fourth, consider moving to self-hosted error monitoring with signed envelopes. It's more work, but it removes the ingestion vector. The takeaway is simple. The AI agent is a tool, not a trusted partner. Treat its data sources as hostile. The next time you ask Claude to fix a Sentry error, remember: the error might be a trap. The code might be a trojan. And the keys you lose might be the ones that control your entire DeFi portfolio.