Allowlist

How ChainPatrol tracks trusted brand-owned domains, wallets, and social accounts to reduce false positives and serve as a baseline for phishing detection

​

Overview

An allowlist is a curated list of known, trusted assets that are explicitly recognized as legitimate within ChainPatrol.

Assets added to the allowlist are considered official or approved and are treated differently from unknown or suspicious assets during threat detection and analysis.

ChainPatrol can automatically identify legitimate assets through integrations — for example, the Vercel integration confirms which Vercel deployments belong to your organization, reducing false positives and speeding up the review process.

Allowlisting helps ChainPatrol distinguish between genuine brand-owned content and potential impersonation or abuse.

Unlike blocklists, which focus on malicious content, allowlists define what is known to be safe.

​

Why We Use an Allowlist at ChainPatrol

Allowlists play a critical role in improving both detection accuracy and signal quality.

​

Dual Purpose

Exclusion from Detection - When an asset is allowlisted, it is excluded from automatic threat detection. This prevents legitimate brand-owned assets from being mistakenly flagged as impersonation, reduces false positives, eliminates unnecessary investigations, and improves team efficiency. For example, your official website example.com is allowlisted, so it will never be flagged as a phishing site, even if detection rules would normally trigger on brand-related keywords.

Reference Baseline - Allowlisted assets are used as reference points when analyzing potentially malicious content. ChainPatrol can compare a suspected phishing page against an allowlisted official website to determine whether branding is being copied, layout is being imitated, content is being duplicated, and visual elements are being stolen. For example, a suspicious site examp1e.com is detected. ChainPatrol compares it against your allowlisted example.com and identifies 95% visual similarity, identical logo usage, and copied page structure, resulting in high-confidence brand impersonation detection.

This dual role (exclusion from detection and use as a trusted baseline) makes allowlists essential for reliable brand impersonation analysis.

​

What Can Be Allowlisted?

In ChainPatrol, any asset type can be allowlisted:

• Domains and URLs - Official websites and web applications
• Social Media Accounts - Verified brand and employee accounts
• Application Pages - App store listings and hosted content
• Development Environments - Testing, staging, and QA environments
• Preview Deployments - Vercel, Netlify, and other preview URLs
• Blockchain Addresses - Official smart contracts and wallets
• Email Addresses - Official company and team emails
• Other Assets - Any asset legitimately controlled by your organization

Allowlisting is not limited by platform or asset category, as long as the asset is known to be legitimately controlled by the organization or brand.

​

What Should and Shouldn’t Be Allowlisted?

​

Should Be Allowlisted ✅

Assets that are owned, controlled, or intentionally operated by the organization or its brands:

Official Websites - Primary company website, product websites, documentation sites, support portals, marketing landing pages. Example: company.com, docs.company.com, support.company.com

Verified Social Media Accounts - Official Twitter/X accounts, official Discord servers, official Telegram channels, official YouTube channels, verified employee accounts. Example: @CompanyOfficial, discord.gg/company-official

Internal Testing Environments - QA environments, staging servers, internal testing sites, employee development environments. Example: staging.company.com, qa-env.company.com

Development and Preview Pages - Vercel deployments owned by the company, Netlify preview URLs, GitHub Pages for official repositories, CI/CD preview environments. Example: company-app.vercel.app, preview-123.netlify.app

Official Blockchain Assets - Official smart contracts, treasury wallets, multisig addresses, token contracts. Example: 0x1234... (official token contract)

​

Should NOT Be Allowlisted ❌

Third-Party Content - Content that is merely tolerated but not controlled by your organization, including partner websites mentioning your brand, news articles about your company, third-party reviews or comparisons, and affiliate or reseller sites. Even if the content is positive or authorized, if you don’t control it, don’t allowlist it.

User-Generated Content - Content created by users, even on your platforms, including user profiles on your platform, community-submitted content, user comments or posts, and customer testimonials on external sites.

Assets Not Fully Controlled - Assets where you don’t have complete control or ownership, including shared hosting environments, third-party integrations, external widgets or embeds, and temporary or borrowed infrastructure. If there’s any doubt about control or ownership, err on the side of caution and don’t allowlist.

Important: Allowlisting an asset implicitly signals trust. Because allowlisted assets are excluded from automatic detection, incorrectly allowlisting an asset can reduce visibility into real threats.

​

Risk Handling and Escalation

Allowlisting does not permanently exempt an asset from scrutiny.

If an allowlisted asset shows suspicious behavior or is believed to be compromised, it can still be escalated, investigated, and acted upon.

​

Compromise Scenarios

Account Compromise - If your official Twitter account is hacked: Asset is allowlisted so automatic detection doesn’t flag it, community reports suspicious activity, manual investigation reveals compromise, asset is temporarily removed from allowlist, threat is blocked and reported, after recovery asset is re-allowlisted.

Domain Hijacking - If your domain is hijacked or DNS is compromised: Asset is allowlisted so automatic detection doesn’t flag it, monitoring detects unusual behavior or content changes, security team investigates, asset is removed from allowlist during incident, malicious content is blocked, after resolution asset is re-allowlisted.

Infrastructure Breach - If your hosting infrastructure is compromised: Allowlisted assets start serving malicious content, user reports or automated monitoring detect anomalies, incident response is triggered, affected assets are removed from allowlist, threats are contained and remediated, assets are re-allowlisted after verification.

This ensures that trust is not absolute and that compromised official assets do not become blind spots.

​

Expiry

Some assets should only stay on your allowlist for a while, such as a partner’s website or a campaign that runs for a season. Give these assets an expiry date and ChainPatrol removes them from your organization when it passes, so the allowlist doesn’t fill up with relationships that have ended.

​

What happens when an asset expires

1. Reminders - Organization owners and admins get a daily email digest that lists assets expiring in 30 days and in 7 days.
2. Expiry - On the expiry date the asset is marked Expired and a 14-day grace period starts. It stays allowed and on your organization during the grace period, so you can renew it if the relationship continues.
3. Final reminder - The digest warns you again 3 days before the grace period ends.
4. Removal - When the grace period ends, the asset is removed from your organization and monitoring for it stops. The digest lists what was removed.

Expiry removes the asset from your organization; it does not change the asset’s status. An allowed asset stays ALLOWED, so it is still treated as safe and is not flagged as a threat. Each removal is recorded in your organization’s audit log, the same way a manual removal is.

​

Setting an expiry

• When adding assets - In the Add Assets dialog, choose an expiry: in 6 months, in 1 year, or on a date. Through the API, pass expiresAt to Add Organization Assets.
• On the Allowlist page - Use Set expiry on an asset, or select several and set one date for all of them. Filter the list by Expiring soon or Expired to see what needs attention.
• From the API, CLI or MCP - Use the Set Asset Expiry endpoint, the chainpatrol orgs assets set-expiry CLI command, or the organization_assets_set_expiry tool in the MCP server.

An expiry date runs to the end of that day in UTC. Setting a new date on an expired asset renews it and ends its grace period. Clearing the expiry keeps the asset indefinitely.

Organization owners and admins can set, renew and clear expiry dates.

​

Granularity of Allowlists

Allowlists in ChainPatrol can be configured at different levels:

Organization Level - Assets allowlisted at the organization level are trusted for the entire organization, regardless of which brand they’re associated with. Use cases include corporate websites, shared infrastructure, company-wide social accounts, and central authentication systems. Example: company.com is allowlisted at the organization level, protecting it for all brands under the organization.

Brand Level - Assets allowlisted at the brand level are trusted only for that specific brand within the organization. Use cases include product-specific websites, brand-specific social accounts, individual product infrastructure, and brand-specific campaigns. Example: product-a.com is allowlisted for “Product A” brand but not for “Product B” brand.

This flexibility allows teams managing multiple brands to tailor trust appropriately.

​

Hierarchy Example

Organization: Acme Corp
├── Brand: Acme Protocol
│   ├── acme-protocol.com (Brand-level allowlist)
│   └── @AcmeProtocol (Brand-level allowlist)
├── Brand: Acme Wallet
│   ├── acme-wallet.com (Brand-level allowlist)
│   └── @AcmeWallet (Brand-level allowlist)
└── Organization-level allowlist:
    ├── acme.com (All brands)
    ├── @AcmeCorp (All brands)
    └── [e-mail] (All brands)

​

Who Can Update the Allowlist?

Allowlist management is restricted to organization administrators and authorized staff members.

• Organization Administrators - Full control over organization-level and brand-level allowlists
• Authorized Staff - ChainPatrol staff can assist with allowlist management
• Limited Access - Standard users cannot modify allowlists
• Audit Trail - All allowlist changes are logged and tracked

Limiting access helps ensure that allowlists remain accurate, intentional, and aligned with security best practices.

​

Best Practices for Allowlist Management

1. Be Conservative - Only allowlist assets you definitively control and trust
2. Regular Reviews - Periodically review your allowlist (quarterly recommended) to remove outdated or deprecated assets
3. Document Decisions - Maintain internal documentation of why assets were allowlisted
4. Remove Compromised Assets - Immediately remove any asset suspected of being compromised
5. Re-add After Verification - Only re-allowlist assets after confirming they’re secure and under your control
6. Set Expiry for Temporary Assets - Give partner and campaign assets an expiry date so they are removed when they are no longer needed

​

Key Takeaways

• Allowlisting reduces false positive noise: Adding your official assets filters them from detection sources, letting your team focus review time on actual threats
• Conservative allowlisting prevents blind spots: Only add assets you definitively control because allowlisted assets that get compromised won’t trigger automatic alerts
• Domain allowlisting uses smart matching: Adding example.com automatically trusts all subdomains, reducing maintenance while maintaining protection
• Allowlist changes require administrator privileges: This restriction prevents accidental or malicious allowlisting that could create security gaps