In Part 1 of our conversation, we explored why SaaS API logging is a mess—why logs are incomplete, misleading, or locked behind paywalls—and how security teams are struggling to investigate SaaS-related incidents.
Now, in part 2 of our conversation, Adam Burt, Head of Research at Vorlon, shares insights on “intent-based” logging failures, API key exploitation, third-party integrations, and where SaaS security is heading next.
If you rely on SaaS for critical business functions (spoiler: you do), this is a conversation you won’t want to miss.
Let’s get into it.
Elias Terman: Adam, in Part 1, you mentioned that even when SaaS platforms provide logs, they’re often misleading. One reason is “intent-based” logging. Can you explain what that is and why it’s a problem?
Adam Burt: Intent-based logging is when a SaaS vendor only logs what happened—but not how it happened and is sometimes limited to modification events.
For example, let’s say someone makes a change in a SaaS application. Instead of logging the API call that was used, it might simply log the intent: “User updated an account.”
Sounds fine, right? The problem is that intent-based logging often ignores read operations. If an attacker quietly extracts 10,000 customer records via API, and the platform only logs changes, there’s no record of the breach.
Some SaaS platforms still don’t log read operations at all. That’s a security nightmare because most data theft doesn’t require making a change. Attackers just exfiltrate information.
Vorlon helps security teams detect these gaps by monitoring API activity at a deeper level, even when SaaS logs aren’t telling the full story.
Elias: That’s terrifying. So if an attacker exfiltrates data without modifying anything, most security teams wouldn’t even know?
Adam: Exactly. And that’s just one way SaaS logs fail security teams.
Another issue is API key abuse. Many security tools focus on user authentication, like tracking logins and enforcing MFA. But what happens when an API key is stolen? The answer: Nothing. API keys don’t require MFA. They often don’t expire unless rotated. And they’re often hardcoded into scripts, CI/CD pipelines, and integrations; meaning they get copied, shared, and forgotten about.
If an attacker steals an API key, they don’t need to log in. They can access data directly through APIs. And if SaaS logs don’t properly attribute API activity, security teams may have no idea an API key has been compromised.
Elias: What can security teams do to protect against API key theft?
Adam: First, visibility is key. Security teams need to know which API keys exist, what data they have access to, and whether they’re actually being used.
Vorlon continuously monitors API key usage and can detect when a key is used in an unusual way; like from a new location, outside business hours, or to access data it’s never touched before. Second, security teams need to enforce expiration policies. Unlike passwords, API keys don’t automatically expire, which is why many organizations have API keys floating around that haven’t been used in years. If you don’t need an API key anymore, revoke it.
Elias: What about third-party integrations? Are they creating security blind spots?
Adam: Absolutely. Most enterprises integrate dozens—if not hundreds—of third-party apps into their core SaaS platforms like Salesforce, Workday, and Microsoft 365.
These integrations are incredibly powerful, but they’re also a security black hole. Security teams rarely monitor what third-party apps are doing via API, and SaaS platforms often don’t make this easy.
For example, let’s say a company connects a marketing automation tool to Salesforce. That tool has access to customer records, deal information, and contact lists. But, how often does security actually review what data is being shared and whether that access is still needed?
Vorlon helps security teams map out these third-party connections and identify high-risk integrations. We’ve seen situations where an integration set up years ago still has API access to sensitive data—even though it’s no longer being used.
Elias: How do you see SaaS security evolving in the next few years?
Adam: We’re at an inflection point. Companies are finally realizing that SaaS security is more than just managing configurations. It requires monitoring how misconfigurations, API activity, non-human identities, and data flows interact.
Here’s where I think we’re headed:
- SaaS security will become a core part of detection and response – Security teams are going to demand real-time visibility into SaaS API activity, just like they do for endpoints and networks today.
- More SaaS vendors will be forced to improve logging – Right now, many SaaS platforms treat security logging as an afterthought. Vendors will have to improve as customers demand better auditing capabilities and transparency.
- Machine-to-machine activity will get more scrutiny – Today, security teams focus heavily on human logins. In the future, they’ll need to apply the same level of scrutiny to API keys, OAuth tokens, and third-party integrations.
Vorlon is ahead of the curve on all of these trends. We’re already helping security teams monitor their SaaS ecosystem in near real time, detect unusual machine-to-machine activity, and close SaaS security blind spots before they become breaches.
Elias: Final thoughts? What should security teams take away from this conversation?
Adam: If your security tools aren’t monitoring SaaS API activity, you’re missing most of the attack surface.
Bringing detection and response to the SaaS ecosystem
After this conversation with Adam, a few things are clear. Most SaaS vendors do not provide the logs security teams actually need. Intent-based logging hides critical details, API key exploitation goes unnoticed, and third-party integrations create security gaps that attackers take advantage of.
Traditional security tools were not built for this problem. SIEMs, EDRs, and other legacy solutions struggle to piece together what is happening in a SaaS ecosystem. This leaves security teams stuck in reactive mode.
Security teams need better visibility, not just more logs. They need to see how data flows between applications, track non-human identities, and detect anomalies before they turn into breaches. That is where Vorlon's SaaS Ecosystem Security Platform comes in.
In Part 3, we will explore why posture management is not enough, how security teams can move beyond detection into real-time response, and what the future of SaaS security looks like. Stay tuned!
Learn more about Vorlon's SaaS ecosystem security platform:
About Adam Burt
Adam Burt
Head of Research at Vorlon
Adam Burt is the Head of Research at Vorlon, bringing over 24 years of experience in cybersecurity across malware analysis, digital forensics, reverse engineering, programming, and security architecture. Before joining Vorlon, he led a team of Solution Architects at Palo Alto Networks, focusing on security and automation.
Throughout his career, Adam has held technical and leadership roles at companies like Symantec, Fidelis Cybersecurity, and NTT, working across industries to help organizations strengthen their security posture. He holds multiple certifications, including CISSP, GCFE, CSTP, and CCSK, and has contributed to research on network vulnerabilities, malware obfuscation, and threat detection.
At Vorlon, Adam leads research into SaaS ecosystem security, focusing on API-based threats, identity risks, and improving security visibility. He lives in South Central UK with his wife and two children.
About the author
Elias Terman
VP of Marketing at Vorlon