TL;DR
- Give the agent a traceable application identity and a bounded user or tenant delegation. A shared administrator token hides who authorised the action and makes offboarding harder.
- Auth0 Token Vault, Descope's outbound/agent connections and WorkOS Pipes address third-party credential lifecycle. WorkOS Connect and Stytch Connected Apps address a different direction: other applications accessing your own platform.
- A stored OAuth token is not an approval for every CRM action. Check tenant, user, scope, record access and current business authorisation at the write boundary.
- Price active users, connected accounts, organisations and enterprise controls separately. Fifty users across five CRM workspaces can mean very different connection counts.
Identify the actor and the authority
An agent may act for a seller while running under an application's workload identity. Both identities matter. The application needs permission to retrieve a delegated token; the token's user needs permission to access the CRM record; the proposed action needs a valid business authorisation.
Record user, tenant, application, connected CRM workspace and operation. A log that only says “automation updated account” cannot explain which person's access made the update possible. Do not place the raw token in prompts or logs to make that audit easier.
Use the CRM's permission model rather than trying to recreate every restriction in model instructions. Restrict scopes where available and check record access. A read scope can be broad, and a write scope may authorise more operations than the user intended. Add an application policy for allowed actions and sensitive fields.
The MCP gateway guide covers central tool routing. Here the decision is whose identity and credential the route uses. The CRM agent platform guide covers the broader application purchase.
Buy the correct direction of connection
| Product path | Direction | Useful purpose | Boundary to keep clear |
|---|---|---|---|
| Auth0 Token Vault | Your app accesses third-party services | Store/manage delegated provider tokens | Token retrieval is distinct from action approval |
| Descope outbound/agent connections | Your app or agent accesses third parties | OAuth lifecycle and controlled token access | Traditional Outbound Apps and agent Connections are distinct console objects |
| WorkOS Pipes | Your app accesses customer-connected services | Provider OAuth and token lifecycle | Pipes differs from WorkOS Connect |
| Stytch Connected Apps | Other apps access your platform | OAuth consent for your APIs | It is not automatically an outbound CRM token broker |
Auth0 Token Vault
Auth0's Token Vault description addresses third-party API tokens used by agents on users' behalf. This is a useful candidate where Auth0 already owns application identity and the team wants the external credential lifecycle near that identity layer.
The significant exit detail appears in Okta's service-specific terms: deleting a connected account from the vault does not automatically revoke tokens at the external provider. Offboarding must therefore address both the broker and CRM side.
Choose it when the supported connection and entitlement fit the application. The reviewed terms include Token Vault in all Auth0 plans, while the AI Agents add-on increases connected-app allowances and is offered for Growth and Enterprise. Avoid assuming the base identity plan includes every agent capability or connected-app allowance. Obtain a price for the actual users, connections and required controls, and test provider revocation rather than equating deleted storage with cancelled authority.
Descope
Descope's Outbound Apps documentation describes third-party token storage, refresh and policies controlling who retrieves credentials. It distinguishes traditional Outbound Apps from agent Connections. That distinction matters when designing an agent or MCP server: use the intended product path and ownership model.
This is relevant to teams wanting tenant/user-specific connections and policy around retrieval. Define the user and tenant reference explicitly, then test a request from a different client context. A correctly encrypted token is still dangerous if the application asks for the wrong tenant's credential.
The trade-off is another policy and identity integration to maintain. Choose it when lifecycle and access controls remove real custom work. Avoid buying it as a substitute for defining permissions. Confirm provider support, refresh behaviour, audit retention and current commercial units in the proposed plan.
WorkOS Pipes
WorkOS Pipes documentation describes customer-connected third-party services and manages OAuth, refresh and credential storage. Its data integration reference describes provider credentials, scopes and settings. This is the relevant outbound path for a product connecting customer CRMs.
WorkOS Connect concerns OAuth/M2M applications accessing your platform. Keep those directions separate in the architecture and proposal. A feature named “Connect” should not be selected solely because the project needs connections.
Choose Pipes when the provider coverage and customer connection lifecycle fit the product. Evaluate custom providers, reconnect experience and error visibility for the support team. Price active connections and required enterprise features using the current offer; an identity-user tariff is not necessarily the complete integration price.
Stytch Connected Apps
Stytch's consent management documentation describes your application serving as an identity provider for connected applications. It is relevant when your CRM-facing product exposes its own API or MCP service to external agents.
It should not be presented as equivalent to an outbound Salesforce token vault without evidence of that specific capability. Choose it for inbound OAuth consent and app-access governance. For outbound CRM credentials, procure a documented broker or implement the provider lifecycle separately.
Map fifty users to five CRM workspaces
Consider 50 users in five customer workspaces. If each user connects only their own workspace, there are 50 user connections. If every user connects all five, there are 250. If the customer grants a tenant-level service connection, there may be five provider connections but a separate 50-user authorisation problem. These are architectural alternatives, not interchangeable billing units.
For each operation retain actor user, customer tenant, provider workspace, scope and connection owner. An approval to update one company's account should identify the exact proposed changes, not simply “allow CRM”. Recheck permission immediately before the write, especially after a long wait.
On offboarding, disable application access, revoke or detach the delegated provider grant, remove broker access and stop queued work relying on it. Reassign tenant-level connection ownership where valid rather than leaving the departing employee as the hidden administrator. The sales approval guide addresses the decision layer around consequential changes.
Cost the identity lifecycle
Assume a broker/platform costs $200 monthly, implementation takes 40 hours at $75 per hour and ongoing connection support takes four hours monthly at $60 per hour. Initial implementation is $3,000 and recurring cost is $440 before the existing CRM and identity subscriptions. These are hypothetical budgets, not provider prices.
If a bespoke integration takes 80 hours and eight monthly support hours under the same rates, initial cost is $6,000 and support is $480 before hosting. The managed option can be rational even when its software fee is higher, but only if it actually handles the provider and controls required. Price reconnection, custom providers, organisation features and audit access in the contract.
Use the ABM Account Scoring Template to distinguish authorised account evidence from fields the agent need not retrieve. Reducing unnecessary access can simplify the permission model as well as the prompt.
Test revocation and the final write
Test an expired token, a revoked grant, a removed user, the wrong tenant, insufficient scopes and a permission changed after approval. Confirm that the agent stops or requests reconnection with a useful reason. It should not silently fall back to a shared administrator credential.
Choose the broker direction and deployment that fit the requirement, then validate its boundary. A vault reduces credential-handling work; the application still owns the intent, tenant mapping and allowed action. That is the buying distinction to preserve before selecting a familiar identity brand.
FAQ
Is OAuth consent enough to authorise a CRM write?
It grants the documented scopes to an application. The user may still intend only a narrower task. Apply record permissions and an application action policy, and require additional approval where the business process needs it.
Can one service account represent everyone?
It can be appropriate for a genuinely tenant-owned background service, with restricted permissions and clear ownership. It is a poor substitute for user delegation when the operation must respect individual access and attribution. Record which model each workflow uses.
Does deleting a token revoke access everywhere?
Not necessarily. Remove broker access and verify provider-side revocation, plus queued operations and cached credentials. Test the documented lifecycle for each provider rather than assuming a delete button has universal effects.
Why do inbound and outbound OAuth products differ?
Inbound OAuth lets other applications use your APIs under your consent policy. Outbound OAuth lets your application access a customer's third-party service. A project may need both, but their tokens, billing and authority boundaries should be designed separately.
