Managed OAuth for AI agents: who authorizes what

An Agent200 API key lets your application call Agent200. It does not open anyone’s inbox. An agent that works with a person’s private messages, files or calendar needs that person’s permission first, and that is exactly the part of agent development most teams would rather not build again.

Three parties, three decisions

Every tool call that touches a user’s account rests on three separate decisions:

1. You, the developer, decide which services, endpoints and OAuth scopes your application may use.
2. The end user authorizes access to their own account, on the provider’s own OAuth page.
3. The external service enforces the permissions it granted, through its API.

A tool runs only when all three line up. Agent200 manages the second step for every supported connector and respects the other two.

When a connection is missing

Say an end user asks your agent to summarize their recent email, and they have never connected an account. Here is the flow:

1. Your agent calls Agent200 for that user. Agent200 checks the user’s connection status.
2. No authorized connection exists, so Agent200 returns an authorization URL, or sends the user through its hosted authorization page.
3. The user opens the link and lands on the provider’s OAuth page.
4. After they approve, the provider redirects to a callback on an Agent200 domain.
5. Agent200 stores the credentials and associates the connection with that end user.
6. The capability is available, for this request and the ones after it.

Two ways to present it

• In your own interface. Agent200 tells you authorization is required and gives you the URL. You show it wherever it fits your product, and decide when to run the request again.
• Through hosted authorization. Agent200 provides the authorization experience, so you do not design a connection screen at all.

Either way, you never write a callback handler, store a refresh token or schedule a token refresh.

Every user keeps their own connections

Connections belong to individual end users inside your project:

Your project
├── user_123
│   ├── Chat workspace A
│   └── Email account A
└── user_456
    ├── Chat workspace B
    └── Email account B

When you call Agent200 for user_123, it uses the connections belonging to user_123. It never reaches for credentials that belong to user_456. That mapping is the base of the whole identity model.

Authorization is not unlimited access

Connecting an account does not hand an agent everything in it. What a tool can actually do depends on the scopes the user granted, the endpoints you enabled, and what the provider’s API allows. You can narrow it further at any time: an agent can be allowed to search email without being allowed to send it.

Read more about identity and permissions, or see which services connect through managed OAuth in the integrations catalog.