Secure API calling for custom GPTs needs OAuth and scope control

At a glance

What this is: This is a technical guide showing how to connect a custom GPT to FastAPI through OAuth, JWT validation, and scope-based access control.

Why it matters: It matters because IAM teams need to decide how AI-enabled application access should be authenticated, authorised, and contained without turning every integration into an unmanaged identity path.

👉 Read Descope's guide to secure API calling with custom GPTs

Context

Custom GPT integrations create a familiar identity problem in a new wrapper: an AI interface is being granted access to protected APIs, and the control point still has to live on the server. The primary issue is not the chat experience, but whether OAuth, JWT validation, and scope enforcement can preserve a clear authorisation boundary for the API.

This matters for IAM and NHI programmes because AI-facing integrations often sit between human consent, machine credentials, and application access. The article frames a proxy-based OAuth design rather than an MCP server, which makes the control plane easier to reason about but also forces practitioners to think carefully about token handling, session expiry, and least-privilege scope design.

Key questions

Q: How should security teams govern custom GPTs that call internal APIs?

A: Treat them as delegated clients, not trusted users. Keep authentication, token exchange, and scope enforcement in the backend, then map each endpoint to a narrow privilege set. That gives security teams a clear control boundary and a reviewable entitlement model for conversational access to operational systems.

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. Without route-level scopes, an AI assistant can reuse one consented session across tasks that should never share the same privilege.

Q: What breaks if a GPT can authenticate but not be constrained by scopes?

A: Authentication alone only proves the client has a token. If scopes are absent or too broad, the GPT can reach endpoints outside the intended access boundary, which turns a controlled integration into a general-purpose API client with elevated reach.

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.

Technical breakdown

OAuth authorization code flow for custom GPT API access

The article uses the OAuth authorization code flow to let a custom GPT obtain access tokens for API calls. The GPT initiates authentication, the user consents to scopes, and the backend exchanges the code for tokens before forwarding requests to FastAPI. The important security property is that the API never trusts the GPT itself. It trusts a token issued by the identity layer, then validates that token on every request. That keeps authorisation decisions on the server side instead of inside the conversational interface.

Practical implication: treat the GPT as an untrusted client and keep token validation and scope enforcement in the API layer.

JWT validation and scope enforcement in FastAPI

The FastAPI backend validates JWT signatures, issuer, audience, expiry, and scopes using a JWKS-backed verifier. That means the API checks both whether the token is genuine and whether it is authorised for the specific route. This is the difference between authentication and authorisation. A token can be valid and still be denied if it lacks the required scope. For identity teams, this is the right place to enforce route-level access because it ties every request to a verifiable, bounded entitlement.

Practical implication: map each API route to explicit scopes and reject any token that is valid but over-broad.

Proxying OAuth endpoints under the API domain

The proxy pattern keeps the OAuth authorize and token endpoints under the same domain as the backend API, which avoids cross-domain complexity when a custom GPT interacts with the service. The article also notes that a custom Descope domain can remove the need for the proxy. Architecturally, this is about preserving a coherent trust boundary while still supporting the GPT workflow. It reduces implementation friction, but it also concentrates responsibility in one backend domain, which makes logging, error handling, and redirect validation part of the security design.

Practical implication: if you use a proxy, harden redirect handling and audit every token exchange and callback path.

NHI Mgmt Group analysis

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.

The proxy pattern makes the trust boundary visible, but not smaller. Moving authorize and token handling into the API domain simplifies integration, yet it also concentrates authentication, callback processing, and scope enforcement in one path. That is useful for control and auditability, but it also means the backend becomes the single place where misvalidation can turn a bounded session into an over-permissive one. The implication is that identity teams must design for observability at the proxy boundary, not assume the proxy itself is a control.

Scope-based access is the right minimum control for AI-assisted API use. The article’s 401 and 403 split is a useful reminder that authentication failure and privilege failure are different outcomes. That distinction matters when a GPT is acting as an interface over operational APIs, because the request may be syntactically valid while still exceeding intended authority. Practitioners should anchor governance in explicit route scopes rather than broad session trust, especially where operational endpoints can change state.

Custom GPT integrations should be governed as delegated machine access, not just application development. The article sits at the intersection of human consent, machine token use, and API exposure. That combination belongs in NHI governance because the effective identity is no longer just the user or just the app, but the tokenised delegation chain between them. Teams that already manage service accounts and API keys will recognise the pattern immediately: the access path is only as strong as the lifecycle of the delegated credential and the precision of the scope model.

Named concept: delegated conversational access. This pattern describes a natural-language client that receives user consent, acquires scoped tokens, and calls protected APIs without becoming a fully autonomous actor. It is distinct from a general AI agent because the runtime behaviour is still bounded by OAuth and server-side policy. Practitioners should use this concept when deciding whether a custom GPT belongs in application security, IAM governance, or both.

From our research:

• 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.
• For a deeper governance lens, compare that exposure with Ultimate Guide to NHIs, which frames lifecycle, visibility, and privilege control across machine identities.

What this signals

Delegated conversational access will become a governance category in its own right as more organisations connect chat-based interfaces to internal APIs. The decision point is no longer whether the interface feels safe, but whether the token lifecycle, scope design, and callback handling can survive real operational use. Teams that already manage workload identity will find the pattern familiar, because the failure mode is still uncontrolled privilege delegation.

The stronger signal for identity programmes is that API access is shifting from fixed integrations toward consented, session-bound machine use. That puts pressure on access review, entitlement design, and audit logging because the control object is now a delegated token rather than a standing account. In practice, the programme must be able to answer who consented, what was scoped, and when the session ended.

AI-facing integrations should be measured like any other identity surface, not like a UX feature. If the organisation cannot trace which GPT action used which scope, the governance model is incomplete. For a broader identity baseline, the Ultimate Guide to NHIs remains the clearest reference point for linking lifecycle and privilege controls to machine access.

For practitioners

• Treat custom GPTs as delegated clients Model every GPT-to-API connection as a delegated access path with explicit owner, scope, and expiry. Require the backend to validate issuer, audience, signature, and route-level scopes on every request.
• 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. Avoid pushing these trust decisions into the client layer or the GPT action definition.
• 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. This prevents a single consent from opening unrelated API functions.
• Log and review callback behaviour Record authorize requests, token exchanges, denied scope attempts, and refresh activity so identity teams can trace how a GPT obtained access and whether it exceeded its intended boundary.

Key takeaways

• Custom GPT API access is an identity problem first and an integration problem second. OAuth and JWTs can make the connection work, but they do not remove the need for explicit control over delegation, scope, and token lifecycle.
• Server-side scope enforcement is the boundary that keeps conversational access from becoming broad API access. When authentication succeeds but authorisation is too loose, the GPT becomes a privileged client rather than a controlled one.
• IAM teams should govern GPT-to-API connections as delegated machine access with auditability, expiry, and revocation built in. That makes the access path reviewable even when the interface is natural language.

Key terms

• Delegated conversational access: A delegated conversational access pattern lets a chat interface obtain scoped credentials and use them on behalf of a user. The control challenge is not the conversation itself, but the lifecycle, scope, and revocation of the token that carries the authority.
• Scope-based authorization: Scope-based authorisation limits what a valid token can do by tying it to named actions or routes. In practice, it is the difference between a token that proves identity and a token that is allowed to perform a specific operation.
• JWT authorizer: A JWT authorizer is the backend component that checks whether a JSON Web Token is genuine, current, and intended for the resource server. It typically validates signature, issuer, audience, and expiry before any request is allowed to proceed.
• OAuth callback proxy: An OAuth callback proxy is a server-side endpoint that receives the identity provider response and forwards or transforms it for the client application. It simplifies cross-domain flows, but it also becomes part of the security boundary and must be validated carefully.

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.

👉 Descope's full post shows the FastAPI implementation, OAuth proxy flow, and GPT action setup in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.