Identity

Your client clicked Allow. You are still holding their keys

Agencies think OAuth got them out of custody of client credentials. The 2025 and 2026 integrator breaches say otherwise. A custody checklist.

By Edwin Ashdown7 minute read

In this post 6 sections
  1. What agencies actually do
  2. What the breaches looked like
  3. Where the risk lands for you
  4. A custody checklist for each engagement
  5. Holding less
  6. Sources

If you build and run agents for clients, you have probably given a version of this answer when a client asked about security: we never touch your passwords, you sign in and click Allow, and you can revoke it whenever you like.

It is a good answer to the question about passwords. It doesn’t answer the question about custody. After the client clicks Allow, a refresh token sits in your n8n instance or your Make organisation or your own database, usable by your workflows and often by your staff, for as long as nobody revokes it. You are holding the client’s keys. You just never had to see them.

This post is general information for people who build agents for clients. It is no substitute for legal advice about your own contracts.

What agencies actually do

The community forums for the automation platforms agencies build on are full of this question, and the answers fall into three patterns.

In the first, the agency runs everything from one place. One agency owner on the Make forum described running “all client scenarios from one Make organization on a single paid plan”, because a separate organisation per client was “not affordable at my scale”. On self-hosted n8n, the documentation is plain that “instance owners and instance admins can view and share all credentials on an instance”.

The second is the OAuth answer, and it is the most common advice. One n8n community member put it this way: when the client authorises inside the tool, “you get a working connection, they keep ownership, and the liability question mostly goes away.”

The third is the one experienced practitioners recommend: build in a workspace the client owns and have them invite you as a member you can be removed from. “Client credentials would always remain in their hands when possible since that helps with offboarding and doesn’t let you become the indefinite custodian of sensitive access,” as another n8n member wrote last month. Its weaknesses are real. It costs more per client, handover gets fiddly, and as a Make user pointed out, “technically you will have access through Make anyway”.

The platforms are building for this. Make now has credential requests, made for “setting up automations for clients without asking them to share passwords”, though only for partners and enterprise customers. n8n has an end-user credentials feature in preview. Vendors build features like that when their customers keep tripping over the same problem.

What the breaches looked like

The integrator breaches I could verify from the last 18 months share a shape: a provider holding many customers’ OAuth tokens.

In August 2025, attackers used OAuth tokens belonging to the Salesloft Drift chatbot integration to export data from customers’ Salesforce instances between 8 and 18 August, then searched the data for more credentials. Google’s threat intelligence team wrote that the attacker’s primary intent was “to harvest credentials”. Cloudflare, one of the victims, found 104 of its own API tokens in support cases its customers had pasted them into. Containment meant Salesloft and Salesforce revoking every active Drift token at once.

Later that year Gainsight’s chief technology officer described a leaked set of 285 Salesforce OAuth tokens, about 250 of them still valid, issued as far back as October 2017. “A token issued in 2017 could theoretically still work in 2025,” he wrote. Tokens like these can “remain valid indefinitely unless explicitly revoked or rotated”. Gainsight now rotates them every few hours.

In June 2026, Klue disclosed that an attacker got in through “a compromised legacy credential associated with an integration service” and took the OAuth tokens Klue used to reach customers’ platforms. Klue then disabled its integrations with HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, Slack and Salesforce. That list is the reach of one integrator.

A related case: in April 2026, Vercel disclosed an incident that began with the compromise of Context.ai, a third-party AI tool one of its employees used. There, an AI tool’s access to a work account was the first hop.

None of these companies asked anyone for a password. Every one of them was holding grants that customers had clicked Allow on. An agency’s shared n8n instance or Make organisation is the same arrangement at a smaller scale.

Verizon’s 2026 Data Breach Investigations Report found a third party involved in 48 per cent of breaches, up 60 per cent on the year before.

Where the risk lands for you

I found no court or regulator decision holding an agency liable for a leaked client credential, so I won’t tell you that you will be sued. The risk shows up in two other places.

The first is your contracts, increasingly written by your client’s regulators. APRA’s CPS 230, in force since July 2025, requires a regulated entity’s agreement with a material service provider to cover ownership of assets, control of data, audit access, liability and indemnity, and termination. The critical infrastructure risk management rules require responsible entities to deal with “misuse of privileged access to the asset by any provider in the supply chain”. If your client is a bank, insurer, super fund or utility, those terms flow down to you.

The second is reputation. When Klue was breached, some of its customers published their own notices, Recorded Future among them. A client who learns about your breach from someone else’s incident notice is unlikely to renew.

One thing I expected to find and didn’t: cyber insurers asking agencies how they hold client credentials. The cyber insurance forms I checked ask about multi-factor authentication and vaulting your own privileged accounts. Questions about AI are starting to appear on professional indemnity forms, about whether a human checks actions and whether agent actions are logged.

A custody checklist for each engagement

You can run this on every current client this week. It needs no new product, and if you hold client access already you will learn something from it.

  1. Who owns the grant? Is the connection in an account the client owns, or in yours? Write it down per client.
  2. Where does the secret live? Name the instance, organisation or database that holds each refresh token or key, and who on your team can use it.
  3. What can each agent reach? One client connection used by five workflows carries the reach of all five. Narrow it where the platform lets you.
  4. Who can revoke, and how fast? The client should be able to cut you off without asking you. Test it once.
  5. What happens at handover? Agree that you revoke your access, hand over configuration and confirm in writing that you hold no remaining credentials. One published sample clause says exactly that. Zapier, for example, can keep a departing member’s connections live for 30 days or until they would normally expire, so check what your platform does.

And the contract topics worth raising with your lawyer: credential ownership in the client’s name, no reuse of credentials across clients, the scope of what agents may access and do, audit access to agent logs, incident notification, the subcontractors and platforms you rely on, revocation and termination, and the handover and exit steps above.

I’ve written before about why an agent shouldn’t hold your API keys at all, and the Hugging Face breach is a good illustration of what broad, long-lived access does once an agent is compromised.

Holding less

The shape that answers the checklist well is an agency that holds as little as possible. Each agent has its own identity, scoped to one client and only what that job needs. Credentials are short-lived. Risky actions wait for a person. Every action is recorded against the agent and the client, so either side can see what ran.

That is the arrangement I built AgentValet around, and the partners page explains how it works for agencies and integrators.

Sources

Filed under

  • credentials
  • agencies
  • oauth
  • integrators

Give your agent only the access it needs

Grant each agent a narrow set of actions, hold the risky ones for your approval, and keep a signed record of every call.

Protect my first agentWatch your agent’s calls live, no signup
All posts

Incidents

17,000 actions inside Hugging Face: reading an agent breach as a containment problem

An autonomous agent ran more than 17,000 actions inside Hugging Face, harvested stored credentials, and moved across internal clusters over a weekend. Here is the breach stage by stage, and what a governed agent layer changes at each one.

6 min read

Least agency

The 9 security review questions that keep agents out of production

Your agent works in staging and security keeps sending it back. Nine questions they ask, the weak answers, the strong ones, and the evidence to bring.

7 min read