Before an agent can call your API on someone's behalf, you have to answer one question: how does the system know who that someone is? There are three workable answers, and the right one depends less on your architecture than on who your users are.
1. Broker the identity
Users sign in through the gateway's own identity provider. You do not run an IdP; the gateway issues and verifies the tokens. Fastest to stand up, and the right choice when your users do not already have accounts somewhere central, or when you are proving the concept.
The trade-off is that it introduces a second place where users exist, which becomes a joiner-mover-leaver problem the moment you have real customers.
2. Exchange tokens with your existing IdP
Your organisation already runs an identity provider. It is registered with the gateway, users authenticate against it as they always have, and the gateway trusts tokens it issued. Nobody gets a new account.
This is usually right for internal use inside a company that already has SSO. It requires your IdP to be reachable and configured, which is a conversation with whoever owns it.
3. Delegate to your own login
The gateway redirects users to your product's own login page, and your product tells the gateway who signed in over a signed contract. You keep your user directory entirely; your users never learn that a gateway exists.
This is the model for software vendors. Your customers' users already have accounts in your product, and asking them to create accounts somewhere else to use an assistant is a non-starter. It is the most integration work of the three, because your side has to implement the contract.
Choosing
- Your users have no central accounts yet, or you are prototyping: broker it.
- Internal users, company already has SSO: exchange tokens.
- You are a software vendor and the users are your customers' users: delegate to your login.
The property all three must share
Whichever you pick, the agent must end up holding a short-lived session scoped to a person, never a standing credential for your API. If any of the three leaves an API key in a client configuration, it has not solved the problem it was chosen for.