You build a Slack agent that pulls GitHub issues, creates Jira tickets, and sends Stripe invoices. Ten people use it. Each person signs in with their own account. The agent uses a single service credential.

Who is allowed to see which issues? Who can create invoices? When the agent makes 50 API calls in one user request, whose permissions apply?

This is the multi-user agent access control problem. OAuth was designed for one user, one session, one token. Agents break that model because the agent is the shared actor, but the authorization boundary must still enforce per-user permissions.

The Single-Credential Trap

Most internal agents start with a service account. You generate one GitHub token, one Slack bot token, one Stripe key. You paste them into .env and ship.

This works until someone asks: "Why can the sales agent see engineering repos?" or "Who approved that refund?"

The service account has admin scope. Every user inherits admin scope.…