How to Build a Faster Response to Salesforce Threats With Canaries

Salesforce environments are well defended against external intrusion, yet breaches via user errors remain a significant concern. A curious employee, a compromised credential, or a misbehaving integration can all put sensitive information at risk. Salesforce Event Monitoring and Transaction Security, part of the Shield offering, provides outstanding observability and policy enforcement to help protect your organization against these threats, stopping them as they happen or sometimes after and capturing the details of what has transpired.

You can further that security using canary records and canary fields, allowing you to detect and apprehend suspicious behavior with precision even sooner. These hidden tripwires remain invisible to your business users while revealing misuse, compromise, or overreach by triggering alerts the moment they are interacted with. 

Canaries are not an option you’ll find to enable in Salesforce, and instead are a standard security technique you can use within Salesforce solutions. You will need Event Monitoring, which is made available in a Trailhead Playground Org if you are curious and not a Shield customer yet.

Canaries vs. Honeypots

If you have been involved with security products and techniques over recent years, then canaries may sound a lot like honeypots – but there are significant differences between the two. Both canaries and honeypots are defensive tools, but they serve different purposes.

Honeypots are decoy systems or environments designed to attract attackers. They simulate real systems to observe behavior and collect intelligence.

Canaries are passive and embedded within production systems. They are not meant to attract attention – instead, any interaction with them is inherently suspicious, immediately signalling that something unusual is happening.

A Brief History of the Term

The concept of the “canary” originates from coal mining. Miners would bring small canary birds underground with them, as the birds were extremely sensitive to toxic gases like carbon monoxide. If the canary stopped tweeting, it warned the miners of unseen danger.

In cybersecurity, the same principle applies. A canary silently signals trouble the moment anyone or anything interacts with it. An alternative name is cookie, such as a stack cookie, however, it is easy to conflate them with browser cookies, so we will stick with the term canary.

Detecting Suspicious Activity

Using canaries as part of a Salesforce security solution helps you target three specific types of threats when they have managed to bypass all other measures.

1. Internal Staff Activity: If an internal user adds a canary field to a list view or report, or accesses a canary record, it indicates exploration or unauthorized data handling.
2. Compromised Accounts: External threats often use stolen credentials or API tokens to enumerate schemas and extract data. Canary records and canary fields are likely to appear in that process and trigger alerts.
3. Third-Party Apps: External Client Apps or Connected Apps may be misconfigured or exploited. Interaction with canary records and canary fields highlights unintended exposure or malicious data collection, enabling rapid containment.

Creating Canary Records

A canary record is a standard Salesforce record that serves no business function and exists only for detection. They are tripwires that you only stumble upon through unauthorized access. Event Monitoring can fire UriEvents (Classic) and LightningUriEvents when they are accessed directly through a record page, otherwise other events can contain them in the list of records returned such as APIEvents, ListViewEvents, and ReportEvents.

They are inserted at regular intervals throughout your data, like normal records, and in most cases, they’re silently omitted from your business-as-usual. You will use an identification field to flag a canary record and filter them out of standard use, or trigger an alert if accessed.

Key Design Guidelines

Placement in Sensitive Objects

• Create canary records within all objects, both standard and custom, that hold confidential or sensitive data.
• Avoid using a dedicated, separate custom object. Attackers often scan only known or business-relevant data, so embedding canaries across standard objects or ones used by your organization increases the likelihood they will surface during unauthorized access.
• Consider whether external objects can support, or should contain, canary records, depending on their source and the capabilities of the source system. It is normal for external objects to be omitted due to compatibility issues with third-party systems.
• Avoid canary record usage with objects provided by managed packages unless you have specifically worked with the vendor for their inclusion, or they have otherwise explicitly allowed for their usage and documented the method to configure them.

Baiting Record Access

• Especially useful when finding internal threats, using the names of well-known celebrities, government officials, or even company executives will make unauthorized record access much more alluring to rogue employees.
• Use appropriate sharing rules to ensure access to the canary records for user accounts you wish to entice towards them. However, do not make sharing rules more permissive for non-canary records as a result.
• Special attention may be required when using Agentforce. Ideally, agents should also have access to canary records, detecting agent-based breaches. However, there may be cases where Restriction Rules can become a useful tool to exclude them from exposure.

Discrete Identification Fields

• Do not name your identification field something obvious like IsCanary__c. Instead, choose a field name and design unique to your organization.
• Provide no clues; instead of a checkbox to denote a canary, consider using alternative data types or values, such as a numeric threshold, an unconventional picklist value, a string value, or a distinctive geolocation. Try to vary field types to keep your implementation unpredictable.
• Consider storing the identifier in an existing standard field to reduce suspicion.
• Contact Salesforce Support if the field requires a custom index to avoid performance issues with subsequent filtering.

Exclusion from Normal Operations

• Exclude canary records from list views, reports, and all automation logic, including Flows, Apex, and Integration Procedures, using filtering.
• Techniques such as using a Selector Layer or Named Queries can help you filter out canary records centrally, in an enterprise code and agent-friendly manner.
• Canary records should not appear anywhere in day-to-day business operations.
• If you are targeting internal threat actors, you may bend these rules. However, do so with caution using a targeted and well-controlled strategy.

Freshness and Archival

• Create new canary records periodically, such as once per month. Determine a ratio of legitimate records to canary records that balances the overhead in storage, speed of detection, sensitivity of records, and your team’s size when administering. You will want them spread throughout your creation dates.
• Do not delete or archive older canaries unless you are also removing data of that same vintage. Retaining them throughout your data ensures that even broad queries or historical exports will interact with at least one canary record, expanding detection coverage across your entire dataset.
• Scheduled Flows, Scheduled Apex, or DevOps tooling can help with automated creation.
• Provide Record Ids to your security team when monitoring events outside of Salesforce.

Backup and Integration Exceptions

• Backup systems should either exclude canary records and canary fields, or monitoring logic should ignore the backup integration user’s interactions.
• This prevents false positives while keeping real-time detection for all other access patterns.

Creating Canary Fields

Canary fields are added to existing objects that appear sensitive and valuable but are only there for detection purposes. You’ll not include them by default on pages, lists, reports, or in API queries, but they are ready to be added for those poking around your organization’s data, tripping the alarm.

Recommended Configuration

• Use field names that appear compelling, like SSN__c, Credit_Card_Token__c, or Salary_Info__c. They should look legitimate but contain no real data.
• Remove them from record pages, reports, list views, and automation logic.
• Give field-level security access to users and integrations so that if a threat actor or compromised credential queries these fields, the activity is recorded by Event Monitoring. Without field access, a canary field cannot lure access attempts.

Integration With Event Monitoring and Transaction Security

Event Streams

Event Monitoring can generate events which can be streamed to a monitoring platform or security tool to detect canary interactions quickly and simply. You can also handle events on-platform through triggers in Apex and using Platform Event-Triggered Flows. However, caution is advised for any automated actions beyond reporting activity.

Transaction Security Policies

Transaction Security policies can automatically act when a canary field is accessed, or with the use of some Apex when a canary record is accessed. A system permission, Exempt from Transaction Security, can be assigned to integration users for purposes such as backups.

Supported actions include:

• Blocking the request
• Requiring multi-factor authentication (MFA)
• Sending an in-app notification or email to the security team

Whilst Transaction Security cannot itself terminate sessions, integration with Event Monitoring allows third-party systems such as AWS EventRelay to forward events to your Security Information and Event Management (SIEM) solution. This enables your Security Operations Center (SOC) to immediately investigate, terminate sessions, and also lock down the user account across multiple connected systems.

Salesforce is also introducing Security Mesh, which provides additional, alternative capabilities for organizations to manage automated response and detection centrally.

Canary Field Example Using Transaction Security

As an example, you can create a canary field of your own with Transaction Security in a Trailhead Playground Org to try it out in action. In our demonstration, we have created NextOneTimePasscode__c, an enticingly named text field.

Next, you will need to find Transaction Security Policies in Setup, either by using the quick find search or navigating to Security > Event Monitoring > Transaction Security Policies, and enabling Transaction Security.
Select New, and you will be offered the choice of clicks or code. For now, we will stick with clicks and use the Condition Builder. Please note that the use of Apex here should only be for identifying the conditions under which Transaction Security should take action.

We can now select the conditions that trigger the policy. For this example, we will select the Report Event when the Queried Entities contains the Account Object and either the Name of Columns or the Name of Grouped Columns contains our canary field NextOneTimePasscode__c.

Finally, we will configure the appropriate action, in this case, a custom message informing the user that their ability to access the field has been blocked, and an in-app notification for our security team to investigate.

Now, when a user attempts to add the field to a report, they will be met with the following custom message we have just configured.

A similar policy can be created for List View access to the same field using a List View Event where the Queried Entities contains the Account Object and the Name of Columns contains our canary field NextOneTimePasscode__c.

Best Practices

• Start slowly, do not underestimate the work required to implement canary records in particular.
• Distribute canary records throughout all sensitive data objects.
• Choose subtle and organization-specific fields and values.
• Give at least read-only field-level security access to canary fields.
• Exclude canary records from list views, reports, and automations.
• Exclude canary fields from record pages, list views, reports, and automations.
• Ensure that considerations have been made for Agentforce Agents where appropriate.
• Filter alerting rules to ignore backup accounts.
• Stream and monitor Event Monitoring through your SOC’s SIEM platform to prioritize and investigate alerts rapidly.
• Remember to provide new Record Ids to your security team if they are using tooling for Event Monitoring outside of Salesforce itself.
• False alarms can occur unexpectedly. Be careful and keep a human in the loop to prevent locking yourself out or impeding business as usual.
• Consider deduplication matching logic and other non-obvious record access.
• Document your canaries, but store that documentation securely and do not widely circulate it.
• Remove any trace of canaries and their detection in developer sandboxes accessed by third-party teams.

Final Thoughts

By introducing canary records and canary fields into Salesforce, organizations can detect unauthorized activity that might otherwise remain hidden, responding to active threats sooner. 

Placing them within sensitive data objects, assigning unique identifiers, and integrating them with Event Monitoring and Transaction Security creates a powerful detection solution capable of exposing threats quickly.

Combined with third-party event processing, canary mechanisms help transform your Salesforce organization into a proactive and intelligent defense system that alerts you to unauthorized behavior before it escalates.