AI in Web3: Strategic Cybersecurity for Leaders

AI adoption across Web3 organisations is outpacing the cybersecurity frameworks meant to govern it. Development teams are generating smart contract code with AI assistants, operations teams are deploying AI agents to automate trading and wallet management, and compliance functions are integrating AI-powered monitoring, often without coordinated oversight of the security implications.

The risks this creates are categorically different in Web3 than in any other industry, because blockchain transactions are final. There is no recall function, no chargeback, and no error trade policy.

An AI system that authorises a transaction it should not have, or AI-generated code that contains a flaw an attacker can exploit, produces losses that cannot be reversed. Faster development cycles and reduced operational costs do not offset this risk; they widen the exposure by increasing the volume of unreviewed code and automated decisions entering production.

This article is written for founders, board members, and technology leaders. It covers the three domains where AI creates the greatest cybersecurity exposure in a Web3 business: (1) software development, (2) transaction and asset management, and (3) on-chain protocol interaction. It also addresses cross-domain controls, governance structures, and the regulatory setting.

1. AI in Software Development

AI coding assistants are now embedded in most development workflows, where they autocomplete functions, suggest solutions, and accelerate routine coding tasks. Code is now generated far faster than security review processes can evaluate it, and that gap is where vulnerabilities enter.

There are two categories of development work that carry disproportionate risk in Web3.

1.1 Disproportionate risk in security-critical code

Any code that handles cryptographic key material (key generation, custody logic, wallet software, signing interfaces) falls into the highest-risk tier. A vulnerability in this code can result in total, permanent loss of digital assets. AI coding assistants do not understand the security implications of their output the way a qualified security engineer does. They produce code that compiles, passes tests, and looks correct, but that may contain subtle authorisation flaws, predictable random number generation, or missing boundary checks.

1.2 Disproportionate risk in immutable deployments

Smart contracts deployed on-chain cannot be patched in the conventional sense. Even when upgrade mechanisms exist (proxy patterns, for example), exploits can be executed before the vulnerability is detected. AI-generated smart contract code that has not undergone independent security review carries a risk that persists for the lifetime of the contract.

1.3 Supply chain risk

A related supply chain risk has received growing attention. AI coding tools sometimes recommend software packages that do not exist. Attackers monitor these fabricated names, register them, and populate them with malicious code.

1.4 Slopsquatting

The next time a developer asks an AI tool for the same functionality, the tool recommends the same name, which now resolves to a real, malicious package. This attack vector is known as slopsquatting, and research indicates that roughly one in five AI-generated code samples reference non-existent packages.

Controls to consider

Track AI-generated code. Tag which code is written or modified by AI tools, particularly for immutable deployments and any module that handles key material. If a vulnerability is later discovered in the AI tool itself, you need to know which code in your production environment was generated by it.

Verify all dependencies. Do not allow AI assistants to auto-install packages. Validate every dependency against official registries before installation.
Independent security review. Security-critical code and smart contracts should be reviewed by a third party that is independent of the development team. For any code that can influence control of key material or customer assets, independent review is the minimum standard.
Treat AI tools as supply chain dependencies. Your threat model should include the compromise of the AI coding tool itself. If the tool is compromised, you need to identify every piece of code it generated and assess whether remediation is required.

2. AI in Transaction and Asset Management

The more immediate risk for most Web3 businesses is AI systems that can directly or indirectly initiate, approve, or influence financial transactions.

AI agents that rebalance funds between hot and cold wallets, execute trades based on market signals, manage gas fees, or perform automated compliance screening may, depending on their architecture, trigger transactions without human intervention.

2.1 Manipulate AI’s inputs

An attacker does not need to compromise your network in the traditional sense; they need to manipulate the AI’s inputs, the data and instructions the AI processes when making decisions, so that the AI takes an action the attacker wants.

Prompt injection, data poisoning, and manipulation of external feeds can all redirect an AI agent’s behaviour without triggering conventional security alerts.

The human operators observe that the dashboards are functioning normally. The AI processes transactions and generates reports as anticipated. However, beneath the surface, it has been subtly redirected.

Controls to consider

Architectural separation. The AI agent proposes; a separate signing infrastructure executes. The agent must never have direct access to key material. This is a non-negotiable architectural requirement.
Multi-signer enforcement. AI must not be able to meet signing thresholds on its own. Cryptographic human authorisation should be required for every transaction above a defined value.
Infrastructure-enforced limits. Transaction value limits, permitted asset types, and approved destination addresses must be enforced by your infrastructure, not by the AI itself. An AI system that is told “do not process transactions above $50,000” can be manipulated into ignoring that instruction. A payment system that refuses to sign transactions above $50,000, regardless of what the AI requests, cannot.
Independent circuit breakers. Automated controls that halt abnormal AI-initiated activity must operate independently of the agent. The AI must not be able to override, delay, or circumvent the circuit breaker.
Kill switch. Staff must be able to instantly disconnect any AI agent from your financial infrastructure. The disconnection mechanism must be tested periodically, and staff must be trained on its use. It must function regardless of the agent’s state or any instructions the agent has received.
Full transaction logging. Record every AI-initiated transaction, including agent identity, the data inputs used in the decision, validation outcomes, and rejected requests. Rejected requests are early warning signs and should be investigated rather than discarded.

For single-signer environments where multi-signer controls are not feasible, the residual risk must be formally documented and accepted at the executive level. This is a governance decision, not a technical one.

3. AI Agents and On-Chain Protocols

Decentralised finance (DeFi) protocols are composable by design.

An AI agent interacting with one protocol can trigger downstream effects across other protocols: liquidations, arbitrage, and rebalancing cascades.

3.1 Trigger downstream

The designers of any individual protocol may not have anticipated every interaction pattern, and an AI agent operating across multiple protocols amplifies this unpredictability.

Controls to consider

Permitted scope register. Maintain a register specifying which contracts and functions each AI agent is authorised to access. Anything outside the register is blocked by default.
Contract assessment before inclusion. Only add audited, well-controlled contracts to an agent’s permitted scope. Require senior management sign-off for any exception.
Exposure limits. Cap total asset value per protocol and across all protocols. These limits must be enforced independently of the AI agent.
No unlimited token approvals. Limit token approvals to the specific transaction amount and revoke after use. Unlimited approvals create a standing risk that an attacker who compromises the agent can drain approved assets without further authorisation.
Human oversight for bridge transfers. Restrict bridge interactions to approved protocols. Require human approval for high-value cross-chain transfers.

Cross-Domain Controls

Retrieval Integrity

AI agents that rely on external data (price feeds, market data, governance information, documentation repositories) are vulnerable to input manipulation. If the data that informs the AI’s decisions is poisoned, the AI’s actions will be poisoned as well.

Organisations using retrieval-augmented generation (RAG) systems have already encountered situations where AI assistants referenced outdated governance proposals, deprecated smart contract documentation, or maliciously altered knowledge repositories. In several documented instances, this led developers to implement insecure provisions or to delay incident response.

Cross-referencing multiple independent sources before triggering transactions, treating recently created domains and accounts with scepticism, requiring human verification for new sources, maintaining the ability to revoke compromised sources and halt pending transactions, and logging every external data source used in AI decision-making all reduce this exposure.

Incident Reporting

Standard incident reporting categories are insufficient for AI-related events. Organisations should establish distinct categories for unintended AI agent transactions, exploits of AI-produced code, unintended protocol interactions, circuit-breaker or kill-switch activations, and retrieval integrity failures.
A circuit breaker that prevents a bad transaction is evidence that the control worked, but also that the AI’s decision-making failed. Near-misses should be investigated with the same rigour as actual losses to determine root cause.

Measuring What Is Important

Governance without measurement is aspirational. Organisations should track concrete metrics that indicate whether AI controls are functioning as intended.

At the operational level, this means tracking the percentage of AI-generated code independently reviewed before deployment; the proportion of AI-generated recommendations verified by a human before execution; mean time to detect (MTTD) and mean time to respond (MTTR) for AI-related incidents; the frequency of adversarial testing exercises targeting AI systems; and the number of AI-related security issues caught during testing versus in production.

Prompt injection attempts, model drift events, and retrieval validation failures should also be tracked. These are leading indicators; by the time they translate into losses, the opportunity to intervene has passed.

A simple maturity model can help benchmark progress. At the initial level, AI usage is largely unmanaged with limited governance or record-keeping. Intermediate organisations have implemented code review requirements, AI usage policies, and security monitoring. Advanced organisations integrate AI risk management into their enterprise cybersecurity programme, conduct regular adversarial testing, automate compliance reporting, and apply zero-trust principles across both AI and blockchain environments. No organisation will eliminate AI risk entirely, but steady progression through these levels demonstrates both capability and intent.

Emerging Threats

Adversarial AI attacks, in which malicious inputs are deliberately crafted to manipulate model outputs, are expected to become a standard technique for bypassing automated security controls, influencing autonomous agents, and deceiving AI-assisted governance mechanisms in Web3 environments.

AI-powered social engineering is already a live threat. Large language models can generate highly personalised phishing campaigns, realistic executive impersonations, multilingual fraud attempts, and convincing deepfake communications. Within DAOs and blockchain communities, these techniques can be used to influence governance votes, manipulate token holders, or compromise privileged accounts. Industry data indicates that deepfake-based fraud attempts have grown by more than 2,000 percent in recent years.

Attackers are also beginning to target AI agents directly. As AI systems become capable of independently executing smart contracts, managing digital assets, or interacting with DeFi protocols, the agent’s reasoning process becomes an attack surface in its own right. Manipulating an agent’s objectives, memory, or external data sources can lead to harmful outcomes, even when the blockchain itself remains secure.

Security strategies must account for this expansion of the attack surface. Continuous monitoring, adversarial testing, explainable AI outputs, cryptographic verification of trusted data sources, and layered human oversight should be treated as the baseline for any Web3 organisation deploying AI in a production environment.

Regulatory Setting

The regulatory environment governing AI and digital assets is developing on parallel tracks, and organisations operating in Web3 need to monitor both.

The European Union AI Act (Regulation (EU) 2024/1689) is the world’s first risk-based legal framework for artificial intelligence. It introduces obligations for AI developers and deployers based on the risk their systems pose, including requirements for transparency, documentation, human oversight, and cybersecurity. The Act entered into force on 1 August 2024 and is being implemented in phases through to 2028. Organisations deploying AI within blockchain services should evaluate whether their use cases fall within the Act’s regulated categories.

The Financial Action Task Force (FATF) provides international guidance for Virtual Asset Service Providers (VASPs), particularly around anti-money laundering (AML), combating the financing of terrorism (CFT), and implementation of the Travel Rule. FATF guidance does not specifically regulate AI, but AI-enabled compliance systems used by exchanges and custodians need to align with FATF expectations. The FATF’s June 2025 targeted update found that global Travel Rule implementation remains uneven, with nearly a third of surveyed jurisdictions yet to pass implementing legislation.

Additional frameworks shaping expectations include the EU’s Markets in Crypto-Assets Regulation (MiCA), Singapore’s digital asset regulations under the Payment Services Act, the UK’s evolving AI governance approach, and emerging regulatory initiatives in the United States. Organisations operating across jurisdictions should maintain a formal regulatory monitoring process.

For organisations transitioning from traditional IT to Web3, existing security practices (ISO 27001 controls, incident response procedures, change management processes) should be integrated with, not replaced by, new AI and blockchain controls.

Resources for further reference:

Stakeholder Roles and Responsibilities

AI governance cannot be delegated entirely to the technology team. The risks are financial, operational, reputational, and regulatory, and they require clearly defined ownership.

Executive leadership

Executive leadership is accountable for establishing risk appetite, approving governance policies, allocating resources, and confirming that AI initiatives align with organisational objectives and regulatory obligations. Boards and senior executives should receive regular reporting on AI-related risks alongside traditional cybersecurity metrics.

Technical teams

Technical teams (software engineers, AI engineers, blockchain developers, security architects, DevSecOps specialists) are responsible for implementing secure development practices, validating AI-generated code, monitoring model behaviour, conducting security testing, and responding to AI-related incidents. Security teams should integrate AI systems into existing risk, vulnerability, and incident response processes rather than treating them as a separate technology category.

Third-party vendors and AI service providers

Third-party vendors and AI service providers require the same due diligence as any critical supplier. Organisations should evaluate model security and transparency, establish contractual security obligations, and monitor compliance throughout the relationship. Supply chain risk management should extend to foundation models, APIs, training data providers, and cloud-based AI services.

A formal RACI (Responsible, Accountable, Consulted, Informed) matrix for AI cybersecurity activities clarifies ownership questions. The matrix should cover model deployment, security testing, prompt governance, incident response, regulatory compliance, and ongoing monitoring. Without clearly assigned responsibilities, governance gaps are inevitable.

If your organisation operates under a cybersecurity standard such as CCSS, ISO 27001, or SOC 2, the risk assessment or threat model that underpins your certification should explicitly address AI risks.