‍

The teams designing today's blockchain infrastructure are inheriting two decades of Web2 security assumptions, and most of those assumptions do not survive contact with decentralized systems. That mismatch, between how centralized enterprises think about trust and how distributed protocols actually need to operate, is one of the most under-appreciated risks in Web3 right now. Layer in the rapid adoption of AI tooling and AI agents, and the surface area expands faster than most teams can govern.

In a recent episode of The Security Table, we sat down with Yorke Rhodes, Co-founder of Blockchain at Microsoft, who has spent his career operating at the intersection of blockchain, AI, and enterprise-scale products. His vantage point, shaped by years inside Microsoft and adjacent ecosystems, gave us a sharp framework for thinking about where Web3 security is breaking, where AI helps, where AI hurts, and why verifiability is the only durable answer.

Below is a synthesis of the conversation, expanded with context for builders shipping high-stakes onchain systems.

The Fundamental Mismatch: Enterprise Trust Assumptions Do Not Translate to Web3

Cloud providers have spent fifteen to twenty years optimizing centralized infrastructure for scale. The result is impressive operationally, but the trust model behind it is alien to the one that distributed consensus actually requires.

As Yorke put it, when you come from an enterprise background, you tend to assume things about identity, permissioning, and trusted parties that simply do not exist in an open, cryptographically secured environment. A security team grounded in cybersecurity will look at single-party control, attack surfaces, and censorship resistance very differently from an infrastructure designer whose entire career has been built inside a centralized cloud.

The biggest hurdle, then, is conceptual. New enterprises and new providers entering Web3 bring trust assumptions that are fundamentally incompatible with the requirements of distributed consensus and open, secure infrastructure. Closing that gap is not a tooling problem first. It is an epistemic problem. Builders have to unlearn before they can build well.

This matters for Olympix's customers because so much of the institutional capital and engineering talent now flowing into Web3, from Fortune 500 enterprises to TradFi institutions building onchain, arrives carrying these legacy assumptions. The protocols they ship are only as resilient as the trust model they encode.

AI Is Powerful, and That Is Exactly Why It Is Dangerous in Security Work

Yorke was direct on this point. AI is genuinely an augmentation of human knowledge and skill. The productivity gains are real, especially in code generation, where developers and even non-developers can now ship work that would have been out of reach a few years ago.

But AI's power creates a specific failure mode. People assume the model already knows what it needs to know. They stop directing it. They stop questioning it. And the gaps in what the model considers, the references it pulls, the architectural choices it suggests, become invisible to anyone without the domain expertise to spot them.

Yorke shared a telling example from his academic research work. While trying to compile reliable source references on a complicated topic using reasoning models from both OpenAI and Anthropic, his team noticed that the models kept returning links to articles about the source rather than the source itself. The output looked authoritative. It was not. Without domain knowledge, no one would have caught it.

The lesson generalizes. AI will not think through a problem the way you want it to unless you have the knowledge to direct it that way. In smart contract security specifically, that translates to a hard truth: an LLM cannot reliably reason about novel attack vectors, economic edge cases, or composability risk without an engineer who already understands those domains shaping the prompt and validating the output. The "human in the loop" is not a nice-to-have. It is the load-bearing component.

The Agent Problem: Productivity Gains, Exponential Vulnerability

The conversation took a sharper turn when we got to AI agents. Agents are massive productivity multipliers, but they also extend your vulnerability surface in proportion to their reach.

Inside enterprises like Microsoft, this challenge is partially contained by decades of investment in role-based access control. Copilot was bolted onto an existing RBAC permissioning system, which is why it could safely unlock proprietary data for productivity gains. Standalone AI providers operating outside the enterprise security perimeter had to build that permissioning architecture from scratch, and many are still working through the implications.

In Web3, the problem is exponentially worse. As Yorke pointed out, decentralized systems typically do not have the same kind of permissioned governance to fall back on. When you register AI agents and set them off to act on your behalf, you have to ask:

• What are the boundaries of what they can do
• How are we monitoring their actions
• What models are they using
• What proprietary or sensitive data is leaking into those models through agent activity
• Who is accountable when an agent makes a costly decision

Most Web3 teams have not yet thought through these questions, because the tooling is new to them. But every agent connected to a smart contract development workflow, a treasury, or a governance system is now part of the trust boundary. If you cannot answer those questions, you do not have governance. You have hope.

Velocity Is Not Free, and Web3 Has the Case Studies to Prove It

Microsoft, Yorke noted, operates under a publicly stated security-first principle. The logic is simple: you cannot be a trustworthy brand unless security comes first, and that applies whether your customers are consumers, enterprises, or nation-states. In practice, this means that internal teams regularly struggle with velocity, because everything goes through security reviews and the security posture itself shifts as the threat landscape evolves.

That tradeoff is not popular with startups. It is, however, the price of resilience.

Yorke's challenge to Web3 builders was blunt. Setting aside outright fraudulent actors, you can pull together five to ten case studies of protocol-level failures where the root cause was not the core cryptography but the governance and security layer above it. Exchanges, bridges, custodians. Teams moved too fast without considering what needed to be considered. The exploits that followed were not exotic. They were obvious in hindsight.

This is precisely the gap Olympix was built to close. Audits, while necessary, happen too late and too infrequently to keep pace with modern Web3 development. When AI is generating a meaningful percentage of production code and agent-based workflows are accelerating commit velocity, point-in-time security reviews cannot scale. What protects high-value protocols is continuous, in-house, deterministic security: static analysis on every commit, automated mutation testing, fuzzing, and test case generation embedded in the development loop. Security has to move at the speed of development, not the cadence of quarterly audits.

Brand Reputation Is an Attack Surface. Verifiability Is the Only Durable Answer.

Some of the strongest material in the conversation came when we asked Yorke about the source of trust in blockchain systems today. Is it brand, or is it provable security?

His answer was unequivocal: it has to move to verifiable. Reliance on trusted brands has massive vulnerabilities. If a brand controls assets, that brand becomes a target, and the attacks come from every direction at once. Cyber attacks. Legal attacks. Geopolitical pressure. Going back fifteen years, the major breaches at companies like Target were direct consequences of being honeypots for consumer data. The exact same dynamic plays out today, only the assets are higher value and the attackers are better resourced.

The path forward is verifiability as critical infrastructure. Microsoft, internally, audits the source of code in its tech stack. The broader industry is investing in trusted execution environments, zero knowledge proofs, and post-quantum cryptography. Different tools, same underlying conviction: trust assumptions need to be replaced with provable guarantees.

For smart contracts, this is not abstract. Verifiability in development comes from rigorous test cases, mutation testing that hardens those test suites by introducing controlled mutations, formal methods, and automated proof of impact. Olympix's approach combines intermediate representation, custom detectors, symbolic execution, fuzzing, and AI working in concert, with the explicit goal of producing deterministic findings rather than probabilistic flags. When you are securing institutional-grade onchain finance, "the model thinks this is probably fine" is not a security posture. Mathematical certainty is.

Yorke made a related point about AI's role here. Responsible AI teams at Microsoft already use secondary agents to run test cases against code in real time as it is being developed. Dr. Sarah Bird, who leads that work, has described capabilities that simply were not possible with human-only review. The model is not replacing the human. It is extending what a human can verify, under the human's direction.

That is exactly the right framing for AI in smart contract security. Use AI to expand coverage of test cases and edge case generation. Use deterministic infrastructure to verify the results. Keep the engineer in the loop, with the domain knowledge to direct the work and validate the output.

The Hot Take: Governance Gaps Are the Existential Risk

We close every conversation by asking for a security hot take. Yorke gave us two, and both are worth sitting with.

First, the vulnerability of system design where governance is improper because it is not understood by the people building the system. If you are coming into Web3 from outside the space, your trust and security assumptions are fundamentally different from what distributed systems require, and that contextual learning takes time. Layer on the natural reluctance of incumbents and intermediaries to abandon old business models, and you get a huge risk surface for anyone new to blockchain, and increasingly for anyone new to the AI-Web3 convergence.

Second, on the optimistic side, the work in zero knowledge for verifiability has been astounding over the last decade. Proving times, recursion approaches, and post-quantum models are all advancing rapidly. The tools for verifiability exist. What is missing is widespread understanding of the governance requirements that have to wrap those tools to actually deliver the trust assumptions builders are reaching for.

That is the real challenge for the next phase of Web3. Not invention. Adoption, with the right governance.

Building Security In, Not Bolting It On

Yorke's conversation reinforces a thesis Olympix has held since the start. Security in Web3 cannot be a milestone. It cannot be a brand promise. It has to be infrastructure, embedded in the development process, running on every commit, producing verifiable outputs that engineers and institutions can trust.

The protocols that will earn institutional capital and survive the next wave of exploits are the ones that internalize this now. Trust assumptions get replaced with proofs. Audits become a checkpoint, not a strategy. AI becomes a multiplier on engineer productivity, governed by deterministic verification rather than probabilistic confidence. And governance becomes the connective tissue that makes all of it work across shared infrastructure.

For teams building at the convergence of AI and Web3, the takeaway is straightforward. The tools for verifiability are here. The question is whether your governance, your tooling, and your team are ready to use them.

If you are working through these questions for your own protocol, we would love to talk. Olympix partners with leading Web3 teams to embed proactive, deterministic security into the development workflow, from static analysis and mutation testing to automated fuzzing and formal methods. Reach out to see how we can help your team ship with confidence.