A transaction security policy is a rule that watches a real-time event in your Salesforce org, such as a login, an API call or a report export, and responds when the event meets conditions you set. The response is a block, a request for multi-factor authentication or a notification. The Transaction Security Policy Accelerator is a free Salesforce Labs app on the AppExchange that installs a library of prebuilt policies, so you do not have to build each one in Setup from scratch.
This guide explains what the Accelerator adds, what has to be in place before you install it, which policies Salesforce's Accelerator documentation names, and an order for turning policies on that keeps your users from being locked out. It is written for admins who own org security without a dedicated security team. The Cirra AI page for Salesforce admins describes how admins hand routine configuration work to an AI client while they keep the judgment calls.
The facts below come from Salesforce's announcement, the AppExchange listing, the Accelerator install guide and Salesforce Help as of October 23, 2026. The Accelerator updates through its managed package, so confirm each detail in your own org before you act on it.
What a transaction security policy does
Salesforce Help describes Transaction Security as a framework that monitors real-time events and applies actions to control user activity. Each policy pairs conditions, which evaluate an event, with actions that run when the conditions are met. Block stops the user's action. Multi-factor authentication asks for an extra verification step. A notification sends an in-app or email alert.
Policies come in two types. A Condition Builder policy is declarative and uses a subset of each event object's fields as conditions. An Apex policy needs a class that implements the TxnSecurity.EventCondition interface and can use any field on the event object. ReportEvent.Records, for example, is available only through Apex. The event types include LoginEvent, ApiEvent, ReportEvent, ListViewEvent, FileEvent and BulkApiResultEventStore, plus event stores for credential stuffing, session hijacking and anomalies.
Transaction Security is included in Real-Time Event Monitoring. Salesforce Help lists Enterprise, Unlimited and Developer Editions and says it requires a Salesforce Shield or Salesforce Event Monitoring add-on subscription. If your org has neither, you can still use this guide for planning, but the policies need that subscription to run.
What the Accelerator adds
Salesforce announced the Accelerator in a March 25, 2026 blog post as a Salesforce Labs app. The AppExchange listing shows it as free and says it installs as a managed package that receives automatic upgrades. Policies are grouped by security domain, including data protection, access control, integration risk and data loss prevention. Each policy carries built-in documentation on the risk it addresses, the event that triggers it and any setup it needs.
Salesforce's Trailhead module on deploying real-time security guardrails describes the library in three areas: blocking mass exports, requiring MFA for high-risk logins and spotting surges in integration activity. Salesforce Ben listed one-click deployment of commonly requested policies among the admin updates from Dreamforce '26.
The Apex behind the policies is published in the TSPAccelerator_PolicyApex repository on GitHub under the Apache-2.0 license. Its README says to clone the repository and change the Apex if you need different thresholds, allowlists or logic, and to test in a sandbox or scratch org first because the policies run in real time and can affect logins and API access.
Check these requirements before you install
The Accelerator's install guide, linked from the AppExchange listing, sets out prerequisites that catch many first installs. Check each one in a sandbox before you plan a production date.
- Licensing: Salesforce Event Monitoring or Shield must be licensed in the org. The guide says the install fails with an "ApexClass Invalid type" error without it.
- Platform: The guide lists Hyperforce, because the app depends on Event Log Objects, plus Lightning Experience and a System Administrator or equivalent user to install it.
- Authentication: Configure an External Client App, then an Auth Provider, then a Named Credential. The Named Credential must be named exactly TSP_Accelerator.
- Permissions: Administrators need the Modify Transaction Security Policies permission that the package adds. Other users need the TSP Accelerator permission set, and the guide lists system permissions to enable by hand: API Enabled, Modify Transaction Security Policies, Customize Application, View All Data, View Event Log Files, View Platform Events, View Setup and Configuration, and View Real-Time Event Monitoring Data.
Salesforce also introduced its own permission in 2026. Salesforce Help says the Modify Transaction Security Policy permission is now required, together with Customize Application, to create, update, delete, enable or disable policies, and that users with only Customize Application get read-only access. Treat everyone who holds these permissions as a privileged group. The post on least privilege for AI agents in Salesforce covers how to scope access for any tool or person that can change your org.
The policies the Accelerator documentation names
Salesforce's Accelerator documentation on AppExchange groups the library into six categories: Data Protection and Classification, Access Control, Security Model, Integration, Data Loss Prevention and Monitoring. The table lists policies the documentation names and what each needs before you activate it. The documentation does not state the action for these policies, so open each one after install and read its action, trigger and setup notes.
| Policy | What it watches | Set this up first |
|---|---|---|
| Detect API Access from Unapproved Third Party Apps | ApiEvent traffic from clients that are not on the allowlist | Add each approved client to Approved_API_Client__mdt. Client_Name__c must match ApiEvent.Client exactly. |
| Total Record Detection for API Queries, List Views and Report Exports | Access to more than 10,000 records. Salesforce's documentation says the threshold is not configurable at this time. | Activate the TSP - Process Record Access Event Flow and the TSP - Delete Record Access Records flow. Old log records are removed after two days. |
| Detect High Risk Data in Bulk API Result Downloads | Bulk API results that contain fields classified as high risk | Mark the right Data Sensitivity Levels as High-Risk and apply them to the fields you care about. |
| Detect Report Exports by Unapproved Profiles | Report exports by profiles that are not approved | Read the policy details for the approved profile list. |
| Detect Dormant User | Users with no successful login in the last 90 days. The documentation says new users with no login history are no longer flagged. | Read the policy details in your org for any extra setup. |
| Detect Logins from Countries on Blocked List | Logins from countries on a blocked list | Read the policy details for how the list is maintained. |
| Impossible Travel Detection | Logins from locations that cannot be reached in the time between them | Read the policy details in your org for its configuration. |
The documentation adds that all policies deploy as Inactive by default. You activate each one in Setup under Transaction Security Policies after testing, and you confirm that the Apex class or flow it references exists. If a deployment returns "Status 400: Bad Request," the guide says to check that the Named Credential user has the permissions needed to create policies.
The default report export policy from Salesforce
Separate from the Accelerator, Salesforce made a change to report exports in 2026 that interacts with your plan. Salesforce Help says a default ReportEvent policy is deployed as disabled for eligible Event Monitoring and Shield customers. When a UI report export exceeds 10,000 records, the policy triggers step-up authentication.
Help lists three scope notes. The default policy does not affect API-based exports, including Data Loader CLI. It currently applies only to internal users and not to Experience Cloud users. It stays editable and can be disabled. Help also says the default policy is not deployed if you already built a ReportEvent policy with Condition Builder, and that Salesforce does not auto-enable it if you edited it. The Accelerator's Total Record Detection policies also use a 10,000-record line, so decide which policy owns report exports before you stack them.
A rollout order that avoids lockouts
Salesforce's install guide says to test every policy in a non-production environment and warns that misconfigured logic or missing allowlists can disrupt service or lock users out. The order below is practitioner advice built on that warning. It turns on one policy at a time so that any problem has one obvious cause.
- Install the package in a sandbox, finish the authentication chain and assign the permissions to a small group of named admins.
- Read the built-in documentation for every policy you plan to use. Write the action (block, MFA or notification) next to each policy name in your change record.
- Pick one policy and complete its setup. For API access that means the allowlist, for high-risk data that means the classifications, and for record counts that means the two flows.
- Activate that one policy and no other.
- Test with a standard user, an admin, an integration user and any service account that runs scheduled work. Record what each one sees.
- Watch the results for a period you choose, then move the policy to production through your usual release route and repeat for the next one.
Your usual release route should have an owner and a rollback plan before the first policy reaches production. The checklist in the post on trusting an AI tool to change your org covers the questions to settle for any change that touches access.
Mistakes that lock users out
The Trailhead module lists design mistakes that apply directly to Accelerator policies. The table pairs each with a safer approach, and adds the classification gap from the install guide.
| Mistake | Safer approach |
|---|---|
| Blocking all report exports | Use a row threshold or specific report IDs. |
| Using a notification when you need prevention | Trailhead advises Block for prevention and notification for awareness. |
| Forgetting service accounts | Exclude specific user IDs or filter by user type. |
| Writing broad login conditions that block | Prefer multi-factor authentication over Block for logins. |
| Activating the high-risk data policy before classifying fields | Mark the Data Sensitivity Levels as High-Risk and apply them to the fields first, as the install guide requires. |
Where Cirra AI fits
The install and the activation happen in Salesforce, in the AppExchange and in Setup. Cirra AI helps with the preparation around them. Cirra AI is a hosted Salesforce Admin MCP Server. You authenticate a Salesforce org through OAuth, connect the AI client you already use, such as Claude, ChatGPT or Cursor, and describe what you need. Cirra AI works as the connected user, within that user's permissions. The Salesforce Admin MCP Server product page lists the capabilities, and Cirra AI supports Salesforce Enterprise Edition and up.
Two preparation questions suit a sandbox connection. The first is who holds the permission set that the package adds. The permission set management use case shows how an AI client answers access questions from live org data. A SOQL query like this one lists the assignments:
SELECT Assignee.Name, Assignee.Username, PermissionSet.Label FROM PermissionSetAssignment WHERE PermissionSet.Label = 'TSP Accelerator'
The second question is which active users the dormant-user policy might flag. This query approximates the 90-day rule the documentation describes, so you can see the list before you activate anything:
SELECT Name, Username, Profile.Name, LastLoginDate FROM User WHERE IsActive = true AND LastLoginDate < LAST_N_DAYS:90 ORDER BY LastLoginDate
Run both in a sandbox first and compare the results with the policy details in your own org, because the policy's own logic may differ from this approximation. Cirra AI also lets you set access per org across four data categories (Metadata, User Data, Personal Setup Data and Business Data), and each category can be None, Read Only or Read and Write. Actions are logged in an exportable audit trail, which gives your change record something to compare against.
The Free plan includes 100 credits, so you can try a sandbox connection before you decide anything. Ready to see it on a sandbox? Start Free Trial, or Learn More about the product.
Frequently asked questions
What is a Salesforce transaction security policy?
A transaction security policy is a rule that watches a real-time event in your org, such as a login, an API call or a report export. When the event meets the conditions you set, the policy blocks the action, requires multi-factor authentication or sends a notification.
What is the Transaction Security Policy Accelerator?
The Accelerator is a free Salesforce Labs app on the AppExchange that installs a library of prebuilt transaction security policies. Salesforce announced it on March 25, 2026, and groups the policies by security domain, such as data protection, access control, integration risk and data loss prevention.
Do I need Shield or Event Monitoring to use the Accelerator?
Yes, according to the install guide. It says Salesforce Event Monitoring or Shield must be licensed in the org, and that the install fails with an "ApexClass Invalid type" error without it. Salesforce Help also says transaction security requires a Shield or Event Monitoring add-on subscription.
Are the Accelerator policies active after install?
No. The install guide says all policies deploy as Inactive. You activate each one in Setup under Transaction Security Policies after you test it and finish any setup the policy needs.
How should I test the policies before production?
Install the package in a sandbox, activate one policy at a time and test with a standard user, an admin, an integration user and any service account. Salesforce's guide says to test every policy in a non-production environment because misconfigured logic or a missing allowlist can disrupt service or lock users out.
Can an AI client help me prepare for the Accelerator?
Yes, with preparation tasks such as listing who holds a permission set or finding users who have not logged in recently. Cirra AI connects an AI client such as Claude, ChatGPT or Cursor to your Salesforce org through OAuth and works as the connected user, within that user's permissions. Connect a sandbox first and review the results before you act on them in production.
