Platform
Real-Time Event Monitoring and Transaction Security: catching the data leaving before it's gone
The 2025 OAuth-token breaches didn't exploit a Salesforce bug. They logged in with valid tokens and ran SOQL until they found AWS keys. Event Monitoring is how you'd have seen it, and Transaction Security is how you'd have stopped it. Here's the event model, the storage, and the policies that matter.
The attackers who pulled roughly 1.5 billion records out of around 760 Salesforce orgs in August 2025 did not break Salesforce. They logged in with OAuth tokens stolen from a third-party integration, ran SOQL and Bulk API queries, and sifted the results for AWS keys and passwords. To Salesforce, every request was a valid, authenticated API call. The only place the story shows up as wrong is the event log.
That’s the case for Event Monitoring, and most orgs that own it have never turned the useful half on. If you have Salesforce Shield or the Event Monitoring add-on, you already have a detailed record of who queried what, who exported which report, and who downloaded which file.
Real-Time Event Monitoring streams those events as they happen and lets you store and query them. Transaction Security Policies let you act on them in the moment: block the export, end the session, require MFA.
My opinion, stated plainly: if you run agents or integrations against production data, Real-Time Event Monitoring is not a nice-to-have, it’s the smoke detector. Here’s the event model, where the data lives, and the three policies I’d stand up first.
Two different things both called “Event Monitoring”
The name covers two mechanisms that behave nothing alike, and picking the wrong one is why teams conclude Event Monitoring is slow or useless.
Event Log Files (ELF) are the batch half. Salesforce generates a log file per event type, delivered hourly or daily, that you pull through the API and load into a warehouse or a monitoring tool. ELF is cheap, comprehensive, and retrospective. It’s great for a weekly review and useless for stopping anything, because by the time the file lands the export already happened.
Real-Time Event Monitoring (RTEM) is the streaming half. Events publish as platform events the moment they occur, and you can subscribe to them, store them in Salesforce objects, and query them with SOQL. This is the half that catches an exfiltration in progress, and the half that Transaction Security Policies hook into. When this post says Event Monitoring, it means RTEM.
Both need the Shield bundle or the standalone Event Monitoring add-on. Shield also gives you Platform Encryption and Field Audit Trail; if you bought Shield for encryption and never configured the monitoring, you’re paying for a tool you left in the box.
The events that matter, and where they’re stored
RTEM covers a long list of event types. For detecting data theft and watching what an agent or integration does, a handful carry most of the signal:
ApiEventrecords each API query, including the SOQL text and the rows returned. This is the one that would have shown the breach: unusual queries against Case, pulling volumes no normal integration pulls.ReportEventand the large-export signal record who ran and exported which report. The default Transaction Security Policy already watches large report exports.BulkApiResultEventStorerecords Bulk API result downloads, the fast path for pulling millions of rows.ListViewEventrecords list-view access and export, a quieter way to scrape a table.LoginEventrecords logins with the flow, the IP, and the app, so a new integration or an odd geography stands out.FileEvent(via the file-download signal) records who downloaded which ContentDocument.
Storage splits in a way that trips people up. Most of these store into big objects (ApiEventStore, LoginEventStore, and the rest), and a big object supports SOQL on only two indexed fields: EventDate and EventIdentifier. You query by date range, not by UserId in a WHERE clause, so for anything richer you stream the events out to a SIEM or filter in a tool.
Retained data lives for 6 months, or up to 10 years with the Shield or Event Monitoring subscription.
The Threat Detection events are the exception and the best-kept secret in the bundle. Salesforce runs machine-learning detectors that emit five standard-object events, and because they’re standard objects you can run SOQL on every field:
CredentialStuffingEventStoreflags successful logins during a detected credential-stuffing run.ReportAnomalyEventStoreflags a report pull that doesn’t match the user’s history.ApiAnomalyEventStoreflags API usage that deviates from the baseline, the exact shape of a token suddenly pulling ten times its normal volume.SessionHijackingEventStoreflags a session whose fingerprint changed mid-stream.GuestUserAnomalyEventStoreflags odd behavior from an unauthenticated guest user.
Threat Detection storage is kept for up to 6 months. These five are where I’d start a review, because Salesforce already did the anomaly math. An ApiAnomalyEvent on an integration user is the alarm the 2025 victims needed.
Logging tells you what happened. Threat Detection tells you what was abnormal. The second one is the difference between a forensic reconstruction after the records are gone and a page while the query is still running.
Transaction Security: acting in the moment, not reading about it later
Detection without a response is a slower incident. Transaction Security Policies (TSPs) are the enforcement layer: a policy intercepts a real-time event and runs an action before, or as, the event completes.
The actions available are Block, Notify, Require Multi-Factor Authentication, and End Session. Which ones a given event supports depends on whether the event has a UI login context:
ApiEventsupports Block and Notify. It can’t prompt for MFA, because there’s no browser to prompt.ReportEventandLoginEventsupport Block, Notify, and MFA, because a person is usually at a screen.ReportAnomalyEventStoreand the other anomaly events support Notify, so you get the alert even where blocking would be too blunt.
Salesforce ships a default TSP that watches large report exports and enforces MFA, which is a sensible freebie but nowhere near enough. The three I’d build first:
- Block or alert on anomalous API usage. Point a policy at the API anomaly signal, scope it to your integration and agent users, and route it to your security channel. This is the one aimed squarely at a stolen token pulling volume.
- Gate large and anomalous report exports. Extend the default beyond its threshold to block exports above a row count that no legitimate user hits, and alert on
ReportAnomalyEventfor everyone else. - Flag logins that don’t fit. A
LoginEventpolicy that notifies on a new connected app, a new country, or the retiring username-password flow catches a bad integration the day it appears, not the quarter you next audit.
A word of caution the docs give for a reason: an Apex-based TSP that errors at runtime can lock users out. Build policies in a sandbox, run them in monitor-only (Notify) mode first, and watch what they’d have blocked before you let them block. A policy that stops a quarterly finance export because you set the threshold too low burns the trust you need to keep the tool switched on.
Why this matters more now than a year ago
Two things changed the calculus. First, the breach pattern. The Salesloft/Drift and Gainsight token thefts, mapped by Microsoft and others as a year of OAuth-centric supply-chain abuse, all share a signature: valid credentials, API-driven extraction, and in several cases the attackers deleting their query jobs to slow the investigation.
None of it trips a login alert, because the login was legitimate. All of it shows up in ApiEvent and the anomaly events. Salesforce’s own August 2026 forensic-reconstruction guidance leans on exactly these logs, and tells admins to enable Event Monitoring for visibility into API calls, report exports, and file downloads.
Second, agents. An Agentforce agent runs as a user and queries your data through the same API surface an attacker would. Governing an agent fleet means knowing what each agent user read, and Event Monitoring is the only record that answers it.
The Einstein Trust Layer masks and audits prompts, but it does not log the SOQL an action ran. RTEM does. If you’re pointing agents at production, the agent user is a new identity on your API, and you want it on the same monitor as every integration.
This sits alongside the other two controls I’d put in place this quarter. Retiring the username-password OAuth flow closes the weakest door; connected-app token governance shrinks what a stolen token can reach; Event Monitoring is how you see the one that still gets through. A Health Check score tells you none of this, because it never looks at who did what.
Where to start if you own Shield and haven’t used it
Turn on the storage for ApiEvent, LoginEvent, and the report-export events, and let the Threat Detection events accumulate for a week. Then read them. You will almost certainly find an integration pulling more than you expected, a report export you can’t explain, or a connected app nobody remembers installing. That first read is the point: you cannot write a sensible blocking policy until you know what normal looks like in your org.
Then stand up the three policies above in Notify mode, watch for a fortnight, and only promote the API-anomaly one to Block once you’ve confirmed it won’t catch your nightly ETL. The goal isn’t a wall of alerts. It’s one page, to the right person, the moment a token starts doing something a token has never done before.
Understanding the basics
What’s the difference between Event Log Files and Real-Time Event Monitoring?
Event Log Files are batch logs delivered hourly or daily that you pull and analyze after the fact. Real-Time Event Monitoring streams events as they happen, stores them in Salesforce objects you can query, and lets Transaction Security Policies act on them in the moment. Only the real-time half can block something while it’s happening.
Do I need Salesforce Shield for Event Monitoring?
Yes. Real-Time Event Monitoring and Transaction Security require either the Salesforce Shield bundle or the standalone Event Monitoring add-on. Shield also includes Platform Encryption and Field Audit Trail. Standard orgs without one of these don’t have real-time events or storage.
What can a Transaction Security Policy do?
Depending on the event, a policy can Block the action, send a Notification, require Multi-Factor Authentication, or End the session. API-based events like ApiEvent support Block and Notify but not MFA, because there’s no browser to prompt. Report and Login events support all four.
How long is event data kept?
Stored real-time event data is retained for 6 months, or up to 10 years with a Shield or Event Monitoring subscription. Threat Detection storage events are kept for up to 6 months. Big-object event stores are queryable by EventDate and EventIdentifier only, so richer analysis usually happens in a SIEM.
Would Event Monitoring have caught the 2025 OAuth-token breaches?
The logins were valid, so a login alert wouldn’t have fired, but the extraction would have shown up as anomalous API and Bulk API activity on the compromised integration users. The ApiAnomalyEvent detector exists for exactly that pattern, which is why Salesforce’s forensic guidance tells orgs to enable Event Monitoring.
If you own Shield and have never turned the monitoring on, we’ll help you light it up, read the first week of events, and stand up policies that alert the right people without locking out your own finance team. Talk to us.
