TL;DR: A refresh token is a credential that does not expire, does not prompt, and does not look unusual in a log. When one is exfiltrated, the attacker gets persistent scriptable access to a SaaS application without tripping the controls built around logins. PainHunt's security cluster describes this as the access path that gets granted once and reviewed never — and the connectors that carry these tokens now sit between every system a company runs.
The evidence
PainHunt's security, cybersecurity and DevSecOps categories hold 6,879 high-scoring signals (10+/15), average score 11.4, average pain intensity 8.0/10 across 31,586 extracted pain points — the highest intensity average among the categories examined here. Sources are Mastodon (3,313), Medium (849), BlueSky (681), GitHub (535) and Dev.to (299), which skews toward practitioners writing for practitioners.
The integration-access cluster describes a consistent shape:
- Stolen tokens give persistent, scriptable access to SaaS applications without triggering standard alerts.
- Refresh tokens are long-lived and reusable indefinitely, so a single exfiltration becomes an undetected backdoor rather than a session.
- Service accounts with elevated privileges are single points of failure. They exist to avoid per-user friction, which means they carry more rights than any individual and less scrutiny.
- Vendor connectors create trusted relationships attackers move through. Compromise the connector, reach every system it was granted access to.
The pattern is not theoretical. The breach shape of the last two years has repeatedly been: compromise one integration vendor, harvest its stored customer tokens, use them against hundreds of downstream tenants. Each downstream victim sees legitimate-looking API traffic from a vendor they authorised.
Why now
Integration count grew faster than review capacity. A mid-size company runs dozens of SaaS products, most connected to several others. Every connection is a standing grant. Nobody's quarterly review covers them because they were never modelled as accounts.
AI agents multiplied the grants. Every assistant, copilot and agent that "connects to your tools" is another OAuth grant with broad scopes, often approved by an individual employee in seconds. The adjacent PainHunt cluster on AI agent permissions and audit logs covers the governance side of the same expansion.
The attacker economics changed. Compromising one integration vendor to reach hundreds of tenants is a far better trade than phishing tenants individually. That makes the connector layer a deliberate target rather than incidental collateral.
The wedge
The narrow, buildable thing is an inventory and behavioural baseline for non-human access, not another identity platform.
- Enumerate every grant, everywhere. One list: which application holds a token in which SaaS product, with what scopes, granted by whom, when, and last used. Most organisations cannot produce this list today, and producing it is by itself worth the first invoice.
- Flag the ones that stopped mattering. Tokens unused for ninety days, tokens granted by people who have left, tokens for applications no longer in the vendor register. Standing access with no current business justification is the cheapest risk to remove and the easiest to get approved.
- Baseline the behaviour, alert on the deviation. Every integration has a characteristic call pattern — endpoints, volume, hours, regions. Attackers using a stolen token do different things with it: enumerate, bulk-read, export. Deviation from an integration's own history is the detectable signal, and it is detectable without seeing the token.
- Make revocation one action. Discovery is only half the product. Being able to kill a grant across every tenant from one place is what turns a report into an incident response tool, and it is what a buyer will remember during an actual incident.
Risks and honest caveats
This is the SSPM market and it has funded incumbents. Several vendors already sell SaaS security posture management with integration inventory in the box. Entering means being materially better at one thing rather than broader — the behavioural baseline for non-human identities is the defensible slice; the inventory alone is table stakes.
API coverage is the whole product and it is per-vendor work. Every SaaS product exposes grant data differently, some barely at all. Coverage determines value and it grows linearly with engineering effort, with no shortcut. Realistically a startup ships depth on ten products, and the buyer wants forty.
A security tool that reads every integration becomes a target. The product must hold high-privilege access to a customer's entire SaaS estate — the same concentration of trust that makes the attack it defends against worth doing. That is a hard architectural constraint and a harder sales conversation.
The buyer is slow and the budget is contested. Security tooling purchases run through review cycles measured in quarters. This is a poor fit for a founder who needs revenue this quarter, and a reasonable fit for one who can survive a long enterprise cycle.
Where this came from
This is one cluster inside PainHunt's security categories. The Pain Point Browser shows the underlying signals with their intensity and commercial scoring, and the Idea Validator will score a specific version of this idea against the same dataset. Two adjacent clusters cover the same trust boundary from other sides: SSRF protection for MCP servers, which is what happens when the agent itself is the untrusted caller, and responding to CVEs in self-hosted software.