Digital asset security at scale: audits, agents, formal verification

Digital asset security conversations often get trapped in tooling. Which audit firm. Which monitoring provider. Which dashboard. That’s understandable, because these are concrete decisions and most teams want a checklist they can execute.

But if you want to build security that holds up at scale, you have to step back and look at the operating model. The biggest gaps I see are not about one missing product. They’re about how organizations conceptualize identity, how they outsource responsibility, and how long they assume they can delay foundational controls.

This is a summary of the main points I shared in a recent conversation on digital asset security with Olympix. You can watch the full interview here.

‍

Non-human identities in web3 security: governance for bots, agents, and smart contracts

When teams talk about “non-human identities” they often think of them as special cases: smart contracts, bots, automated transaction engines, operational agents, CI/CD processes. The common mistake is to treat these things as “just systems” rather than identities that need governance.

The better mental model is simple. Functionally, these identities are no different than full-time employees. They do work. They access resources. They initiate actions. They can be misconfigured. They can be compromised. And they can become the most dangerous insiders in your environment because they tend to be highly privileged and poorly monitored.

If your organization has adopted the principle of least privilege for employees, the same should apply to non-human identities. In fact, you should start from the strictest version of that principle: zero standing privileges.

Zero standing privileges is a new label for an old idea. Access should not exist by default. Identity should request access only when it needs it, the system should evaluate context, and then access should be granted narrowly and temporarily. This holds whether the actor is a person or a process.

The second layer is to treat these non-human identities as part of your insider threat model. Insider threat programs often focus on humans because that’s where most organizations have historically had the visibility. But the same lens should apply to processes and agents. They are identities. They have patterns of behavior. They can deviate. And if you do not instrument them as insiders, you will miss some of your most meaningful signals.

‍

Smart contract security beyond audits: why audits and onchain monitoring aren’t enough

The dominant “security model” in crypto is usually some combination of audits plus on-chain monitoring. Both are valuable. The problem is not that they exist. The problem is that many teams treat them as the security program rather than components inside one.

The first fallacy is responsibility transfer. Some organizations implicitly assume that if an external firm gives them a thumbs up, the security obligation has been handled. That’s not how it works. Security responsibility does not move just because a third party ran tests.

The second fallacy is timing. Audits are point-in-time assessments. They do not continuously cover your attack surface. A contract can be audited in January and exploited in February with no meaningful changes to the codebase, because the vulnerability could be newly discovered or newly weaponized. This is why “zero day” exists as a concept. Unknown vulnerabilities are real. They’re also routine.

The third fallacy is staleness. Audits expire. If you are passing around a report from 12 to 24 months ago as evidence of security posture, you’re communicating that you do not understand the lifecycle. Even a strong report is only a snapshot.

The way I prefer to frame audits is that they should be among the last steps, not the first. Your internal program should be designed so that the auditor finds very little. If a team is disappointed that the auditor found nothing critical or high, that’s a misunderstanding of what good looks like. The goal is a mature internal pipeline that catches issues before they ever reach an external reviewer.

That pipeline should include layered preventive controls and layered detective controls.

Preventive controls include the things you expect: secure development practices, CI/CD controls, internal scanning (SAST and DAST), code review gates, key management policies, and tight access paths into production repositories and deployment workflows.

Detective controls exist because preventive controls will never be perfect. You need monitoring that looks for deviations, circuit breakers that limit blast radius, and operational procedures that assume something will eventually go wrong.

If you want to build a program that looks like what mature non-web3 organizations have been doing for decades, the key idea is layers. Not one tool. Not one provider. A system of controls where each layer compensates for the limits of the one above it.

‍

Building a digital asset security stack: threat modeling, key management, and deployment integrity

Teams often want a prescriptive list of “the stack.” But the stack is downstream of understanding what can go wrong.

The most underrated practice in digital asset security is threat modeling. Not because it replaces tools, but because it dictates which tools matter and where they should sit.

Threat modeling forces the organization to explicitly map the ways failure can happen. Who can update a contract. Where those keys live. What approvals exist before code reaches production. What would happen if a developer workstation was compromised. Whether ownership of an employee could translate into malicious injection into a production repository. Which operations are truly non-negotiable and what must be provably true.

You can do all the standard enterprise hygiene, and you should. Strong authentication, hardware keys, segmentation, data loss prevention, and the usual controls are table stakes. But web3-specific threats require web3-specific modeling. The value is not theoretical. It gives you a blueprint for controls that match your real risk.

For most teams, the practical place this shows up is in your build and deployment pipeline. The contract code might be clean, but the route into production is still an attack surface. Threat modeling should drive explicit controls around repo access, code review gates, and deployment authorization so that unauthorized code cannot reach production without detection.

‍

LLM security tools vs. formal verification: combining probabilistic and deterministic methods

There’s a growing debate about probabilistic tools versus deterministic methods. I don’t see this as a binary. Every organization should be doing both.

LLMs can be force multipliers when you use them correctly. The right way to deploy them is not to “yolo” instructions into a model and hope it behaves. You build structured agents with scoped roles and scoped access, the same way you would design responsibilities for an employee.

A purpose-built agent to review source code. Another to attempt exploitation. Another to reason about specific vulnerability classes. Independently operating, with guardrails and access boundaries aligned to the work. Used that way, LLMs can help a small team move like a much larger team. They can expand coverage and accelerate discovery earlier in the pipeline.

On the deterministic side, I remain a strong advocate for formal verification. It is uniquely important in web3 because the environment is unforgiving. Transactions are immutable and often irreversible, and the assets involved are bearer assets. When things fail, they fail publicly and at speed.

Formal verification is best understood as building mathematical guarantees about behavior. Not “we think it works,” but “we can prove it cannot violate this property.” For example, a balance should never be lower than a defined threshold, or a safety invariant must always hold. You may not be able to prove every single possible contingency, but there are non-negotiables that you should be able to prove.

The reason adoption is still limited is that it’s hard. It touches math and engineering discipline in ways many organizations are not staffed to handle. But tools are improving, and the importance is increasing. As the space matures, formal verification will move from “nice to have” to “expected,” at least for certain categories of contracts and invariants.

The real advantage of combining these approaches is timing. Identifying issues after going live is always more expensive and riskier. Bug bounties and post-deploy monitoring help, but you are already live. Updating production code introduces new risk, operational disruption, and additional opportunities for compromise.

The best place to catch issues is before deployment. LLM-based testing and formal guardrails both push detection earlier, where fixes are cheaper and the blast radius is smaller.

‍

“Fix it later” security debt in web3: why security programs must start early

If I had to pick one belief the industry continues to get wrong, it’s the mindset of “I’ll fix it later.”

I understand why it happens. Many projects begin bootstrapped or lightly funded. They are not hiring CISOs. They are not hiring dedicated security engineers. They take existing engineers and assign security as an additional responsibility.

The problem is that engineering and security are different disciplines. Engineers are not security people, and security people are not engineers. The way we think, what we prioritize, and what we notice are different. Asking one to be the other usually produces a fragile outcome somewhere in the system.

Security is foundational. It is much harder to retrofit later, and the longer you delay the harder the retrofit becomes.

The analogy I like is construction. You don’t build a house and then decide you’ll install plumbing later. The pipes go in before the walls close. Security works the same way. Foundational controls, key governance, deployment integrity, identity boundaries, and monitoring hooks should be part of the architecture from day one, even if they start minimal and mature over time.

‍

Digital asset security at scale requires identity governance and layered controls

Security at scale is not a vendor decision. It’s an operating model decision.

Treat non-human identities as identities, with the same rigor as employees. Stop assuming audits can be a substitute for internal programs. Build layered preventive and detective controls. Start from threat modeling, not tool shopping. Use both probabilistic and deterministic methods intentionally. And retire the idea that you can “fix it later” without paying a multiple in cost and risk.

If you get those principles right, the tool choices get much easier.