The OAuth Problem in Agentic AI: Per-User Tokens vs Service Accounts

Every agentic AI platform has to make this decision in its first week of development.

A user wants to connect their QuickBooks account so the AI can read financial data. Two architectures exist.

Service account. The platform has its own QuickBooks connection. All users of the platform query QuickBooks through that single connection. The connection is authenticated once, by the platform operator, and shared across the user base.

Per-user OAuth. Every user authorizes the platform against their own QuickBooks account. Every query to QuickBooks uses that specific user's OAuth token. The platform stores tokens per user, refreshes them per user, revokes them per user.

Service accounts ship in an afternoon. Per-user OAuth takes a week. Most platforms choose the afternoon. Most platforms regret it.

Why service accounts look attractive

On the surface, the service account architecture has real engineering advantages. Simpler credential management. One set of credentials, managed in your secret store, rotated on a schedule. Faster onboarding. Users do not click through an OAuth consent screen. They just start asking questions. No token refresh complexity. You handle token refresh once, on your own schedule, without coordinating with a user base. No per-user scope configuration. The service account has whatever permissions it has, applied uniformly.

If you are shipping a demo or a proof of concept, these advantages are real. If you are shipping a product, they are a trap.

Why service accounts fail in production

Four problems show up as the platform matures, and they all show up at the worst possible time.

Problem 1: audit attribution is impossible. Every compliance framework has a variant of the same control. SOC 2 CC6.1. CMMC AC.L2-3.1.1. HIPAA 164.312(a)(2)(i). The control says: every access to a protected system must be attributable to a specific human identity. Service accounts fail this control on day one. Your logs show "the CorpusIQ service account queried QuickBooks at 2:47 PM." They do not show "Ted queried QuickBooks at 2:47 PM." The auditor asks who the human was. You cannot answer. Control fails. For regulated customers, this single control failure means your platform cannot be purchased. No amount of feature richness compensates.

Problem 2: the blast radius of a breach. A service account has access to every user's data. If the service account credentials are compromised, every user is exposed. Per-user tokens contain the damage. If one user's token is compromised, only that user is exposed. The other 999 users are unaffected. Enterprise security reviews explicitly ask about blast radius. "What happens if your service account is breached?" is a standard question. "All customer data is compromised" is a conversation-ending answer.

Problem 3: permission heterogeneity. Different users want different permissions. One user wants the AI to have read-only access to Shopify. Another user wants the AI to have write access for inventory updates. A third user wants the AI locked out of customer PII entirely. Service accounts cannot handle this. The service account has whatever permissions it has. If the permissions are broad, risk-averse users cannot deploy your platform. If the permissions are narrow, feature-hungry users cannot use the parts of the platform they want. Per-user OAuth lets every user choose their own scope at the time of authorization.

Problem 4: revocation is all-or-nothing. A user leaves the company. Their access needs to be revoked. With a service account, there is nothing to revoke. The user never had individual access. The only way to revoke is to change the service account credentials, which revokes access for every user on the platform simultaneously. With per-user OAuth, the user's token is revoked at the identity provider. The platform respects the revocation on the next token refresh attempt. Other users are unaffected.

Why per-user OAuth is worth the cost

The engineering work for per-user OAuth is real. You have to implement OAuth consent flows for each provider. You have to store tokens securely per user. You have to handle token refresh across providers with different refresh semantics. You have to handle revocation gracefully.

This is maybe a week of focused engineering work per provider. For a platform with 20 connectors, that is 20 weeks of work, spread over the product lifecycle.

The cost is worth paying because it unlocks the customer segment that actually pays. SMBs under 10 employees might deploy on either architecture. SMBs between 10 and 100 employees start asking about audit attribution when they hit roughly 50 employees. Enterprises and regulated industries require per-user OAuth. Non-negotiable.

If your platform targets any customer above 50 employees, per-user OAuth is not optional. It is the license to operate.

The specific technical pattern

Authorization code flow. User initiates a connection. Your platform redirects to the provider's OAuth consent screen. User consents. Provider redirects back with an authorization code. Your server exchanges the code for an access token plus a refresh token. Both tokens are stored against the user's identity.

Token storage. Tokens are encrypted at rest with a key specific to your platform, not the provider. Tokens are never logged in plaintext. Tokens are retrieved only by the specific user's session context.

Refresh handling. Access tokens expire. Before making a tool call, your server checks token freshness. If the access token is close to expiry, it uses the refresh token to get a new one. Failed refresh triggers a re-authorization prompt on the user's next session.

Revocation handling. When a tool call returns 401 with invalid-grant, your server treats it as a revoked token. The user's connection state is marked as requiring re-authorization. No silent retries.

Scope minimization. At authorization time, request the minimum scopes needed. Not the maximum scopes you might need later.

The enterprise question set

When an enterprise evaluates your platform, the OAuth architecture questions come up in the first call.

Do you support per-user OAuth for every connector? Answer should be yes. How are tokens stored and who has access? Answer should cover encryption at rest, per-user isolation, and the fact that no admin role can read plaintext tokens. What happens when a user is offboarded? Answer should cover revocation propagation and the time window between revocation and enforcement. Can we specify scope per connector? Answer should be yes. How do you handle provider OAuth policy changes? Answer should cover your operational process for reacting to Google, Microsoft, and Intuit scope policy updates without breaking customer access.

Platforms that answer all five well are enterprise-ready. Platforms that cannot answer three or more are not.

The honest trade-off

Per-user OAuth is more work. It is also the only architecture that survives enterprise scrutiny.

Teams that ship service accounts to move fast often rebuild their authentication layer in year two under audit pressure, while also migrating existing customer data to the new architecture. Teams that ship per-user OAuth from day one take longer to reach their first paying customer and have a much smoother path to their hundredth.

The correct trade-off depends on what business you are building. If the goal is a consumer-facing novelty that will never be audited, service accounts are fine. If the goal is an enterprise-ready platform, per-user OAuth is table stakes. Most founders claim to be building the second and ship the first. Do not be that team.