How We Engineered a Customizable Rules List for Smarter AI Phishing Protection

At Dashlane, our goal is to help organizations strengthen their defenses against phishing while adapting to their unique environments. Every company has its own systems, internal tools, and workflows—and cybersecurity solutions must fit those realities.

That’s why we built the new Custom Rules List for our AI Phishing Alerts.

Our proprietary AI model detects suspicious sites directly within the Dashlane extension, protecting users from phishing attempts without compromising our zero-knowledge principles.

But we know that security isn’t one-size-fits-all. For some companies, legitimate internal portals or partner sites might look unconventional enough to trigger a phishing warning. Instead of forcing every team to conform to a fixed global policy, we wanted to give admins the ability to customize their Dashlane experience to match their corporate context.

The Custom Rules List lets admins decide how Dashlane should behave for specific domains—whether that means silencing alerts for trusted internal sites or finetuning which warnings employees see. This flexibility empowers organizations to balance protection with usability, maintaining strong security coverage without unnecessary friction.

In this article, we’ll dive into how we designed and built this feature: From the security architecture that keeps every company’s rules private to the engineering choices that make it scalable and future-ready.

To turn this idea into reality, we needed a mechanism that could distinguish between global domains—safe for all users—and internal domains that are unique to each organization. This led us to design a two-tier system for managing trusted websites. Each tier serves a different purpose but works together to maintain both usability and security across environments.

The solution is not one, but two distinct allowlists:

As we scoped the requirements for our allowlists, an idea emerged: What if admins could do more than just skip phishing alerts based on a domain?

And because most allowlist complexity resides not in its format but in its storage and distribution, turning the allowlist into a much more flexible list of custom rules seemed like a low-effort, high-reward opportunity.

So, what is a custom rule? It’s simple. A custom rule is defined with a list of domains and a list of actions. 

Admins can create new rules and see the list of rules through a dedicated interface in the Admin Console.

How to create a custom rule in the Admin Console

Custom rules list view

For a feature like custom rules, the architecture needs to be secure, scalable, and adaptable. Here’s a look at the key decisions we made for our first iteration.

The list of custom rules is encrypted in transit between the extension and the secure enclave through our secure tunnel architecture (an encrypted communication established between a Dashlane extension and a Dashlane secure enclave). Then, the tunnel payload is decrypted by the enclave.

Next, the list of rules is validated,  encrypted again, and signed by the enclave using AES-256-CBC-HMAC—this time using a key that’s specific to the team and limited in scope to the encryption/decryption of the rules list. We include a team identifier in the encryption context, which guarantees that, even if a malicious actor gained access to our storage, they couldn't misattribute one team's rules to another.

For an extra layer of protection, when sending the rules to user devices, we don’t send a cleartext list of domains. Instead, we send the hashes of those domains. From there, the extension hashes the current domain and its subdomains and looks for matches. Only the admins will receive the cleartext list of domains when querying the servers for the list.

In our system, the ratio of reads to writes is extremely unbalanced because we expect thousands of reads for every single write.

The most frequent operation—getting custom rules for the end users—will happen in the background and, thus, will have no noticeable effect on user experience if it becomes slow. Writes, on the other hand, are triggered by admins from the Admin Console, and slowness there could result in a painful user experience.

So here is our dilemma: Optimize for reads (which, in turn, means optimizing for cost and minimized impact to other services) or optimize for writes (which might have a more noticeable impact on user experience).

For this first iteration, we chose a design that optimizes for reads but makes few assumptions besides that: Storing the custom rules in an object storage (AWS S3) with the list of rules encrypted in a single block. This enables us to demonstrate value and put our concept to the test at scale before deciding in what direction to optimize.

We could have used databases like MySQL and DynamoDB (these are commonly used at Dashlane), but their main benefits—like indexing and querying individual fields—are nullified when the data is encrypted as a single, opaque block.

Regarding DynamoDB, something else we had to consider is that DynamoDB items have a size limit of 400KB. This could have become limiting had we decided to store the entire list in a single item. S3 provides a simple, scalable, and cost-effective solution; it’s everything we need until we can test our hypothesis and confirm the value of this feature in the real world.

At this stage, there are still some unknowns about how customers will use this tool in practice. Will they put all the domains in one rule and group by actions? Will they define groups of domains and, for each group, decide what actions should apply to it? How often will they update the rules?

Once we start observing how admins use the tool, we can improve it based on their actual feedback rather than on how we imagine them using it.

This is just the beginning. We already have a few ideas for functional and technical improvements. Which ones get implemented will depend on the feedback we get and the behaviors we observe.

Here are a few examples:

We began our journey with the critical need to support enterprise customization of our phishing protection features.

This exploration has not only resolved an immediate challenge but has also laid the groundwork for a versatile, general-purpose tool poised to enable a multitude of future capabilities, evolving as we gather real-world insights into its usage.

Our commitment is to continuously enhance and adapt it based on user feedback and observed behaviors, ensuring it remains a robust, effective solution that meets the needs of our customers.