Automated Exploit Validation: Your AI Agent vs a Real $107K DeFi Hack

We gave a coding agent a single contract address and asked it to do the whole job: pull the contract's code, scan it for vulnerabilities, and validate whatever it found by trying to exploit it on a live fork. It had Azimuth connected through MCP, so it could pull the contract, analyze it, and run validation on its own. We gave it nothing else: no incident report, no explanation of what had gone wrong, nothing beyond the address itself.

Working from the code alone, it found the dividend-accounting flaw that drained a real protocol of roughly 56.73 ETH (about $107K) in June 2026, then confirmed the flaw was exploitable on a live fork. That was the same flaw a security firm published in their post-mortem after the attack.

We recently released our MCP connection for Azimuth so that you can do your full security routine in one place. Then we needed to test it. We wanted to ask the simple question: Can an agent use Azimuth to independently find and validate smart contract vulnerabilities.

AI-Powered Vulnerability Detection: Why We've Gone Agentic with Azimuth's MCP

Most security tooling makes you come to it. You open a dashboard, paste in a contract, wait for a scan, and read a report. We wanted the opposite; an adversarial execution platform that sits at your AI's fingertips. So Azimuth's detection and validation engines are available as MCP tools, which means any agent that speaks MCP can call them directly.

This is the part of security that has always been the bottleneck. Finding bugs is quick; proving they're real is slow and that verification work is exactly what agents are starting to absorb. When a security engine can be called directly by an agent, the whole loop runs in one place, with no one clicking through a dashboard in the middle.

With Azimuth's MCP, your agent can now run the full loop itself. It pulls the source, starts a scan, takes the findings and runs validation against them, and returns evidence without you ever changing tab. The security work can now happen in the same place the development work is already happening.

Where did we get our target?

We didn't choose a contract we had already studied and given to Azimuth. Instead we pulled one from the TestMachine Source Galaxy, a semantic map of thousands of verified Solidity contracts with real hacked ones flagged.

We landed on NovaBox, a NOVA/ETH dividend pool that was exploited in June 2026. Then we ran it blind. The agent received the address and nothing else. It had no root cause, no incident report, and no hint about what to look for. That constraint is the entire point of the test. Finding it from scratch and validating it is the part that matters.

Explore the contract in the TestMachine Source Galaxy →

What the Agent Found Using Azimuth: The $107K hack

Given the contract address, our agent ran the contract through Azimuth. Azimuth's detection engine came back with 5 findings. 1 high-severity, 3 mediums and a low in the contract.

The headline finding came back as high severity: a deposit balance update that happens after point distribution, which overallocated dividends.

Alongside it, Azimuth flagged a related medium finding, a new account added after distribution isn't initialized against current totals, so it can immediately claim dividends that accumulate before it ever joined.

Most security tools stop there and let you manually triage anywhere from 5-100 findings just to find the real ones. Azimuth's validation engine was built to prove vulnerabilities.

From Detection to Validation

With our 5 findings surfaced, the agent ran them through Azimuth's validation engine. Our validation engine attempted to reproduce them against a live fork of Ethereum mainnet to drive exploitability.

Both came back Confirmed: exploitable in live forked state, not just flagged on paper.

The exploit path follows the same shape as the real attack. A helper contract deployed from within a constructor slips past the check meant to block contract callers. A flash loan from Aave V3 funds a large qualifying deposit. Because the contract credits the deposit fee before it updates balances, the attacker's claim gets multiplied against the post-deposit total, and the dividend payout comes out inflated. Withdraw, swap back, repay the loan.

Why this matters

Security that requires a detour tends not to get run. Security that lives where you already are does.

Exposing Azimuth over MCP means detection and validation become something an agent simply does during a review or a build, without anyone opening a separate tool. That is the shift we care about: moving from security you have to visit toward security that runs alongside the work.

So you can run, validate, and patch all from the one location.

Run Azimuth on your codebase → app.testmachine.ai

Connect Azimuth's MCP to your Agent

Wiring Azimuth into your agent takes a single entry in your MCP config. Point your client at the Azimuth MCP endpoint, add your API key, and the detection and validation tools become available to the agent.

{
  "mcpServers": {
    "azimuth": {
      "serverUrl": "https://api.testmachine.ai/v1/mcp",
      "headers": {
        "X-API-Key": "YOUR_API_KEY"
      }
    }
  }
}

Grab an API key from your Azimuth account, drop it into the config, and restart your client so it picks up the new tools. Full setup instructions, including client-specific steps, are in the Azimuth MCP docs.