Notifications
Clear all
Topic starter
06/07/2026 9:43 am
TL;DR: Custom GPTs can call protected APIs through OAuth, token validation, and scope checks without standing up an MCP server, according to Descope. The real question is not whether the connection works, but whether the authorisation boundary, token lifecycle, and server-side enforcement remain defensible as agent usage scales.
NHIMG editorial — based on content published by Descope: Secure API Calling With Custom GPTs and Descope
Questions worth separating out
Q: How should security teams govern custom GPTs that call internal APIs?
A: Treat them as delegated clients, not trusted users.
Q: Why do OAuth scopes matter when an AI assistant accesses APIs?
A: Scopes are the line between a token that is merely valid and a token that is actually authorised for a specific operation.
Q: What breaks if a GPT can authenticate but not be constrained by scopes?
A: Authentication alone only proves the client has a token.
Practitioner guidance
- Treat custom GPTs as delegated clients Model every GPT-to-API connection as a delegated access path with explicit owner, scope, and expiry.
- Keep consent and token exchange on the server side Use the backend as the only place that handles OAuth callbacks, token exchange, and redirect validation.
- Bind each operational endpoint to a narrow scope Assign separate scopes for read and write operations, then reject any token that is valid but broader than the intended route.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step FastAPI JWT authorisation code for validating signatures, issuer, audience, and expiry.
- Proxy endpoint examples for /authorize, /token, and /api/oauth/callback so you can reproduce the OAuth flow.
- OpenAPI configuration details for wiring a GPT action to a protected API.
- Descope consent flow and session timeout settings that affect real deployment behaviour.
👉 Read Descope's guide to secure API calling with custom GPTs →
Custom GPT API calling: is OAuth enough for identity control?
Explore further
06/07/2026 9:59 am
OAuth does not solve the identity problem by itself. The article shows a working access pattern, but the underlying governance question is whether a conversational client should ever be allowed to obtain and reuse tokens on behalf of a user. OAuth scopes limit what the client can do, but they do not explain who owns the delegated capability once the session is active. Practitioners should treat the token as the enforcement object and the GPT as an access broker, not a trusted identity.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- That same report found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own the risk of custom GPT API access in IAM programmes?
A: IAM, application security, and platform teams should share ownership, but the decisive control belongs to the API owner. That team defines scopes, validates tokens, logs usage, and can revoke access without changing the GPT itself.
👉 Read our full editorial: Secure API calling for custom GPTs needs OAuth and scope control
