Adobe Took Rilo's Team. Its Slack Token Never Expires.

Adobe licensed Rilo's technology and hired its six-person team; Rilo shuts down. But Rilo was a free-tier agent platform wired into 100+ systems, and the OAuth grants it holds in your Slack, Salesforce and Gmail outlive the company that issued them.

By Rajesh Beri·September 2, 2026·13 min read
Share:
A single unplugged office wall socket with a live power cable still running from it into a dark, empty startup office — cardboard boxes packed, chairs stacked, one monitor still glowing.

Illustration generated using AI

Adobe did not buy Rilo. It licensed the technology, hired the six people, and left the company to shut down. What nobody in that transaction did — not Adobe, not Rilo, not the investors — is revoke the OAuth grants Rilo already holds inside your Slack workspace, your Salesforce org and your Gmail. Those grants live on your side of the connection. They do not expire because the vendor did. And nobody will send you a termination notice, because on a free tier with no credit card, you were never a customer of record.


What Adobe Actually Took, and What It Left in Your Tenant

Adobe took a team and a licence. It did not take the connections Rilo had already opened into customer systems, and there is no evidence anyone has closed them.

TechCrunch reported on 2 September 2026 that Adobe acquired Rilo in a licensing-and-team deal, with terms undisclosed. Rilo's six-member team joins Adobe. The company was founded in 2025 by IIT batchmates Georgi Boby and Dhruv Jaglan, and had raised $1 million at a $10 million valuation from PeakXV, DeVC and Day Zero Ventures. Adobe declined to comment beyond confirming the deal. The line that matters to you is this one: post-acquisition, "Rilo will shut down and won't be available to its customers."

Now go and look at what Rilo was. Its own site still describes an AI agent platform that automates go-to-market workflows — competitor monitoring, prospect-signal detection, investor tracking, multi-platform content distribution — wired into more than 100 integrations. The named ones include Slack, Salesforce, HubSpot, Gmail, Notion, LinkedIn, Reddit, Apollo, Instantly and Zapier. As of publication the site is still selling: "Your first workflow is free," "No credit card. No commitment. Just outcomes," "Your first output arrives in 15 minutes." There is no wind-down notice on the page.

That combination is the whole story. An agent platform reaches across systems by design — it cannot summarise your competitor's Slack chatter or enrich your HubSpot pipeline without read access to both. To get that access it asked a user to click through an OAuth consent screen. The user clicked. The grant was recorded in your tenant, and the resulting refresh token was written to a database owned by a company that is now being dissolved.


Your Grant Does Not Expire Because the Company Did

On the platforms Rilo connected to most, the default token lifetime is effectively forever, and the only party who can end it is you.

An OAuth refresh token is a long-lived credential the vendor stores on its own servers and exchanges for a fresh access token whenever it wants back into your system. It is not a password you can rotate. It is a standing grant that only the resource owner can withdraw.

Platform Default token lifetime Who has to act
Slack Never expires unless the app opted into rotation Workspace owner or admin
Salesforce Valid until revoked Salesforce admin or the user
Google Workspace Dies after six months of non-use Admin, or the individual user
Microsoft Entra Until the grant is deleted Admin — Graph for user-consent grants

Slack is the starkest. Slack's own developer documentation states plainly that "Without token rotation, the access token never expires," and rotation is opt-in — an app has to actively enable it. A startup shipping fast on a free tier had no reason to.

Salesforce is the same by default. Salesforce's connected-app documentation lists "Refresh token is valid until revoked—Default. The refresh token is used indefinitely, unless revoked by the user or Salesforce admin." Unless someone on your side changed that policy, the grant persists.

Google is the only one of the three that cleans up after you, and it is slow about it. Google's OAuth 2.0 documentation lists the conditions under which a refresh token stops working, and the relevant one here is that "the refresh token has not been used for six months." So if Rilo's infrastructure goes dark tomorrow and stops calling Gmail, that grant self-expires around March 2027. If the infrastructure keeps running — a scheduled workflow nobody switched off, a container still polling — it never does.


Salesloft Drift Needed Three Companies to Pull the Plug

The last time third-party OAuth tokens at an AI vendor went bad at scale, revocation required the vendor, Salesforce and Google acting in concert. Rilo will have none of them.

Google Threat Intelligence documented that beginning as early as 8 August 2025 and running through at least 18 August, the actor tracked as UNC6395 used compromised OAuth tokens associated with the Salesloft Drift application to systematically export large volumes of data from numerous corporate Salesforce instances. The queries targeted Cases, Accounts, Users and Opportunities, and the actor then combed the exports for AWS access key identifiers, Snowflake tokens, passwords and other secrets. Google's assessment was blunt: the primary intent was to harvest credentials for follow-on compromise.

Look at what remediation actually required. On 20 August, "Salesloft, in collaboration with Salesforce, revoked all active access and refresh tokens with the Drift application." Salesforce removed Drift from the AppExchange. Then on 28 August, Google separately identified affected users, revoked the OAuth tokens granted to the Drift Email application, and disabled the Workspace integration. Three organisations, three separate revocation actions, over eight days — and Salesloft was a live, funded, staffed company with an incident response function. We covered the same structural failure in the Klue OAuth breach that reached 195 companies.

Steel-manning this properly: there is no evidence Rilo has been breached, and nothing suggests its founders are careless. Two IIT graduates who built a workflow engine good enough for Adobe to license are not the villains here. The point is narrower and worse. Drift's tokens got revoked because a company existed to revoke them. When the company is being wound down and its customers were never customers of record, that control path does not exist. The only actor left in the system who can end the grant is the tenant it points at.


The Free Tier Is Why Procurement Will Never Find It

Rilo's entry point was a workflow that cost nothing and took a browser, which means there is no invoice, no MSA, no DPA and no change-of-control clause to fire.

This is what makes the deal different from the acqui-hires we have already covered this quarter. When Klaviyo bought Agency and set a wind-down date of 31 August, the product was paid, so there was a customer list and an export clock. When OpenAI absorbed NextSlide, the problem was that buyers learned five months late — but they did eventually learn, because they were on a contract. When Nvidia licensed Poolside's model factory and hired 109 engineers, the complaint was that no change-of-control clause fired against an enterprise agreement that did at least exist.

Every one of those stories assumes a contract. This one does not. Your vendor inventory is keyed on spend. A tool that never generated a line item is invisible to it, and dissolution of the entity behind that tool generates no notice, no deletion obligation and no counterparty to serve.

The scale of that blind spot has been measured, though not disinterestedly. The Cloud Security Alliance's State of SaaS Security report for 2025-2026, commissioned by the SaaS security vendor Valence Security, surveyed 420 IT and security respondents in January 2025 and found 46% of organisations struggle to monitor non-human identities, with 56% saying third-party vendors and GenAI tools hold overprivileged API access to sensitive data. The same research found 55% report employees signing up for SaaS applications without security's involvement. Take those for what they are — self-reported perceptions, in a survey paid for by a company selling the remedy — and they are still the only public measure of a gap nobody else is counting.

And when something does need revoking, most teams are slow. A CSA survey of 383 respondents commissioned by Oasis Security — again, a vendor in this category — run in August and September 2025 and published in January 2026, found 79% of organisations rated their confidence in preventing attacks via non-human identities as low or moderate, 78% have no documented, formally adopted policy for creating or removing AI identities, and nearly a quarter — 24% — take more than 24 hours to rotate or revoke a credential after a potential exposure. This is the same machine-identity governance gap we wrote about when machine identities passed humans 109 to 1.


Revoking It Is Five Jobs in Five Consoles, With Two Traps

There is no single button. Each platform files the grant somewhere different, and two of the five will let you think you have revoked something you have not.

Google Workspace. Go to Menu > Security > Access and data control > API controls, then Manage App Access. The list shows each app's name, OAuth client ID, verification status and the number of users who granted it, and exports to CSV. Setting an app to Blocked, or moving a service to Restricted, does revoke tokens: Google's admin documentation states that "If you change access to Restricted, any previously installed apps that you haven't trusted stop working and tokens are revoked." Note the reporting lag — "the accessed apps list is updated 48 hours after a token is granted or revoked" — so verify twice, two days apart. Also note the default: unless an admin changed it, users may access any third-party app.

Microsoft Entra — trap one. Enterprise apps > All applications > pick the app > Permissions gives you an Admin consent tab and a User consent tab. Microsoft's documentation is explicit that "You can't revoke permissions in the User consent tab using the portal." A self-serve free tier is, almost by definition, user consent — so the grants most likely to be Rilo's are exactly the ones the admin centre cannot remove. You need Microsoft Graph (GET /servicePrincipals/{id}/oauth2PermissionGrants, then DELETE /oAuth2PermissionGrants/{id}) or the equivalent PowerShell. Revoking also does not stop a user re-consenting later; that needs a consent policy change. We walked through the same portal-versus-Graph gap in the Copilot memory persistence case.

Slack — trap two. From the desktop app, Admin > Apps and workflows > App Management Settings. You can mark an app Restricted, and it feels like remediation. Slack's help documentation says otherwise: "If an app you restrict has already been installed to your workspace, members can continue using it." Restricting blocks future installs. Uninstalling is the action that ends access.

Salesforce. Revoke from the Connected Apps OAuth Usage page in Setup, or from the individual user's detail page under OAuth Connected Apps. Both are named in the connected-app documentation cited above.

HubSpot and Notion. In HubSpot, the settings icon, then Integrations > Connected Apps; open the app and disconnect it. In Notion, Settings > Connections > Manage, where an Enterprise workspace owner can see every member who installed a connection and disconnect it.

One thing revocation does not do. Google's own guidance to users spells out the limit: once you revoke a linked app's access "they can't access your data anymore. You may need to contact the developer of the app to request that they delete the data they already have." Note who you are being told to contact. Whatever Rilo already pulled into its own storage stays there, in the infrastructure of a company that is shutting down. Revocation caps the future. It does not undo the past, and no free-tier signup gave you a deletion right to enforce.


Do This Before the Lights Go Out

This Week:

  1. Search for the grant, not the vendor. Pull the third-party app list from Google Workspace API controls, Entra enterprise applications, Slack app management, Salesforce OAuth Connected Apps Usage, HubSpot Connected Apps and Notion Connections. Grep each for "Rilo" and for getrilo.ai in redirect URIs and publisher domains. Do not ask procurement — procurement has never heard of it.
  2. Revoke where you find it, and use the right mechanism per platform: Blocked in Google, Graph DELETE in Entra for user-consent grants, uninstall (not restrict) in Slack, revoke in Salesforce, disconnect in HubSpot and Notion.
  3. Ask the one question that finds the rest: which employee clicked consent, and what else did they connect the same month? An agent tool is rarely the only one.

This Month:

  1. Run the same sweep for every AI tool with a free tier that anyone in go-to-market or engineering has touched this year. Sort the resulting app inventory by scope breadth, not by vendor size — a six-person startup with chat:read across your whole Slack is a larger exposure than a public company with a calendar scope. Discovery tooling helps here; SaaS security posture platforms and agent-identity products both enumerate OAuth grants, and we compared the governance layer in Okta vs Entra Agent ID vs SailPoint.
  2. Turn off the default that made this possible. In Google Workspace, move from "users can access any third-party app" to an allowlist. In Entra, restrict user consent to verified publishers and low-impact scopes. Both changes are reversible and both take an afternoon.
  3. Add a monthly diff of the OAuth app list to whoever runs identity. New grant, new row, someone reads it. That is the entire control.

Before Your Next Renewal Cycle:

  1. Change what "vendor inventory" means. If the list is generated from the general ledger, it structurally cannot contain a free tool, and free is now the default distribution model for AI startups. Generate it from OAuth grants and IdP sign-ins instead, and reconcile spend against that — not the other way round.
  2. Write a dissolution clause into the tooling policy, not just the contract template: any external application holding a scope above read-only on a system of record gets an annual re-consent, so an abandoned grant dies on its own within twelve months.

The Bottom Line

Every acqui-hire story of the past two years has been argued in contract terms — who gets notice, whose clause fires, how long the export window runs. That framing has quietly stopped working. The AI tools reaching deepest into enterprise systems now arrive through a consent screen rather than a purchase order, which means the artifact that survives the vendor is not a contract at all. It is a token, sitting in your tenant, pointed at a company that no longer exists.

Adobe got the team and the technology. The investors got their outcome. Rilo's founders got a landing at a large company inside two years. Everyone in the transaction is finished, and the only unfinished business belongs to people who were never party to it.

The deal closed. Your grant did not.

Continue Reading

Share:

Frequently Asked Questions

Did Adobe acquire Rilo outright?

No. TechCrunch reported on 2 September 2026 that Adobe acquired Rilo in a licensing-and-team deal with undisclosed terms. Rilo's six-member team joins Adobe, and post-acquisition Rilo will shut down and won't be available to its customers. Adobe declined to comment beyond confirming the deal.

What happens to a third-party OAuth grant when the vendor shuts down?

Nothing automatic. The grant is recorded in your tenant, not the vendor's, so only you can withdraw it. Slack access tokens never expire unless the app opted into token rotation, and Salesforce's default connected-app policy is 'refresh token is valid until revoked'. Google Workspace is the exception: a refresh token stops working after six months of non-use.

Where do I find Rilo's OAuth grants in my SaaS estate?

Google Workspace: Menu > Security > Access and data control > API controls > Manage App Access. Microsoft Entra: Enterprise apps > All applications > Permissions. Slack: Admin > Apps and workflows > App Management Settings. Salesforce: the Connected Apps OAuth Usage page in Setup. HubSpot: Integrations > Connected Apps. Notion: Settings > Connections > Manage.

Why can't I revoke some OAuth permissions from the Entra admin portal?

Microsoft's documentation states you can't revoke permissions in the User consent tab using the portal. Self-serve free-tier tools are almost always granted by user consent rather than admin consent, so those grants must be deleted through Microsoft Graph or PowerShell — GET the service principal's oauth2PermissionGrants, then DELETE each grant by ID.

Does restricting an app in Slack revoke its access?

No. Slack's help documentation says that if an app you restrict has already been installed to your workspace, members can continue using it. Restricting only blocks future installs and requests. To end an existing app's access you have to uninstall it.

Does revoking a grant delete the data the vendor already collected?

No. Google's guidance on removing third-party access states that once you revoke a linked app's access it can't access your data anymore, but that you may need to contact the developer of the app to request that they delete the data they already have. Whatever the vendor already pulled into its own storage stays there, and a free-tier signup with no DPA gives you no contractual deletion right to enforce — nor, once the vendor dissolves, a developer left to ask.

Newsletter

Stay Ahead of the Curve

Weekly enterprise AI insights for technology leaders. No spam, no vendor pitches—unsubscribe anytime.

Subscribe

Latest Articles

View All →