The finding usually turns up in an access review. A connected app called something like "AI Sales Assistant" can send mail as forty employees. The support vendor's bot has an integration user with write access to every case and contact in the CRM. A contractor's coding agent opens pull requests overnight on a repository token that belongs to the contractor. Each was approved, as an integration, by whoever owned the system at the time. None was reviewed as what it is: a third party's decision-maker holding your credentials.
Reviewing a SaaS product's AI features asks what the vendor does with your data in its own service. This is the other question: what the vendor's agent can do in yours, and how you stop it. The access review above is what happens when only the first question gets asked. Treat each vendor agent as a privileged identity you issue and can withdraw, and make the decisions below in this order, because each one depends on the last.
First, assume the vendor's tokens will one day act as the vendor
The clearest recent case did not involve a model at all, which is the point. Google's Threat Intelligence Group reported that from as early as August 8 to at least August 18, 2025, an actor it tracks as UNC6395 used compromised OAuth tokens for the Salesloft Drift third-party application to reach Salesforce customer instances, and systematically exported large volumes of data from objects such as cases, accounts, users and opportunities [1]. The actor searched the stolen data for secrets, including AWS access keys, passwords and Snowflake tokens, and deleted query jobs to hide its activity, although the logs were not affected [1].
Google said the issue did not stem from a vulnerability in the core Salesforce platform [1]. Salesloft and Salesforce revoked Drift's active access and refresh tokens on August 20; an August 28 update extended the scope to Drift's email integration, whose tokens had been used to read email from a very small number of Google Workspace accounts [1]. The guidance: treat every token stored in or connected to the platform as potentially compromised, restrict connected-app scopes, and enforce IP restrictions [1].
A vendor agent is the same long-lived token with a decision-maker attached. Unlike an integration that syncs fixed fields, it decides at runtime, guided by the vendor's model, the vendor's prompts and content written by your customers and prospects, and its behavior can change with a vendor release you never saw. OWASP's Excessive Agency entry describes the resulting risk as damaging actions taken in response to unexpected, ambiguous or manipulated model output, rooted in excessive functionality, permissions and autonomy [5]. For a vendor agent you set all three when you click grant, usually by accepting whatever the install flow asked for.
Decision 1: which identity does the agent act as?
Its own: a dedicated integration user, service account or OAuth client, never an employee's. RFC 8693 distinguishes delegation, where the acting party keeps its own identity, from impersonation, where it becomes indistinguishable from the user [4]. Prefer delegation, so every record shows that the agent acted and on whose behalf. Approve the vendor once, then give each of its agents a separate identity and connection, because the connection is where the authority lives.
Decision 2: what may it do, and what has to ask?
Content from customers can steer the vendor's agent, so the agent reaches your systems only through its own identity with narrow, expiring scopes. Reads and field updates are granted, sending email asks or is capped, and delete and bulk export are not granted at all.
- Grant the minimum. RFC 9700, the OAuth security best current practice, says token privileges should be restricted to the minimum the use case requires and tokens audience-restricted to a specific resource server [3]. Decline install flows that ask for full API access, and ask the vendor which objects and actions its agent actually uses.
- Bound refresh tokens. RFC 9700 requires refresh tokens to be bound to the scope and resource servers the owner consented to, and recommends they expire after a period of client inactivity [3]. Ask how long the vendor's tokens live and whether they survive a password change.
- Pin the network. Where the system supports it, restrict the agent's identity to the vendor's published egress addresses, the control GTIG recommended for connected apps [1].
- Separate reading from acting. Reading cases, updating them and sending email are different grants. Where the system allows it, give each its own credential so one can be revoked without the others.
- Make outbound and irreversible actions ask or stay capped. Sending from your domain, deleting records, issuing credits and pushing to protected branches need a person or a hard hourly limit; OWASP suggests rate limiting a mail-sending interface for exactly this reason [5].
| Vendor agent | What the vendor asks for | What to grant | Should ask a person or stay capped | What to log on your side |
|---|---|---|---|---|
| Support bot in the CRM | Full API access to the CRM | Read and update on cases and contacts in its queues; no export, no delete | Credits above a set amount, account changes, bulk updates | Every write, with record ID, changed fields and the triggering ticket |
| AI sales development agent | Send-as on employee mailboxes, CRM read and write | A dedicated sending identity, read on leads and accounts, write to activity records only | First email to a new domain, any attachment, sends above a daily cap | Every message sent: recipient, content hash and the record that triggered it |
| Contractor's coding agent | A personal access token with repository admin | A fine-grained token on named repositories: branch pushes and pull requests; no admin, no workflow files | Pushes to protected branches, changes to CI workflows or agent configuration | Pushes, pull requests and token use by source address, tied to the contractor |
| Meeting or productivity assistant | Read all calendars, drives and chat | Read on the invited user's calendar and the meeting's linked documents | Sharing outside the organization, posting to channels | Files read and summaries shared, by user |
| Accounts payable agent | Read and write on the ledger and payment runs | Read invoices and vendor records; create draft payments only | Releasing any payment, adding or changing a payee's bank details | Drafts created, approvals and releases, with the approver |
Decision 3: what does the contract oblige the vendor to do?
The NIST AI RMF calls for policies and procedures that address AI risks from third-party entities, and for contingency processes to handle failures or incidents in high-risk third-party AI systems [2]. For a vendor agent, that becomes terms you can enforce.
- The vendor names each agent that will act in your systems, its actions and its scopes, and gives notice before adding actions or scopes.
- Credentials you grant are used only by the named agent for the named purpose, stored encrypted, and never passed to subprocessors.
- The vendor notifies you within an agreed window, such as 24 hours (an example, not a standard), of any suspected compromise of your tokens or its agent platform, and says which tokens to revoke.
- The vendor provides its agent's action logs for your systems on request, including the input that triggered each action, retained for an agreed period.
- You may suspend the agent at any time without penalty, and the vendor documents how its own pause works and what keeps running after it.
- On termination the vendor revokes and deletes your tokens, deletes your data from its agent's memory and logs, and confirms in writing.
Decision 4: whose record of its actions will you trust?
Your own. Vendor logs are written by the party you are trying to check, and in a compromise they may be the first thing touched. In the Drift campaign the actor deleted query jobs but the platform's logs remained, and GTIG's investigation steps start there: event monitoring records of queries, authentication activity from the connected app and activity by the integration user [1]. That works only if the logs exist on your side and are kept long enough to investigate.
For each vendor agent, record the identity that acted and on whose behalf, the action and target object, a hash or summary of what changed, the time and source address, and the vendor's request ID so its logs can be matched to yours. Those logs should answer two questions: who acted, and for whom.
Decision 5: who can stop it, and how long does that take?
Every vendor says its agent can be paused. The real question is whether you can stop it without the vendor, and how fast. The NIST AI RMF asks for mechanisms, with assigned and understood responsibilities, to supersede, disengage or deactivate AI systems [2].
A vendor console pause depends on the vendor; disabling the identity, revoking grants and refresh tokens, and blocking at the gateway or network are yours. After any of them, check what keeps running without the credential.
The layers differ in who controls them and what they stop. A console pause depends on the vendor's systems working as described. Disabling the integration identity stops new sign-ins, but in many systems an already-issued access token stays valid until it expires. Revoking the grant and its refresh tokens ends existing sessions. Blocking at a gateway or network edge stops the calls that pass through it. Use the layers you control first, then check what keeps running without the credential: messages queued in the vendor's outbox, scheduled jobs, webhooks that push into your systems, a second credential created during onboarding, and sending-domain delegation that lets the vendor send as you with none of your tokens.
The drill that found three things still running
Harrow & Pine, a fictional outdoor-equipment retailer of 1,200 people, runs a vendor's support bot in its CRM, a second vendor's AI sales agent, and a contractor's coding agent on its storefront repository. After reading about Drift, its security team ran a one-hour drill: stop each agent using only controls Harrow & Pine owns, and time it. The figures are illustrative.
The support bot stopped in four minutes: the team deactivated its integration user, revoked the connected app's tokens, and the bot's next write failed. The coding agent seemed to stop when the contractor's token was revoked, but a pull request appeared twenty minutes later. During onboarding the contractor had added a second token to the repository's CI secrets, and nobody had recorded it.
The sales agent kept sending. Revoking its mailbox access stopped it reading replies, but outbound mail went through the vendor's own sending service, which Harrow & Pine had authorized for its domain through DNS records at setup. Stopping it took a DNS change and a call to the vendor, and about two hours of scheduled emails went out first. The drill produced three fixes: a register of every credential and delegation each vendor agent holds, a contract term requiring the vendor to purge queued sends on suspension, and a quarterly repeat of the drill.
Decision 6: how does it leave?
Vendor agents are rarely offboarded on purpose: the contract lapses and the tokens keep working. Treat the end like a privileged employee leaving, and work from the credential register, not memory.
- Revoke every grant and refresh token, and delete or disable the integration identity.
- Remove sending-domain delegations, webhooks, scheduled jobs and any secrets the vendor added to your CI or configuration.
- Rotate secrets the agent could read. After Drift, GTIG advised searching the exposed data for keys and passwords and rotating what was found, because the actor had searched it for the same things [1].
- Check your logs for any use of the agent's identity after revocation, and investigate what you find.
- Get written confirmation that the vendor deleted your tokens and data, including agent memory or logs that hold your content.
- Remove the agent from your inventory and record the date, so the next access review does not rediscover it.
What a gateway can stop, and what it cannot
A gateway controls only the calls that pass through it. A vendor calling your SaaS APIs straight from its own cloud bypasses it, so scopes, IP restrictions and those systems' logs remain the controls there. Where a vendor or contractor agent reaches your tools, MCP servers or models through Intertrace, it uses its own runtime key: its actions are attributed to it, each decision is recorded with the rule that made it, and revoking the key is a kill switch you hold. Outbound messages, payments and admin changes ask a person. Read-only discovery of identity-provider AI-app grants and committed keys finds vendor agents you already let in.
The decision that sits above the security team
Every step above assumes someone owns the vendor agent on your side: keeps its register entry current, times its drill, and runs its exit. If nobody does, none of the rest happens. Before re-scoping anything, list every vendor and contractor agent that can act in your systems, starting from identity-provider grants, connected apps and integration users, and put one internal owner's name next to each. An agent with no owner is the one still sending mail two hours after you thought you stopped it.
