Safe Modules and Guards Explained: The Most Overlooked Attack Surface in Your Multisig

Here's a question most crypto teams don't like answering:

Can you name every module that's enabled on your Safe right now?

If your answer is "I'm not sure," you're in good company.

Most teams spend a lot of time getting their multisig setup right. They debate whether it should be 2-of-3 or 3-of-5, carefully choose trusted signers, invest in hardware wallets, and document signing policies.

Then, somewhere along the way, someone enables a module—maybe for automation, account recovery, or a one-off integration—and eventually everyone forgets it's even there.

The problem is that an enabled module doesn't care about your signature threshold. It can move funds from your Safe without requiring a single signature.

That's why modules and guards remain one of the most overlooked attack surfaces in multisig security. In this guide, we'll look at what they are, why they exist, and how to make sure they aren't quietly putting your treasury at risk.

What Is a Safe Module?

A Safe (formerly Gnosis Safe) is the most widely used multisig wallet in crypto. By default, it works exactly as you'd expect: a transaction only goes through after the required number of owners approve it. Whether your threshold is 2 of 3 or 3 of 5, nothing happens until enough signatures are collected.

A module is an optional smart contract that extends your Safe's functionality. Think of it like installing an app on your phone. The phone itself doesn't change—you simply give it new capabilities.

Some common, legitimate examples include:

• Allowance modules: Let a team member spend up to a predefined limit (for example, $5,000/month for operational expenses) without collecting signatures every time.
• Recovery modules: Help you regain access if one or more signers lose their keys.
• Automation modules: Handle recurring payments, DCA strategies, or DAO operations. The Zodiac suite is a well-known example.

Modules exist because managing everything through a pure multisig can become frustrating. Nobody wants to chase three different signers just to approve a routine payment. Modules make day-to-day operations faster by trading a little control for a lot more convenience.

And that's exactly where the risk begins.

The Part Nobody Tells You: Modules Bypass Your Signatures

Here's the detail that catches even experienced teams off guard:

Once a module is enabled, it can execute transactions directly from your Safe. No signatures. No threshold. No approval flow.

Your 3-of-5 setup? The module doesn't go through it.

That's not a vulnerability; it's how modules are designed to work. It's also what makes features like spending allowances and automation possible. But it comes with important security implications.

• A malicious module is effectively a backdoor with unrestricted access to everything your Safe holds.
• A buggy module can be exploited to drain funds, even if every signer follows perfect security practices.
• A forgotten module that was enabled years ago for an integration your team no longer uses becomes an open door that nobody is watching anymore.

Put simply, your multisig is only as secure as the weakest module attached to it.

You could have five hardware wallets stored in five different countries, and it still wouldn't matter if a single compromised module has permission to execute transactions.

This is exactly why attackers target this part of the stack. Convincing three careful people to approve a malicious transaction is difficult. Finding a vulnerable or over-permissioned smart contract is often much easier.

Some of the industry's biggest multisig-related losses, including the record-breaking Bybit hack, didn't break the cryptography behind multisigs. They simply found a way around it.

What Is a Safe Guard?

If modules add capabilities to your Safe, guards do the opposite; they enforce restrictions.

A guard is a smart contract that checks every transaction before your Safe executes it. If a transaction breaks the rules you've defined, the guard can block it before it goes through.

Teams commonly use guards to enforce policies such as:

• Only allowing transfers to a pre-approved list of addresses.
• Blocking risky operation types that the team never intends to use.
• Setting spending limits or restricting transactions to specific time windows.

When configured properly, a guard acts as a safety net. Even if a convincing phishing attack tricks your signers, a well-designed guard can stop a malicious transaction before any funds leave the Safe.

But guards come with their own trade-offs.

Because every transaction passes through the guard, it has enormous control over your Safe. If the guard contract is malicious—or simply contains a bug—it can reject every transaction, effectively freezing your Safe and preventing you from accessing your own funds.

In other words, installing a guard you don't fully trust is like giving someone the authority to veto every transaction your treasury ever makes.

Modules vs Guards: Quick Comparison

How Do You Know If Your Safe Is at Risk?

Ask your team these three questions this week:

1. What's enabled on our Safe right now?

Not what you think is enabled: what's actually on-chain.

Old integrations, test deployments, and one-time tools have a habit of sticking around long after everyone has forgotten about them.

2. Who reviewed those contracts?

A module has as much power as a signer; in many ways, even more, because it doesn't need anyone else's approval to execute transactions.

Treat every module with the same level of scrutiny you'd apply to adding a new owner. Has it been audited? Is it still actively maintained? Do you trust the team behind it?

3. Has our configuration drifted over time?

Safes evolve. Owners are replaced, signature thresholds change, and modules are added or removed.

A configuration that was secure when your Safe was created may look very different today. The problem is that most teams rarely stop to review those changes.

If you can't confidently answer all three questions, you probably don't have a multisig problem.

You have a visibility problem.

And unlike many security issues, visibility is one of the easiest things to improve.

Check Your Safe in Seconds, Free and Read-Only

This is exactly why we built Multisig Inspector at QuillAudits.

Just paste your Safe address, and you'll get a complete on-chain security report showing your owners, signature threshold, enabled modules, module exposure risks, and any configuration drift. These are the exact blind spots we've covered throughout this article.

And because we know security teams are (rightfully) cautious about interacting with their treasury, Multisig Inspector is designed to be completely read-only.

• No wallet connection: Simply paste your Safe address.
• Read-only by design: It can't create, approve, or sign transactions.
• No backend database: Nothing about your Safe is stored on our servers.
• Exportable reports: Share the results with your team, DAO, auditors, or compliance stakeholders as part of your security documentation.

Running a scan takes less time than reading this article.

Scan your Safe now

If the report raises questions, or your treasury is valuable enough that "probably secure" isn't good enough, our team also performs comprehensive multisig security reviews that go beyond configuration checks.

Conclusion

At the end of the day, a multisig is only as secure as the configuration behind it. Teams spend a lot of time protecting owner keys and setting the right signature threshold, but it's just as important to understand the modules and guards attached to the Safe. Reviewing them regularly, removing anything you no longer need, and keeping an eye on configuration changes can eliminate risks that are easy to miss. A few minutes of visibility today can prevent a costly surprise tomorrow.