How Stow Uses OAuth Proxying to Prevent Credential Leakage

The standard way to give an AI access to your Google account is to hand it a token — an OAuth Bearer token that the AI includes in every API request. That token, if extracted from the AI's context, gives whoever has it direct access to your account. OAuth proxying is the pattern that removes the token from the AI's possession entirely.

The Traditional Flow (and Its Risk)

In the standard OAuth + AI integration pattern:

1. You authorize the AI application to access your Google account
2. Google issues an OAuth token to the application
3. The application passes that token (or a reference to it) to the AI model in its context
4. The AI uses the token to make API calls directly

The problem: once the token is in the AI's context window, it's in the AI's context window. It can be logged, extracted via prompt injection, included in model outputs, or simply persisted in conversation history longer than intended. The token that was issued for "AI to use on your behalf" becomes a credential that a third party could abuse.

This isn't hypothetical. Prompt injection attacks specifically target this pattern — crafting malicious content that tricks the AI into revealing or misusing credentials from its context.

OAuth Proxying: The Token Never Leaves Stow

The token that gives access to your Gmail is never in Claude's context, never in a prompt, and never in a model output. It exists only in Stow's encrypted credential store and in transit on Stow's servers during the API call.

What This Protects Against

Token Lifecycle in Stow

OAuth tokens have lifetimes — Google tokens typically expire after one hour. Stow manages the full token lifecycle:

• Storage: Tokens are encrypted at rest using AES-256. The encryption key is managed separately from the token data.
• Refresh: Stow uses the OAuth refresh token to obtain new access tokens automatically when they expire. You don't need to re-authorize periodically.
• Revocation: If you disconnect a service in Stow, the stored token is deleted and a revocation request is sent to the service's OAuth endpoint.
• Masking: Any reference to a token in logs shows only a masked prefix (e.g., ya29.a0A…). Full tokens are never written to logs.

How This Differs From Personal Access Tokens

Some services (GitHub, Neon, Airtable, Calendly) use Personal Access Tokens (PATs) rather than OAuth. The proxying approach is the same:

• You generate the PAT in the service's settings
• You paste it into Stow — this is the only time it appears in plaintext
• Stow encrypts and stores it; the original is not retained
• Subsequent API calls use the stored encrypted token, decrypted only at the moment of the API call, within Stow's infrastructure

The AI agent never receives the PAT. It makes a Stow tool call; Stow makes the authenticated service API call.

Connecting Services: The User's Perspective

From your perspective, connecting a service is simple:

• For OAuth services (Gmail, Google Drive, Slack): click Connect, authorize in your browser, done
• For token services (GitHub, Neon, Airtable): generate a token in the service settings, paste it into Stow, done

In both cases, the credential leaves your hands exactly once — when you enter it. After that, Stow holds it, uses it, and the AI agent never sees it.