How Do You Manage App Connections for a Multi-User AI Agent?

A practical field guide from Automation Ace.

Short answer: to manage app connections for a multi-user AI agent, use a managed auth platform (Composio, Nango, Pipedream Connect, or Arcade) to store each user's tokens, keep your own table that maps every connection ID to the user or organization that owns it, and scope every agent run to the signed-in user so the agent can only use that user's (and their organization's approved shared) connections. Add connect links for missing apps, a reconnect flow for expired access, a connections page in your product, and admin controls for shared connections and offboarding.

Short answer

1. Managed auth platform for tokens; your database for ownership.
2. Every connection belongs to a user or an organization.
3. Every agent run is created server-side for one user, with only allowed apps and tools.
4. Connect links on first use; reconnect on failure.
5. A connections page for users and controls for admins.

The data model

Names differ, but every platform has the same pieces. Your job is to connect them to your own users and organizations reliably.

Step 1: Use a managed auth platform

Storing and refreshing tokens for thousands of users across many apps is a product of its own. Let a platform do it and keep tokens out of your database and away from the model. See the best managed app auth platforms and keeping tokens away from agents.

Step 2: Tie every connection to a user or organization

-- Your side: who owns which connection (no tokens)
users(id, org_id, email, ...)
app_connections(
  id               PK,
  owner_type       'user' | 'org',      -- personal vs shared connection
  owner_id         user or org id,
  app              'gmail' | 'hubspot' | ...,
  platform_ref     connection / connected account / account id,
  account_label    'pat@prospect.com' or 'Acme HubSpot',
  status           'ok' | 'needs_reconnect' | 'revoked',
  created_by, created_at, last_used_at
)

• Set your user and organization IDs when the connection is created (Nango tags, Pipedream external user ID, Composio and Arcade user IDs).
• Confirm creation from the platform's webhook or callback, then save the reference.
• Record the account label so users can tell two Gmail accounts apart.
• Derive user IDs from your authenticated session; Composio's docs, for example, advise against trusting a browser-supplied ID.

Step 3: Scope each agent run to one user

// At the start of every agent run (server-side)
const user = await requireSession(req);                 // never from the prompt
const allowedApps = policyFor(user.role);               // e.g. ["gmail", "hubspot"]

const session = await createAgentSession({
  userId: user.id,                                      // selects this user's connections
  orgId: user.orgId,                                    // for shared org connections
  apps: allowedApps,
  tools: toolAllowlistFor(user.role),                   // read/draft tools only for most roles
  expiresIn: "1h",
});
// Pass session.mcpUrl + session.token (or the scoped tools) to the agent

The model should never choose whose account to use. Your backend picks the user, the connections, and the tool allowlist before the agent starts. See how to limit which app actions an agent can take.

Step 4: Handle the connection lifecycle

Step 5: Give users a connections page

• List each connected app and account, its status, and when it was last used.
• Connect, reconnect, set default account, and disconnect buttons.
• Plain language about what the agent can do with each app.
• Warnings when a connection needs attention, also surfaced in the agent's replies.

Step 6: Admin controls and audit

• Org admins choose which apps and actions are allowed for which roles.
• Shared connections have a named owner and can only be changed by admins.
• Every tool call is logged with user, connection, action, and result; see permissions, approvals, and audit trails.
• Offboarding revokes personal connections; see what happens when someone leaves.

Common mistakes

• One shared connection for every user, so the agent acts as one person for everyone.
• Letting the prompt or browser decide which user ID to use.
• No record of who owns a connection, so nobody can fix it when it breaks.
• Deleting and recreating connections instead of reconnecting, which loses configuration.
• Giving every user every tool by default.

Your users already connected apps in Zapier or Make? See reusing automation app connections in an AI agent.

Frequently asked questions

How do I manage app connections for a multi-user AI agent?

Use a managed auth platform to store each user’s tokens, keep your own table mapping each connection to the user or organization that owns it, scope every agent run to the signed-in user with only allowed apps and tools, and build connect, reconnect, and disconnect flows.

Should each user connect their own account, or use a shared connection?

Personal data such as email and calendar should use each user’s own connection. Shared team systems can use an organization connection with a named owner and admin-only changes. Avoid one connection for everyone.

How does an agent know which user’s connection to use?

Your backend decides before the run starts, from the authenticated session, and creates tools or an MCP session scoped to that user. The model should never choose the user or connection.

How do I support two accounts for the same app?

Allow multiple connections per user for that app, store an account label for each, and let the user choose a default or pick one per task. Some platforms, such as Composio, support multiple connected accounts per user.

What happens to connections when a user leaves?

Revoke their personal connections at the platform and mark them revoked in your table. Reassign or recreate any shared organization connections they owned.