This month saw the first confirmed reports of AI-assisted zero-day discovery in the wild, the launch of SEAL Certifications, and growing industry recognition that operational security is becoming just as important as protocol security.

SEAL certifications are now open

For years, Web3 security has focused primarily on audits and smart contract reviews. But many of the ecosystem’s largest losses now originate elsewhere:

• Operational failures

• Compromised credentials

• Governance attacks

• Incident response breakdowns

• Human error

To address this gap, the Security Alliance (SEAL) has officially launched SEAL Certifications. Since publishing the framework in late 2025, SEAL has conducted:

• Reviews with 25+ protocols

• Feedback sessions with leading auditors and security researchers

• Extensive pilot testing across multiple sectors

The framework is now live. Oak Security is proud to be one of the initial providers working with SEAL on certifying projects.

Ask us about beginning the certification process. Learn more

The state of Web3 security (2022-Q1 2026)

Together with rekt.news, Oak Security recently published one of the largest empirical studies of Web3 security ever conducted. We have now made all the data available on an interactive dashboard.

The data covers:

• 23,818 published audit findings

• 22 auditing firms

• 218 exploit incidents

• $7.76 billion in documented losses

Human attacks now dominate losses. 52% of all recorded losses originated from:

• Phishing

• Private key compromise

• Social engineering

• Supply-chain attacks

Losses remain concentrated. The eight largest incidents accounted for over 50% of all recorded losses.

More audits ≠ fewer losses. Audit volume tripled between 2022 and 2024, yet ecosystem-wide losses did not materially decline.

Security risk has shifted. Private key compromise, governance attacks, operational failures, and supply-chain compromises now exceed traditional code exploits in economic impact.

Ethereum and BNB Chain dominate incident losses. Together they represented 94% of aggregate recorded losses.

Download the report here

Featured in the press

Crypto cybersecurity practices must refocus on human error

This month, Oak Security Managing Director Stefan Beyer was featured in Newsweek discussing one of the most important findings from our State of Web3 Security research.

For years, the industry has responded to hacks by increasing the number of audits performed. Audit activity has tripled since 2022.

Yet our analysis of 23,818 audit findings and 218 exploit incidents shows that the majority of losses now originate from human-vector attacks, including:

• Phishing and social engineering
• Private key compromise
• Supply-chain attacks
• Governance manipulation
• Operational mistakes

As Stefan explains in the article:

“Hackers figured this out awhile ago. Now the industry needs to catch up.”

The conclusion is simple: audits remain essential, but they are no longer sufficient on their own.

Web3 security must evolve into a broader discipline that includes operational security, governance controls, incident response readiness, staff training, and organizational resilience.

Read the full Newsweek article here

AI cybersecurity brief

AI discovers its first real-world zero-day

In May, Google’s Threat Intelligence Group disclosed the first publicly confirmed case of AI being used to identify and weaponize a previously unknown vulnerability.

Rather than simply assisting researchers, the system independently identified a trust-model flaw that enabled authentication bypass.

This marks an important shift: AI is moving from productivity tool to autonomous vulnerability researcher.

What we’re seeing across the industry

Offensive AI is accelerating

• AI-assisted phishing campaigns continue to scale

• Deepfake-enabled impersonation attacks are increasing

• Automated reconnaissance and exploit chaining are becoming easier

Shadow AI creates new attack surfaces. Organizations are rapidly adopting:

• Internal copilots

• AI agents

• Workflow automations

without corresponding security controls.

Supply-chain risks are growing. Attackers increasingly target:

• AI plugins

• Open-source packages

• Model repositories

• Third-party integrations

Defensive AI adoption is rising. Security teams are increasingly deploying AI for:

• Threat detection

• Log analysis

• Incident response

• Vulnerability prioritization

However, governance often lags behind deployment.

OPSEC tip of the month

Treat every AI conversation as potentially public. Never enter:

• Proprietary information

• Internal documentation

• Customer data

• Sensitive credentials

• Regulated information

into unmanaged AI tools.

Quick wins

• Create an approved AI tools list

• Restrict sensitive data usage

• Audit shadow AI adoption

• Apply least-privilege access to AI agents

• Log AI interactions where possible

CypherTalk podcast highlights

Censorship resistance with Shayan Eskandari

Security and privacy researcher Shayan Eskandari discusses:

• Censorship-resistant infrastructure

• Privacy challenges in blockchain systems

• Decentralized communications

• Building tools for users in restrictive environments

Listen here

Bug bounties with Joran Honig

One of Web3’s most prolific security researchers joins CypherTalk to discuss:

• Finding edge-case vulnerabilities

• Audit methodologies

• Bug bounty economics

• Security workflows

• AI-assisted research

Listen here

SEAL certifications with Isaac Patka

Isaac Patka, certification lead at SEAL and co-founder of Shield3, explains:

• Why operational security matters

• Incident response readiness

• Security war games

• Treasury security

• Governance controls

• Human-factor attacks

Listen here

Regulators’ corner

Stablecoin intelligence, liquidity & regulation

In the latest episode of MetaMarkets, Jan Philipp Fritsche and Jón Egilsson are joined by Max Grabner from Range to discuss the future of stablecoin infrastructure. Topics include:

• Stablecoin adoption trends

• Treasury management

• Compliance and sanctions screening

• MiCA’s impact on issuers

• European competitiveness

• The future of cross-border payments

Key question

Will stablecoins become open financial infrastructure, or another layer controlled by traditional intermediaries? Listen here

Featured audit

Divigent protocol

This month Oak Security audited Divigent, a non-custodial yield infrastructure designed for AI agents operating with USDC on Base.

The protocol automatically deploys idle agent wallet capital into audited lending markets, generating yield during periods when funds would otherwise remain unused.

Audit focus

• Yield allocation logic

• Capital management mechanisms

• Protocol integrations

• Security assumptions surrounding AI-agent workflows

• Best-practice implementation review

As AI-native financial systems emerge, ensuring secure interaction between autonomous agents and DeFi infrastructure becomes increasingly important. Read more

Events corner

Institutional and policy forum - Europe’s next financial layer

Berlin, Germany | June 15

Together with the European Ethereum Institute, Oak Security is bringing regulators, institutions, policymakers, and builders together for a full day focused on:

• Stablecoins

• MiCA implementation

• CBDCs

• Institutional adoption

• Quantum readiness

• Operational security

• Tokenization

• The future of European financial infrastructure

Oak Security will also present findings from our State of Web3 Security research. If you’re attending Ethereum Day in Berlin, we’d love to see you there. RSVP here

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

A four-year empirical analysis of 23,818 published audit findings across 22 firms and 218 real-world exploit incidents totals US$7.76 billion in losses.

Produced by Oak Security in collaboration with rekt.news.

Key findings from the report

• 52% of total losses came from human-vector attacks, not smart contract bugs

• The top 8 incidents accounted for 50.6% of all recorded losses.

• Audit volume tripled between 2022 and 2024, but ecosystem-wide losses did not materially decline

• Private-key compromise, phishing, supply-chain compromise, and governance attacks now exceed code-level exploits in financial impact.

• Ethereum and BNB Chain accounted for 94% of aggregate losses.

Download the full report. Talk to the authors.

April 2026 marked the worst month for crypto exploits in over a year, but the real signal was how the attacks unfolded.

The main dangers are changing from usual smart contract problems to issues with operational security, infrastructure breaches, cross-chain dependencies, and ongoing social engineering schemes. Increasingly, the distinction between nation-state operations and financially motivated attacks is becoming difficult to identify.

What we’re seeing

Infrastructure and operational security are becoming the primary attack surface

Q1 and April exploit data reveal a clear trend:

• Phishing and social engineering campaigns continue to outperform traditional smart contract exploits.

• Bridge infrastructure remains structurally fragile.

• Cloud, IAM, validator, RPC, and frontend compromise vectors are increasing.

Attackers are becoming more patient, coordinated, and operationally sophisticated.

For protocols, these developments mean security audits can no longer stop at code review alone.

Drift Protocol (~$285M)

Attackers reportedly spent months building credibility before exploiting oracle and collateral weaknesses linked to whitelisting mechanisms.

• Social engineering now rivals smart contract vulnerabilities in severity.

• Collateral governance and oracle dependencies remain critical failure points.

• Insider-access assumptions require far deeper review.

We are increasingly seeing the following:

• Operational trust assumptions becoming the primary exploit path

• Attacks designed around protocol processes rather than code alone

Kelp DAO / LayerZero Bridge (~$292M)

Forged cross-chain messages reportedly enabled attackers to spoof bridge activity and trigger cascading liquidity disruptions across integrated systems.

The downstream impact ultimately became larger than the initial exploit itself.

• Bridges remain one of the highest-risk areas in Web3.

• Cross-chain trust assumptions require adversarial testing.

• Protocols increasingly inherit risk from connected ecosystems.

This is especially critical for:

• Relayer validation

• Oracle dependencies

• Governance execution across chains

• Emergency response coordination

AI-Assisted phishing is accelerating

We are seeing increasing reports of the following:

• Deepfake support calls

• AI-generated impersonation attempts

• Targeted phishing using scraped public data

• Session hijacking and browser-based credential theft

The sophistication gap between attackers and average users is widening rapidly.

Verification processes matter more than ever:

• Multi-channel confirmation

• Hardware wallet usage

• Strict signing hygiene

• Minimising screen sharing and remote access workflows

Governance is becoming a security layer

Recent incidents continue to reinforce the following:

• Upgrade systems

• Multisigs

• Timelocks

• Emergency powers

• Operational governance

…are now core components of security infrastructure.

The industry conversation is evolving beyond “Was the code audited?” toward more fundamental questions:

• Who controls upgrades?

• How quickly can permissions change?

• What happens during emergencies?

• How transparent are recovery procedures?

Regulatory pressure is raising operational expectations

MiCA implementation, stablecoin reserve scrutiny, proof-of-reserve discussions, and broader compliance expectations are pushing protocols toward more mature operational standards.

Security reviews increasingly need to assess the following:

• Governance transparency

• Incident response readiness

• Operational controls

• Infrastructure resilience

• Custody and access management

OPSEC quick tip

Separate wallets by function

One wallet should never handle everything.

Recommended separation:

• Cold storage

• Active trading

• Governance voting

• Testing / experimental apps

• Public-facing identity

Concentrating too many permissions and assets within a single signer continues to be one of the most common paths to catastrophic wallet compromise.

Podcasts

CypherTalk - Censorship resistance with Shayan Eskandari

A talk about how to resist censorship and build privacy systems and what the future holds for decentralised communication, including information on MoaV and the challenges of working in limited situations.

Listen here.

MetaMarkets - Stablecoin intelligence, liquidity, and regulation

Featuring Max Grabner.

The discussion explores the following:

• Stablecoin infrastructure

• Treasury intelligence

• MiCA implications

• Liquidity fragmentation

• Sanctions screening

• The future competitive landscape for issuers

Listen here.

ETHMilan 2026

Stefan Beyer, our co-founder, will be speaking at ETHMilan 2026 as part of a security panel, along with researchers, builders, and security experts working across blockchain infrastructure, audits, and AI-powered defence systems.

Security remains one of the most critical layers of the onchain ecosystem, especially as operational and infrastructure risks continue accelerating across Web3.

See you in Milan.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

Hi everyone!

This is a quick note to say we’re now in the final 24 hours of The DAO Security Fund quadratic funding round.

If you’ve been meaning to support CypherTalk, this is the last chance to vote/donate and have your contribution matched and amplified.

CypherTalk is a public-good podcast focused on Ethereum security, privacy, operational security, and real-world attack analysis, helping turn deep technical knowledge into accessible, actionable insights for the ecosystem.

Support here: CypherTalk on Giveth

Every contribution now has maximum impact through matching, thank you to everyone who’s supported so far.

The DAO Security Fund quadratic funding round is now live, and CypherTalk has been selected as part of the round.

CypherTalk is a public-good podcast focused on:

• Ethereum security

• Privacy and operational security

• Real-world attack analysis

• Cryptography and defensive research

Support CypherTalk here.

Why this matters

Security education is one of the most scalable ways to reduce preventable losses across Ethereum.

As attacks become more sophisticated, especially with AI accelerating exploit discovery and phishing operations, improving user and builder awareness becomes increasingly important.

If you hold an Ethereum Security badge, your vote carries even more weight in the round.

Thank you for helping support open security infrastructure for Ethereum.

The state of Web3 security (2022 - Q1 2026)

Oak Security, in collaboration with rekt.news, recently published a four-year empirical analysis covering:

• 23,818 published audit findings across 22 firms

• 218 documented exploit incidents

• US$7.76 billion in aggregate losses

Key Findings

• 52% of total losses originated from human-vector attacks rather than smart-contract bugs

• Private-key compromise, phishing, and supply-chain attacks now exceed all code-level exploit categories combined

• Audit volume tripled between 2022 and 2024, while ecosystem losses showed no corresponding decline

• Eight incidents alone accounted for over 50% of aggregate losses

• Ethereum and BNB Chain represented 94% of total recorded losses

The report reinforces a growing industry reality:

Web3 security is no longer only a smart-contract auditing problem. Operational security, infrastructure security, governance security, and human-vector defence are increasingly critical.

READ THE FULL REPORT HERE

GPT-5.5 matches mythos preview in cybersecurity evaluations

Recent testing conducted by the UK’s AI Security Institute (AISI) suggests that OpenAI’s GPT-5.5 now performs at a similar level to Anthropic’s heavily publicised Mythos Preview model on advanced cybersecurity evaluations.

The findings are significant because Mythos Preview was previously framed as representing an unusually high cyber capability threshold requiring restricted release.

According to AISI’s testing:

• GPT-5.5 achieved comparable performance across expert-level cybersecurity tasks

• The model successfully completed complex reverse-engineering and exploitation challenges

• GPT-5.5 solved one advanced Rust binary disassembly challenge autonomously in just over 10 minutes

• GPT-5.5 became one of the first publicly accessible models to partially succeed in AISI’s simulated enterprise attack scenarios

Advanced offensive cybersecurity capabilities are no longer unique to isolated frontier models. They are increasingly emerging as a byproduct of general improvements in reasoning, coding, autonomy, and long-horizon task execution.

Broader Threat Trends (May 2026)

• Rapid growth in AI-assisted phishing and social engineering campaigns

• Increasing use of autonomous malware agents

• Rising security failures across AaI pipelines, agents, and integrations

• Shrinking patch windows due to accelerated vulnerability discovery

• Lower operational barriers for attackers using AI-assisted tooling

The security landscape is rapidly shifting toward AI-accelerated exploitation and defence.

OPSEC tip of the month

Rename your Bluetooth devices and Wi-Fi hotspots

Avoid using:

• Real names

• Device models

• Identifiable labels

Why this matters

Bluetooth and hotspot names are publicly broadcast and easily detected using nearby scanning tools.

This can enable:

• Passive identification in public spaces

• Correlation of identity with devices

• Increased exposure to social engineering

Small change. Real privacy gain.

CypherTalk podcast highlights

The state of Web3 security with Diogo Patão from rekt.news

This episode explores the newly released Web3 security reports from Oak Security and rekt.news, alongside broader discussions on:

• The rise of AI-assisted attacks

• Why human attack vectors now dominate ecosystem losses

• Recent large-scale exploits and operational failures

• How builders and users can improve security practices

• The future of blockchain security research

“AI is here to help us, not just to attack.” LISTEN HERE

Password manager security & applied cryptography with Matilda Backendal

Key discussion points:

• End-to-end encryption is often weaker in practice

• Cloud systems frequently lack true default encryption

• Password managers remain a critical security dependency

• Security trade-offs between usability and formal guarantees

Cryptography is constantly shaped and often weakened, by real-world implementation constraints. LISTEN HERE

Auditing cryptographic protocols with Nadim Kobeissi

Key discussion points:

• Limits of formal verification in real-world systems

• Responsible disclosure challenges

• AI’s role in vulnerability discovery and stockpiling

• Emerging post-quantum and AI-augmented threat models

“Claims of formal verification being bug-free are often exaggerated.” LISTEN HERE

DeFi, banking risk & evolving oversight

New episode of MetaMarkets featuring Furkan Danisman

This episode explores whether DeFi lending systems such as Aave can meaningfully compete with traditional banking infrastructure.

Topics discussed include:

• Aave V3’s previously reported 0% non-performing loan ratio

• How recent incidents challenge assumptions around DeFi resilience

• Whether tail-risk events are properly captured in DeFi risk models

• Whether markets can self-correct security failures

• The growing possibility of stronger regulatory frameworks

LISTEN HERE

Featured Audit - AtomOne v4 (Cosmos SDK L1)

This month, Oak Security audited AtomOne v4, a Cosmos SDK-based Layer 1 forked from the Cosmos Hub.

The review focused on protocol-level upgrades spanning:

• Governance systems

• Economic mechanisms

• Cross-chain infrastructure

READ HERE

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

1. The core AtomOne chain: Cosmos SDK v0.50 migration, a new two-tier DAO governance module with steering and oversight DAOs, dynamic fees, etc.

2. AtomOne’s Cosmos SDK fork: governor-based governance delegation, dynamic deposit throttlers, Nakamoto bonus distribution, and the epoch module

3. IBC light client module for Gno chain connectivity

The audit surfaced findings across critical, major minor and informational severity levels, all of which have since been resolved and acknowledged by the reserve protocol to ensure the programme meets strong security standards. Read the full audit report.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

For the past four years, the industry has talked about Web3 security as if it were one thing. The data says it’s two — and they don’t line up.

We analysed every public audit finding we could get our hands on between January 2022 and March 2026 — 23,818 findings across 22 firms and 2,978 reports. We paired that with 218 real-world exploit incidents documented by Rekt News, representing roughly $7.76 billion in cumulative losses.

The headline finding is this: the categories that auditors surface are not the categories that drive realised losses.

Of the twelve most frequent audit categories and the twelve largest exploit-loss root causes, only one — access control — appears in the top four on both sides. Private key compromise, phishing, and social engineering account for nearly half of all dollar losses across the four-year window, but a negligible share of audit findings. The industry has spent a decade hardening Solidity. The money is being taken somewhere else.

A few of the numbers that stood out to us:

• 49.6% of cumulative losses came from human-vector attacks (keys, phishing, supply chain, governance manipulation)

• 48% of incidents affected protocols that had received at least one public audit

• 8 incidents account for more than half of all losses; 20 incidents account for over 70%

• 89% of incidents happened on Ethereum or BNB Chain

• Q1 2026 is the first quarter since 2022 where code-level bugs dominated both incident count and losses — a possible rotation, or just a quiet patch

The full 33-page report is available here

A note of thanks

This report could not exist without Rekt News. They granted us explicit permission to use their incident archive as primary research data, and the four-year picture of realised losses you’ll see in the report is built on their reporting. The investigative work the Rekt team has done — incident by incident, post-mortem by post-mortem — is the empirical foundation the rest of the industry now builds on.

P.S. Our podcast and Rekt News are participating in TheDAO Security Fund’s current quadratic funding round, alongside other public goods working to make Web3 safer. The fund is deploying ETH reactivated from the original 2016 DAO hack If you liked the reports, please consider supporting our podcast, CypherTalk, and Rekt.

The short version: Even a small donation can have an outsized impact, but only if enough people participate. Quadratic funding rewards broad community support over big individual gifts. A $10 donation from 10 people can outweigh a single $1,000 donation. Read all about how it works here.

The catch: To qualify for matching, you need to donate to at least 3 projects in the round (not just us) and complete a quick KYC check on Giveth.

If you’ve got a few minutes and a few dollars to spare, here’s what to do:

1. Head to the Ethereum Security round on Giveth

2. Pick 3+ projects you believe in (we’d be honoured if CypherTalk is one of them)

3. Complete the passport verification

4. Donate any amount

Some projects we’d recommend alongside ours:

• SEAL 911 — Emergency response for critical protocol incidents

• BlockThreat — Security research and threat intelligence

• Rekt — Post-mortems on protocol breaches

• scfuzzbench — Open-source fuzzer tooling

Your donation helps us keep CypherTalk independent and freely available—no sponsors, no ads, no corporate backing. Just honest security education for the Ethereum ecosystem.

— Oak Security

Donate on Giveth →

We’re excited to share that CypherTalk is now live on the DAO Security Fund.

Support here:
https://qf.giveth.io/project/cyphertalk-podcast:-security-education-for-ethereum?roundId=16

What is CypherTalk?

CypherTalk is a free, independent podcast focused on:

• Cybersecurity in Web3

• Privacy and operational security

• The human side of security failures

We translate complex security topics into practical insights for builders, users, and teams, so better decisions happen before things go wrong, ultimately reducing the risk of security failures and enhancing overall operational security.

Why this matters now

Crypto security isn’t just about smart contracts anymore.

A large share of losses today comes from the following:

• Phishing attacks

• Social engineering

• Weak operational security

• Human error under pressure

And with ecosystems growing faster and attackers becoming more sophisticated, these risks are increasing, not decreasing, which highlights the urgent need for improved security measures and proactive strategies to mitigate these threats.

Security education is one of the most scalable ways to reduce preventable losses, as it empowers individuals and organisations to recognise threats and respond effectively to security incidents.

What CypherTalk does

CypherTalk focuses on real-world security understanding, including:

• How attacks actually happen in practice

• How teams can improve operational security

• How users can avoid common traps

• Insights from leading experts in cryptography and Ethereum security

Featuring voices across the ecosystem, including:

• Griff Green (Giveth)

• Jordi Baylina (Zisk)

• Peter Kacherginsky (BlockThreat)

Why your support matters

CypherTalk is part of a quadratic funding round, meaning:

• Even small contributions matter

• Community participation increases matching

• More supporters = more funding unlocked

Your vote doesn’t just support a podcast; it helps fund security education for the entire Ethereum ecosystem.

Support CypherTalk

https://qf.giveth.io/project/cyphertalk-podcast:-security-education-for-ethereum?roundId=16

If Ethereum security matters to you, this campaign is one of the most direct ways to support it.

Every contribution helps strengthen the ecosystem’s ability to prevent the next major exploit, not just respond to it.

Thank you for supporting open security infrastructure.

Meet our senior team at Paris Blockchain Week (April 15-16) to harden your defences. Join our TG group to stay updated.

TheDAO Security Fund

Griff Green, founder of Giveth, shares lessons from the DAO hack, the evolution of Ethereum security, and how TheDAO Security Fund is pioneering community-led funding for crypto security on the latest episode of the CypherTalk podcast. Listen.

Featured audit: Reserve updates

Our team audited Reserve Protocol 4.2.0, looking at improvements in security and governance, and we have fixed all issues to maintain high standards. Read more.

Join our team!

Senior Blockchain Security Engineer | Job Posting Shared

Senior Zero-Knowledge (ZK) Blockchain Security Auditor (f/m/d) | Job Posting Shared

AI agents under threat

ClawJacked highlights the rising security risks of agentic AI, shows how vulnerabilities in cloud development environments can be exploited, and underscores the need for isolation, zero trust, and careful access control when running autonomous AI agents. Read more.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The audit surfaced findings across informational and minor severity levels, all of which have since been acknowledged by the reserve protocol to ensure the programme meets strong security standards. Read the full auditreport.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We’ve entered the age of agentic AI, systems that don’t just think but act.

Modern AI agents can talk to APIs, call tools, move data, create sub-agents, and even perform tasks on behalf of users. Every new capability increases what these systems can do. But it also increases the number of ways attackers can exploit them.

A vulnerability known as ClawJacked offers a clear example of why the security risks around AI agents deserve closer attention.

A security weakness in cloud development environments

ClawJacked is a security weakness affecting certain browser-based cloud development environments. The issue stems from how authentication tokens are stored and accessed during active development sessions.

In a typical attack scenario, a developer visits a malicious website while logged into a vulnerable cloud development environment. Through carefully crafted cross-origin interactions, the attacker can trick the browser into leaking authentication tokens associated with the active development session.

Once these tokens are obtained, attackers may be able to:

• Access private source code repositories

• Interact with cloud APIs

• Modify development environments

• Potentially pivot into broader cloud infrastructure

The attack does not require installing software or malware. Instead, it relies entirely on browser session behaviours and token handling mechanisms, which can be exploited through techniques such as session hijacking or cross-site scripting.

In many ways, this vulnerability does not fundamentally change the threat model. Security professionals have long been sceptical about giving AI agents access to vast environments. However, ClawJacked highlights that many users are already doing exactly that and that it can quickly lead to serious trouble.

When AI agents have too much access

One of the core problems with AI agents is the amount of information they often have access to.

Agents frequently operate with large volumes of contextual data that are difficult for humans to fully oversee. At the same time, many users grant these systems far more privileges than they should.

As a result, an AI agent may have access to sensitive resources such as:

• API keys

• Login credentials

• Critical internal documents

• Access to financial systems such as bank accounts

If an attacker hijacks an agent with this level of access, the damage can extend far beyond the original system.

For example, if the agent has access to a user’s contact list or email history, a breach could place everyone in that network at risk. Past emails could also allow attackers to recreate the user’s writing style, making it easier to impersonate them and target colleagues, friends, or family members.

Safer ways to run AI agents

Because of these risks, running AI agent frameworks directly on personal or corporate machines is not recommended. AI agent frameworks are software systems designed to perform tasks autonomously using artificial intelligence.

Instead, systems like OpenClaw should be operated in controlled environments. One approach is to run them inside a Docker container on a separate server. This helps limit the damage if the agent or its environment becomes compromised.

Isolation and careful control over the environment are important steps toward reducing risk.

Using zero trust with AI agents

To secure these systems, many experts argue that organisations need to apply the Zero Trust principles.

The core idea behind Zero Trust is simple: never trust by default, always verify.

Instead of granting broad access “just in case,”, permissions should follow a just-in-time approach. Systems receive access only when it is needed and for the time it is required. This preserves the principle of least privilege, ensuring that entities only have the permissions necessary to perform specific tasks.

Another important shift is moving away from perimeter-based security. Rather than relying on a single protective boundary around a system, security controls should exist throughout the entire environment.

Perhaps the most important principle is the assumption of breach. Systems should be designed with the expectation that attackers may already be inside the network, database, or application. Security architecture should reflect that reality.

Treat autonomous agents as experimental

For now, organisations should treat fully autonomous AI agents, which are systems that can operate independently without human intervention, as experimental technology.

Companies should educate staff about the dangers of AI agents, particularly when it comes to permissions and access control. Excessive privileges granted to agents can pose significant security risks in the event of a system compromise, as they may allow unauthorised access to sensitive or critical systems, leading to potential data breaches or operational disruptions.

ClawJacked illustrates how seemingly small weaknesses can have large consequences when powerful automated systems are involved.

Agentic AI multiplies both power and risk. Zero Trust provides a framework for keeping that power under control.

Every agent must prove who it is, justify what it wants to access, and continuously earn trust. Only then can organisations safely harness the capabilities of autonomous systems without exposing them to potential attackers.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We will be at Cannes for EthCC, delving deeply into ZK, TEEs, FHE and privacy. Register now. We’ll also be hosting a surprise event like last year’s beachfront champagne tasting, all info in the TG group.

The future of ZK

The security legend Jordi Baylina talks to us about zero-knowledge technology and the future of privacy infrastructure on the latest episode of CypherTalk. Listen.

Peter Kacherginsky from BlockThreat joins us next to discuss threat modelling and the actual locations of exploits. Stay tuned.

2026, the year of institutions?

We debate whether crypto is becoming institutional infrastructure and what institutions actually need in terms of privacy on the latest episode of MetaMarkets. Listen.

Featured audit: Avail Cosmos and Backend Changes

During our audit of Cosmos and backend architecture changes for Avail, off-chain components became just as critical as smart contracts. Read more.

Join our team!

Senior Blockchain Security Engineer | Job Posting Shared

Senior Zero-Knowledge (ZK) Blockchain Security Auditor (f/m/d) | Job Posting Shared

Our custom AI translated a Solana Multisig to Stylus

If you are a Solana developer, try porting your contracts to Arbitrum. Read more.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We covered a broad surface area, encompassing the Cosmos SDK appchain, an off-chain node responsible for fulfilling bridging and settlement requests, and a TypeScript SDK.

The audit surfaced findings across critical, major, and minor severity levels. The resolved critical issues addressed serious vulnerabilities, including malicious vote extensions capable of mutating bridge state and consensus failures triggered by non-deterministic time checks. All resolved findings were verified by our team, and the remaining acknowledged issues represent risks the client has accepted or is actively tracking within their security model. Read the full audit report.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The recent breach of Mexico’s government networks marks a chilling milestone: for the first time, a cybercriminal used an AI chatbot, Anthropic’s Claude, to orchestrate a large-scale attack. The attacker didn’t just access a single database; they extracted sensitive data across multiple agencies, including 195 million tax records, voter information, government employee credentials, and population registry files, totaling 150GB, according to Bloomberg.

What makes this data breach particularly notable is the level of insight it gives into the attacker’s mind and proficiency. Claude AI was able to retrieve most of the details of how the attacker engineered his attack; he prompted Claude AI in Spanish. While Claude initially warned the attacker about malicious intent, it eventually complied once the attacker claimed they were participating in a bug bounty program. Interestingly, the attacker also tried to obscure their intentions using OpenAI, a company known for its artificial intelligence technologies, but was ultimately blocked.

At Oak Security, we see this incident as an alarming trend. AI has made offensive hacking more accessible than ever, but AI systems still struggle to reliably detect and prevent malicious intent. They face a dilemma: limiting the tools’ offensive capabilities also reduces their defensive capabilities; that is what they advertise with.

Why this breach matters more than others

Even as AI evolves, the attack underscores persistent weaknesses in organisational security:

• Poor operational security practices

• Weak or missing authentication controls

Attackers using AI can scan, test, and exploit vulnerabilities much faster than before, so organisations must rethink cybersecurity as a proactive, adaptive discipline rather than a compliance exercise.

Our services to prevent AI-driven attacks

1. Operational security from scratch: Establish secure practices for all systems and workflows from day one. Book a training course.

2. Multiple-layered audits: Continuously harden products and infrastructure to detect vulnerabilities before attackers can exploit them. Request a quote.

The road ahead

AI will continue to reshape the threat landscape in the next 1-2 years. The Mexican government’s violations prove that no organization is immune. Security teams must recognise the dual nature of AI: it can empower both defence and offence. The time to prepare is now.

For a deeper dive into immediate actions enterprises and government bodies should take to protect sensitive data, see our follow-up article.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The recent Claude AI breach of Mexican government networks has demonstrated a new reality: AI is enabling attackers to scale their operations and craft sophisticated attacks faster than ever. Enterprises and government bodies can no longer rely solely on traditional security measures. Protecting sensitive data now requires a proactive, holistic approach.

1. Implement and enforce zero trust architecture (ZTA)

Zero Trust operates on a simple principle: never trust. Every system, communication, and user is treated as potentially compromised. Key aspects include:

• Least-privilege access: Employees, contractors, and even executives should only have access to systems and data necessary for their role.

• Formal frameworks: Follow standards like NIST SP 800-207, which provides a global benchmark for designing secure architectures.

A Zero Trust setup ensures that even if credentials are stolen or an employee is compromised, attackers cannot move freely within the network.

2. Enforce phishing-resistant multi-factor authentication (MFA).

Passwords alone are no longer sufficient. Organisations must deploy strong authentication methods to protect critical systems:

• Hardware keys: Physical devices like YubiKeys provide strong protection against phishing and credential theft.

• Passkeys and authenticator apps: Public/private key-based solutions and OTP apps add layers of security, reducing risks from stolen passwords.

3. Continuous monitoring and behavioural analytics

AI-powered attacks can move quickly, often bypassing traditional alerts. Continuous monitoring of network and user behaviour allows organisations to detect anomalies in real time and respond before breaches escalate.

4. Encrypt data at rest and in transit.

Encryption ensures that even if attackers gain access to systems, the information remains unreadable and unusable. This includes sensitive tax, voter, and employee data in government systems, as well as proprietary business data in enterprises.

The bottom line

The Claude AI incident is a warning: attacks are evolving, and AI can empower even lone attackers. Enterprises and government bodies must assume breaches are inevitable and design systems that minimise impact. Implementing Zero Trust, strong authentication, continuous monitoring, and encryption is no longer optional; it’s essential for safeguarding sensitive data in a world of AI-driven threats.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We built StylusPort to close that gap: an open-source MCP server paired with a 13-chapter migration handbook for Solana-to-Stylus work.

Stylus port has the power to overcome what separates Solana and the EVM: The execution and data models of Solana and Stylus diverge in critical ways: Solana accounts vs EVM storage, PDAs vs contract addresses, Borsh vs ABI encoding, CPI vs external calls, and compute units vs gas.

We equipped Claude Opus 4.6 with StylusPort and ported a Solana Multisig to Stylus. The input was Coral’s production multisig program (roughly 300 lines of Anchor Rust). The output was a Stylus contract implementation with 23 unit tests.

Read below what worked, what failed, and what still needs human review. The short version: structured retrieval and constrained workflows produce a strong starting point, but they do not replace audit-grade engineering.

ℹFor readers unfamiliar with MCP: Model Context Protocol is an open standard that lets AI assistants use external tools and knowledge.

What is StylusPort?

StylusPort has three components.

The Handbook. Thirteen mdbook chapters covering migration patterns: program structure, state storage, access control, external calls, native tokens, ERC20/721, errors and events, a full Bonafida Token Vesting case study, testing/debugging, gas optimization, and security. Each chapter includes side-by-side Solana and Stylus examples in both Anchor and “Native” flavors.

The MCP Server. A Rust binary exposing four tools, thirteen resources, and two prompts over stdio. It works with Claude Code, Cursor, OpenCode, and other MCP-compatible harnesses.

The Prompts. Two structured workflows with defined steps:

• Plan --- analyze the Solana program, search the handbook, then produce an 11-section migration plan with architecture mapping tables, a risk register (minimum eight items), implementation phases, and a test plan.

• Execute --- read the plan, implement phase by phase, verify WASM compilation, run tests, and produce a completion summary.

The four tools

• detect_solana_program_kind --- reads a Cargo.toml and returns “anchor” or “native” to determine migration strategy.

• search_handbook --- BM25 full-text search across all 13 chapters, returning ranked resource URIs.

• generate_stylus_contract_cargo_manifest --- produces a Cargo.toml with pinned dependencies (stylus-sdk = “=0.9.0”, alloy-primitives = “=0.8.20”, motsu = “0.10.0”), WASM target config, and release optimizations.

• generate_stylus_contract_main_rs --- produces the ABI export entrypoint boilerplate.

The target: Coral Multisig

Coral (formerly Serum) Multisig is a production Solana governance contract. It is compact (about 300 lines in one lib.rs) but still exercises migration-critical patterns.

It implements an M-of-N multisig wallet. A group of owners collectively approve and execute arbitrary Solana transactions. The key concepts:

• Multisig account: owners list, approval threshold, and an owner_set_seqno (a version counter that invalidates all pending transactions whenever the owner set changes).

• Transaction account: target program, instruction data, an approval bitmap tracking which owners have signed, and a did_execute flag preventing replay.

• PDA signer: a Program Derived Address that signs for cross-program invocations during execution.

• Self-governance: set_owners and change_threshold can only be called through the multisig’s own execute_transaction, creating a recursive self-call pattern.

It uses Anchor, multiple related account types, CPI with PDA signing, layered access control, and state invalidation logic, while remaining small enough to verify by hand.

The migration in two commands

Step 1: plan

We invoked the Plan prompt inside Claude Code.

Discovery: Claude scanned for Cargo.toml, read programs/multisig/src/lib.rs, then ran detect_solana_program_kind and got “anchor”, which routes it to the Anchor-flavored handbook sections.

Handbook research: Five parallel search_handbook calls followed; each returned a ranked list of chapters to read.

• “storage state accounts mapping Solana to Stylus”

• “access control authorization signers owners”

• “CPI external calls cross-program invocation”

• “serialization data layout borsh anchor”

• “errors events logging revert”

Note: targeted search helps avoid context-window overload, which can reduce output quality.

Then it read seven handbook chapters via their MCP resource URIs: state-storage, access-control, external-calls, errors-events, security-considerations, testing-debugging, and program-structure.

Boilerplate generation: Both generators were called to produce a Cargo.toml and main.rs with pinned dependency versions.

Compared with ad hoc prompting (or Skills alone), the MCP server reduces unnecessary non-determinism by generating standardized boilerplate.

Plan output: Claude wrote a 551-line plan.md covering all eleven required sections. Key sections included:

The architecture mapping tables captured how each Solana account type becomes Stylus contract storage:

The risk register identified ten risks with concrete mitigations:

• Reentrancy. Solana’s runtime prevents reentrancy by default. The EVM does not. Mitigation: set did_execute = true before the external call (checks-effects-interactions pattern).

• Owner index drift. If the owner set changes between transaction creation and execution, signer indices become meaningless. Mitigation: the owner_set_seqno mechanism, carried over directly from the Solana implementation.

• Self-call authorization. Solana uses PDA signing. Stylus needs msg_sender() == contract_address(). Governance functions must be unreachable from external callers.

You can see the generated plan in its entirety here.

Step 2: execute

We invoked the Execute prompt. Claude read the plan and began implementing it phase by phase.

Phase 1 - Project Setup: Created Cargo.toml, src/main.rs, and a src/lib.rs skeleton. The first WASM build failed with a missing vec! macro. In no_std, vec! comes from alloc, not the standard prelude. Claude added extern crate alloc; use alloc::vec; and rebuilt successfully.

Note: this shows a guess-then-retrieve loop. If a wrong guess compiles, the error can still slip through.

Phase 2 - Storage and Errors: Defined all storage types, eleven error variants, and six events using the sol! macro. The WASM build passed with warnings about unused fields.

This is where the error model becomes more expressive than the original. Anchor errors are essentially u32 codes with string messages:

#[error_code]
pub enum ErrorCode {
    #[msg("The given owner is not part of this multisig.")]
    InvalidOwner,
    // ...
    #[msg("Not enough owners signed this transaction.")]
    NotEnoughSigners,
    // ...
    #[msg("The given transaction has already been executed.")]
    AlreadyExecuted,
    // ...
}

The Stylus version carries structured data:

sol! {
    error InvalidOwner(address caller);
    error NotEnoughSigners(uint64 required, uint64 provided);
    error AlreadyExecuted(uint256 tx_id);
    // ...
}

#[derive(SolidityError)]
pub enum ContractError {
    InvalidOwner(InvalidOwner),
    NotEnoughSigners(NotEnoughSigners),
    AlreadyExecuted(AlreadyExecuted),
    // ...
}

Clients can now programmatically read which owner was invalid and how many signatures were missing, not just that an error occurred.

Phase 3 - Core Logic: Claude implemented all seven public functions, seven view functions, and seven internal helpers. Two compile issues required API and import adjustments.

First: error[E0277]: the trait bound ‘alloy_primitives::Bytes: AbiType’ is not satisfied. The Bytes type is not ABI-encodable in the Stylus SDK. Claude switched the public API signatures from Bytes to Vec<u8>.

Second: error[E0433]: could not find ‘calls’ in ‘stylus_sdk’. The import path for the Call context had changed between SDK versions. Claude re-consulted the handbook’s external-calls chapter and found the correct path: stylus_sdk::prelude::*.

After the adjustments, the ported contract’s public interface looks like this:

#[public]
impl Multisig {
    #[constructor]
    pub fn constructor(&mut self, owners: Vec<Address>, threshold: U64) { // ... }
    pub fn create_transaction(&mut self, target: Address, value: U256, data: Vec<u8>) -> Result<U256, ContractError> { // ... }
    pub fn approve(&mut self, tx_id: U256) -> Result<(), ContractError> { // ... }
    pub fn execute_transaction(&mut self, tx_id: U256) -> Result<Vec<u8>, ContractError> { // ... }
    pub fn set_owners(&mut self, owners: Vec<Address>) -> Result<(), ContractError> { // ... }
    pub fn change_threshold(&mut self, threshold: U64) -> Result<(), ContractError> { // ... }
    pub fn set_owners_and_change_threshold(&mut self, owners: Vec<Address>, threshold: U64) -> Result<(), ContractError> { // ... }

    // View functions
    pub fn get_owners(&self) -> Vec<Address> { // ... }
    pub fn get_threshold(&self) -> U64 { // ... }
    pub fn get_transaction(&self, tx_id: U256) -> (Address, U256, Vec<u8>, Vec<bool>, bool, U32) { // ... }
    pub fn is_owner(&self, addr: Address) -> bool { // ... }
    pub fn get_tx_count(&self) -> U256 { // ... }
    pub fn get_owner_set_seqno(&self) -> U32 { // ... }
    pub fn get_approval_count(&self, tx_id: U256) -> U64 { // ... }
}

Phase 4 - Unit Tests: Twenty-three tests using the motsu harness by OpenZeppelin. They cover constructor validation, transaction creation, approval flow, execution guards, owner-management authorization, view functions, and property invariants. All pass, but what exactly was tested?

The tests break down into seven categories: constructor validation (6 tests covering valid init, single owner, empty owners, zero threshold, threshold exceeding owner count, and duplicate owners), transaction creation (4 tests: success, auto-approval by creator, ID increment, non-owner rejection), approval flow (4 tests: success, non-owner rejection, double-approval rejection, invalid transaction rejection), execution guards (2 tests: insufficient signers, invalid transaction), owner management authorization (3 tests: set_owners, change_threshold, and set_owners_and_change_threshold all rejected when called directly), view functions (2 tests: is_owner and get_transaction for a nonexistent ID), and property invariants (2 tests: threshold bounds and approval count not exceeding owner count).

This is decent coverage of the rejection paths, but it has significant gaps.

No successful execution test: execute_transaction is only tested for failure cases. There is no test that a fully-approved transaction actually executes and returns the expected result. The entire happy path of the contract’s core function is untested.

No self-governance test: The three owner-management tests only verify that direct calls are rejected. The happy path --- calling set_owners or change_threshold through execute_transaction --- is never tested. This is the contract’s most critical flow: the re-entrant self-administration pattern where the multisig governs itself by executing transactions that target its own functions. An auditor would flag this immediately.

No owner_set_seqno invalidation test: The stale-seqno rejection path, where an owner-set change invalidates pending transactions, is untested. This is a security-critical invariant carried over from the Solana implementation.

No AlreadyExecuted test: The replay-protection path, where a second execution of the same transaction is rejected, is untested.

Key migration patterns

Four patterns from this migration recur across Solana-to-Stylus ports.

Accounts become contract storage

Solana stores each piece of state in a separate, dedicated account. Stylus stores everything inside the contract.

Solana:

#[account]
pub struct Multisig {
    pub owners: Vec<Pubkey>,
    pub threshold: u64,
    pub nonce: u8,
    pub owner_set_seqno: u32,
}

#[account]
pub struct Transaction {
    pub multisig: Pubkey,
    pub program_id: Pubkey,
    pub accounts: Vec<TransactionAccount>,
    pub data: Vec<u8>,
    pub signers: Vec<bool>,
    pub did_execute: bool,
    pub owner_set_seqno: u32,
}

Stylus:

#[storage]
pub struct Transaction {
    target: StorageAddress,
    value: StorageU256,
    data: StorageBytes,
    signers: StorageVec<StorageBool>,
    did_execute: StorageBool,
    owner_set_seqno: StorageU32,
}

#[storage]
#[entrypoint]
pub struct Multisig {
    owners: StorageVec<StorageAddress>,
    threshold: StorageU64,
    owner_set_seqno: StorageU32,
    tx_count: StorageU256,
    transactions: StorageMap<U256, Transaction>,
}

Key shifts: Pubkey becomes Address, Vec<T> becomes StorageVec<StorageT>, and separate Transaction accounts collapse into StorageMap<U256, Transaction>. The nonce disappears (no PDA derivation in EVM), while tx_count is added as an explicit identifier counter.

PDA signers become the contract address

On Solana, the multisig executes transactions by deriving a PDA and using it to sign a cross-program invocation:

let multisig_key = ctx.accounts.multisig.key();
let seeds = &[multisig_key.as_ref(), &[ctx.accounts.multisig.nonce]];
let signer = &[&seeds[..]];
solana_program::program::invoke_signed(&ix, accounts, signer)?;

On Stylus, the contract is the signer. When it makes an external call, msg.sender on the receiving end is the contract's own address:

let call_context = Call::new().value(value);
let result = self.vm().call(&call_context, target, &data);

This simplifies the self-governance pattern. On Solana, set_owners requires a PDA signer account derived from specific seeds, validated through Anchor constraints. On Stylus, it is a four-line check:

fn require_self_call(&self) -> Result<(), ContractError> {
    if self.vm().msg_sender() != self.vm().contract_address() {
        return Err(ContractError::Unauthorized(Unauthorized {}));
    }
    Ok(())
}

Errors get richer

Anchor errors are essentially u32 codes with human-readable messages attached at compile time. A client learns that “not enough owners signed” but not how many did sign or how many were needed.

Stylus errors, defined through the sol! macro, carry structured data:

error NotEnoughSigners(uint64 required, uint64 provided);

This improves off-chain diagnostics. Tooling can programmatically parse the error, display the gap, and help users understand exactly what went wrong.

Why structured knowledge matters

A simpler experiment is to ask an LLM to “port this to Stylus.” The result can look plausible while missing runtime-critical differences like reentrancy assumptions, storage semantics, or ABI constraints.

StylusPort improves this with retrieval plus constrained prompts: research first, implementation second, and an explicit plan with risk analysis and architecture mapping.

The two-phase workflow also creates a practical review gate: inspect the migration plan, challenge architectural choices, and correct direction before implementation.

That division of labor matches the principle we discussed before: the model accelerates boilerplate and pattern transfer, while humans validate design and audit correctness.

Conclusion

Structured knowledge plus AI execution can produce a reliable migration starting point. Here, the plan was reviewable, the generated contract compiled, and tests covered many rejection paths. What remains is the hardest work: auditing correctness, testing realistic execution paths, and validating security invariants under deployment conditions.

Your mileage may vary

Coral Multisig is a single-program, 300-line repository. Real-world Solana projects are often multi-program monorepos with shared state, internal CPIs, and dense account relationship graphs. As complexity rises, omission risk rises with it.

The practical value of this tooling is speed-to-first-working-draft, not automatic correctness. Treat generated code as a starting point that still needs disciplined review, comprehensive testing, and security audit.

For MCP server setup instructions and the latest workflow details, refer to the StylusPort repository.

The handbook is also available to read online. In addition to practical porting guidelines, it also covers the differences between Solana programs and Stylus contracts, as well as security considerations.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We’re heading to Hong Kong for Consensus HK (Feb 10-12), where we’ll focus on institutional scaling and enterprise-grade security.

The enemy isn’t just code

Social engineering continues to be the top threat to crypto teams. We explain why attackers keep winning and how strong OpSec and zero-trust practices can dramatically reduce risk. Read more

Think your Web3 assets are safe?

Join our free OpSec session on Feb 26, 5 PM CET, and learn how hackers really strike and how to stop them!

Cyphertalk Podcast is live!

Our new twice-monthly podcast on real-world cybersecurity and privacy, kicking off with Security & Privacy in 2026, covering human risk, AI-driven threats, zero-knowledge tech, and what actually keeps systems resilient. Listen here

CoinList Token Sale Fund

We recently audited the CoinList Token Sale Fund, reviewing custodial smart contracts, backend flows, and security controls. We addressed all critical issues and received praise from CoinList for our partnership. Read more

Join our team!

Senior Blockchain Security Engineer | Job Posting Shared

Senior Zero-Knowledge (ZK) Blockchain Security Auditor (f/m/d) | Job Posting Shared

TGE security, done right

Launching a token? Don’t rely on hope or audit badges. Our latest guide offers a practical checklist for Token Generating Events (TGEs), covering layered security, early detection, and rapid incident response. Read more

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The system relies on role-based access control to separate committing, remitting, and ownership responsibilities, and is designed to support ERC-20 token contributions under strict operational assumptions. It incorporates internal accounting of committed and remitted balances, and administrative controls for managing privileged roles and final fund transfers.

In addition to the code review, we conducted a full threat modeling exercise covering on-chain contracts, backend systems, privileged operators, and external token dependencies.

During the audit, we identified several minor and informational issues related to trust assumptions, operational edge cases, and best practices. All resolved issues were fixed and verified, while the remaining findings were acknowledged by CoinList as acceptable within their security and governance model. Read the full audit report.

“Oak Security has been a great partner from day 1. They are very flexible, always open to communication, and able to support all our needs. Highly recommend them.”- Matt Delacour, CTO, CoinList

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We’re excited to announce the launch of Cyphertalk, a twice-monthly podcast exploring the realities of cybersecurity and privacy in a world that’s moving faster than our defenses.

In Episode 1: Security and Privacy in 2026, hosts Jade Doherty and Stefan Beyer (co-founder of Oak Security) dive into:

• Why humans are the #1 target: phishing, social engineering, supply chain attacks

• Remote work, context switching, and why “always-on” makes mistakes more likely

• AI as an arms race: scaling attacks vs improving defenses

• ZK/privacy tech maturity: new opportunities and new risks

• Why the “zero trust mindset” is about reducing impact, not paranoia

• Institutional security expectations and how crypto security is (slowly) evolving

Stefan also shares a personal story of a highly targeted “podcast invite” scam that nearly turned into a credential-stealing attack, a perfect example of why, in 2026, it’s less about never making mistakes and more about designing systems that limit blast radius when mistakes happen.

Listen & Subscribe:
🎧 Podbean
Apple | Spotify

We’d love your feedback! Follow, subscribe, leave a review, or send us your topic suggestions, we want Cypher Talk to cover what you really want to know.

Stay safe, stay curious,
Oak Security

Web3 projects consistently demonstrate a strong commitment to cybersecurity. Many protocols invest heavily in security reviews, engage reputable audit firms, and communicate their efforts transparently to users and investors. This reflects a shared understanding: security matters.

Yet recent high-profile incidents reveal that investment alone is not enough. Audits are more common than ever, but their effectiveness depends on how they are scoped, structured, and executed. The 2025 Balancer exploit offers a clear lesson. Despite multiple audits that deemed the protocol mature and secure, a vulnerability outside the defined audit scope was exploited, leading to losses of A. They performed the reviews exactly as specified. The key takeaway is that clearly defining the scope of security work is just as important as the quality of its execution.

The problem with cybersecurity RFPs

A Request for Proposals (RFP) is the document a project uses to engage a cybersecurity firm. It specifies:

• Which systems or codebases will be reviewed

• The depth and methodology of the review

• What is included in and excluded from the scope

• The expected deliverables

RFP defines a project’s security priorities. What is included signals which risks are considered most critical, while what is excluded reflects assumptions about acceptable or unlikely threats.

The problem is RFPs themselves require expert knowledge. Scoping a review is a security-relevant task. Ideally, scoping should involve a third-party expert. If the scope is incomplete, audits may leave critical risks uncovered. Often, RFPs are unclear, leaving auditors narrowing the scope further to submit competitive bids. This creates a race to the bottom, where security is optimised for cost rather than real-world risk coverage.

Current audit platforms reinforce this mindset. They are optimised for conducting audits, which encourages projects to treat security as an afterthought. Cybersecurity RFPs are conducted after development is completed, which violates the shift-left paradigm.

Why audits benefit from clearer framing

In many industries, certifications serve as indicators of safety. Web3 often adopts a similar mindset, treating audit reports as proof of security.

Audits are highly valuable, but they are limited to the scope of a specific engagement. Auditors focus on the tasks assigned to them, which can be a strength as long as the scope encompasses all relevant risks. Poorly scoped audits, even if executed flawlessly, can give a false sense of security. Clear, thoughtful framing of security objectives ensures audits deliver real-world protection rather than just a report.

Advancing the RFP process

When used intentionally, RFPs remain one of the most effective tools for commissioning security but only if carried out by experts and early in the development cycle:

• Engage security expertise early
  Before soliciting proposals, internal security leads, virtual CISOs, or external advisors can assist in defining the scope.

• Separate scoping from execution
  A neutral expert can design the RFP and evaluate bids, allowing auditors to focus on delivery while improving coverage.

• Evolve audit platforms
  Supporting adversarial testing, follow-up reviews, and remediation leads to stronger, longer-lasting outcomes.

• Emphasise outcomes over checklists
  Outcome-driven security aligns incentives around resilience, risk reduction, and user protection.

Security as a continuous discipline

Web3 does not suffer from a lack of audits. It has an opportunity to better align security investment with security outcomes. By refining how security work is defined and commissioned, the industry can:

• Set clearer expectations

• Improve collaboration between teams and auditors

• Build more resilient systems

In cybersecurity, outcomes are shaped early. When projects ask better questions, they receive better protection.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.