Building and Selling Multi-User AI Agents with OAuth

Most AI agent tutorials stop at single-user setups, handing you a static API key and walking you through one basic tool call. That works fine for personal projects, but the moment you want to sell or scale an AI agent to multiple users, that design collapses. Without proper access controls, every tool call runs under your credentials, not your user's, leading to security risks, broken functionality, and angry customers. The solution is a multi-user OAuth integration pattern that ensures every AI agent action is attributed to the correct user, with no cross-access. This guide walks you through building a production-ready multi-user AI agent, then monetizing it across multiple channels.

Why Multi-User AI Agents Require Per-User OAuth

When an AI agent acts on behalf of multiple people, every tool call must answer one critical question: who is the agent acting for? A Slack message read must pull data from the correct user's workspace, a GitHub issue must be created in a repo the user has access to, and all actions must be logged under their identity. If you use a shared API key for all users, every action runs under your credentials: Alice's Slack messages would show up in your workspace, Bob's GitHub issues would be created in your personal repos, and a single user revoking access would break the agent for everyone.

The fix has two non-negotiable components, both of which are skipped in most basic agent tutorials:

• Per-user OAuth grants: Each user authorizes access to their connected services individually. Alice grants Slack and GitHub access for her accounts, Bob grants access for his, with no shared credentials between them.
• Identifier-based token retrieval: Your agent never stores or passes raw access tokens to the LLM, tool schemas, or logs. Instead, it passes a unique user identifier (like an email or internal user ID) to a secure function that fetches the correct, decrypted access token only at the exact moment of the tool call, then discards it immediately after.

This pattern is the foundation of any production-ready multi-user AI agent built for SaaS or client work.

Concrete Example: The Channel-Watcher AI Agent

To make this pattern tangible, we'll build a command-line AI agent called channel-watcher-agent designed for dev teams. Each run of the agent performs four automated tasks:

• Reads recent messages from a connected Slack channel
• Uses an LLM to classify each message as a bug report or concrete action item
• Files a GitHub issue for all qualifying messages in the user's own accessible repositories
• Replies to the original Slack thread with a link to the new issue

No manual input is required from the user after initial setup: the agent runs on a schedule, makes its own judgment calls, and all actions are attributed to the user who authorized the connection. The stack is intentionally lightweight, using only Node.js, the Slack Web API, Octokit for GitHub, and a lightweight agent framework, with no unnecessary dependencies.

Step 1: Register OAuth Apps for Connected Services

First, you'll create OAuth apps for every service your agent will connect to. For this example, you'll register apps for Slack and GitHub:

• For Slack: Go to the Slack API dashboard, create a new app, and add bot token scopes for channels:read, chat:write, and thread:read. Enable event subscriptions for new messages in your target channel.
• For GitHub: Go to your GitHub developer settings, register a new OAuth app, set your callback URL, and request repo and issues scopes to let the agent create issues in the user's repos.

This step is standard for any API Integration with OAuth-enabled services, and takes less than 15 minutes for both platforms.

Step 2: Build the OAuth Consent Flow

Next, you'll build the user-facing consent flow that lets users grant access to their accounts:

1. When a user signs up for your agent, redirect them to the OAuth consent page for the service they're connecting (Slack or GitHub).
2. After the user logs in and grants access, the service redirects back to your app with a temporary authorization code.
3. Your app exchanges this code for a long-lived access token and refresh token, after validating the state parameter to prevent CSRF attacks (a common oversight in custom Software Development for OAuth flows).

You'll write this flow from scratch for full control, rather than relying on third-party auth providers, so you can customize it for your agent's use case.

Step 3: Encrypted Token Storage Keyed by User ID

Never store OAuth tokens in plain text. Instead, use a strong encryption key (stored as an environment variable, never committed to version control) to encrypt tokens before saving them to your database. Each token pair (access and refresh) is associated with the user's unique identifier (e.g., their email or internal user ID from your auth system).

When the agent needs to make a tool call for a user, it looks up their ID, decrypts the correct token for the required service, uses it for the call, then discards it immediately. Tokens are never passed to the LLM, included in tool schemas, or written to logs, eliminating the risk of credential leaks.

Step 4: Run Per-User Tool Calls and Handle Edge Cases

With your token store set up, the agent can now run tool calls for each user correctly. For the channel-watcher agent, when processing messages for Alice:

• The agent uses Alice's decrypted Slack token to read messages from her connected channel
• It uses Alice's GitHub token to create issues in repos she has write access to
• It uses her Slack token again to reply to the original thread with the issue link

You'll also need to build logic for token refresh: when an access token expires, use the stored refresh token to get a new one without prompting the user to log in again. If a user revokes access from their Slack or GitHub settings, catch the resulting error, delete their stored tokens, and prompt them to re-authorize.

Monetize Your Multi-User AI Agent

Once you've built the core OAuth integration pattern, you can sell the agent or your implementation services across multiple platforms:

• SaaS subscription: Host the channel-watcher agent (or a custom version for other use cases) as a SaaS product, charging dev teams $15–$30 per user per month for automated issue tracking. Use Stripe for payments, and host on platforms like Vercel or Render for low overhead.
• Custom builds on Fiverr and Upwork: Many businesses need custom AI Agents that connect to their internal tools (Jira, Salesforce, Google Workspace) with per-user OAuth. Offer tailored builds on freelance platforms, with prices starting at $500 for small business use cases and $2,000+ for enterprise integrations.
• Digital products on Gumroad: Sell the
• YouTube tutorials and affiliate income: Post walkthroughs of building the agent on YouTube to drive traffic to your paid products, or earn affiliate income by recommending the tools and platforms you use (hosting, auth providers, LLM APIs).

The key selling point of your agent is the per-user OAuth security: most off-the-shelf AI agents use shared credentials, which is a non-starter for teams that need to keep user data separate, compliant with regulations like GDPR and HIPAA.

Extend the Pattern to Any OAuth-Enabled Service

This OAuth integration pattern works for any AI Agent that needs to connect to user-specific accounts. You can adapt it to build agents that:

• Read a user's Gmail and Calendar to draft meeting recaps and follow-up emails
• Access a sales rep's Salesforce leads to generate personalized outreach messages
• Pull data from a user's Google Drive to answer questions about their internal documents

The core logic remains identical: each user grants their own access, you store tokens encrypted keyed to their user ID, and you fetch the correct token only at the moment of the API call. This pattern is the foundation of any scalable, secure multi-user AI agent built for SaaS or client work.