Secure API calling for custom GPTs needs OAuth and scope control

At a glance

What this is: This article explains how a custom GPT can authenticate to APIs with OAuth and scoped JWTs while keeping authorisation decisions on the server side.

Why it matters: IAM and NHI teams should care because GPT actions behave like delegated machine access, so token issuance, scope enforcement and expiry control become the real security boundary.

Context

OAuth can let a custom GPT call protected APIs without introducing an MCP server, but that only works if the resource server still owns authentication and authorisation decisions. The governance problem is not whether the chatbot can reach the API, but whether its delegated access is constrained by token scope, expiry and validation at the server boundary.

In this pattern, the GPT behaves like a delegated non-human identity that acquires tokens, presents them to the API and continues until the session expires. That means the controls that matter are JWT validation, scope enforcement, consent handling and session management, not the conversational interface itself.

Key questions

Q: How should teams control custom GPT access to protected APIs?

A: Treat the GPT as a delegated client, not a trusted operator. Put authentication, token validation, scope enforcement and revocation in the API layer so the model never becomes the policy decision point. Narrow scopes to the exact endpoint and task, then expire them aggressively when the workflow ends.

Q: Why is OAuth alone not enough for GPT-to-API security?

A: OAuth establishes delegated access, but it does not guarantee that every request is appropriate. The backend must still check token validity, issuer, audience, expiry and endpoint scope. Without those controls, a legitimate token can be used to reach resources that were never meant to be exposed to that client.

Q: What are the signs that a GPT integration has weak authorization control?

A: Look for broad scopes, reused tokens across unrelated actions, unclear 401 versus 403 handling, and authorization decisions that happen outside the resource server. Those signals indicate that the GPT can probably reach more of the API than the business intent allows.

Q: What happens when a custom GPT keeps access after the task is complete?

A: If session expiry and revocation are not tightly managed, the GPT can continue to use delegated tokens after the user expects access to end. That turns a short-lived assistant into a standing machine client, which increases the chance of unintended API use and makes incident scoping harder.

Technical breakdown

How OAuth turns a custom GPT into a delegated API client

OAuth gives the GPT a delegated path to an API through an authorization code flow, consent screen and token exchange. In this design, the GPT does not authenticate by inventing trust; it receives access and refresh tokens after the user consents, then presents those tokens to the resource server. The important distinction is that the GPT is not the policy engine. The API validates the bearer token, checks issuer, audience and signature, and then decides whether the requested endpoint is in scope. That makes the GPT a client of the authorization system, not the authority over it.

Practical implication: keep authorization decisions in the API layer and treat the GPT as an untrusted client that merely carries scoped tokens.

Why JWT validation and scope checks still matter for custom GPTs

A valid OAuth exchange does not by itself make every request safe. The backend still needs to validate the JWT signature, confirm it has not expired, verify issuer and audience claims, and enforce endpoint-level scopes such as read or write permissions. Without those checks, a token becomes a reusable pass rather than a bounded delegation. The article also shows why 401 and 403 must mean different things operationally: one indicates the token failed authentication, the other that the caller is authenticated but not authorised for that action. That distinction is what keeps machine access legible.

Practical implication: enforce JWT verification and scope-to-endpoint mapping on every request, not only at login or consent time.

Why proxying the OAuth server changes the control boundary

Using a FastAPI proxy for the OAuth endpoints lets the application and resource server stay under the same operational domain, which simplifies callback handling and request validation. It also reduces how much of the flow is scattered across external components. But the architectural trade-off is that the proxy becomes part of the trust boundary and must preserve state, redirect handling and token exchange correctly. If the proxy misroutes the callback, weakens validation or mishandles scopes, the GPT can still be granted access that the API never intended to allow. In delegated access models, the authorization server path is part of the security model.

Practical implication: review proxy-mediated OAuth flows as security-critical infrastructure, not as a convenience wrapper.

Threat narrative

Attacker objective: The objective is to obtain and use delegated API access that appears legitimate while exceeding the permissions the resource owner intended.

1. Entry occurs when the custom GPT starts the OAuth flow and receives user consent to act against protected APIs.
2. Credential use occurs when the GPT presents access or refresh tokens to the FastAPI backend for subsequent API calls.
3. Impact occurs if token validation or scope enforcement is weak, allowing the GPT to reach endpoints beyond its intended delegation boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Scoped delegation, not chatbot capability, is the real control plane: This pattern succeeds or fails on whether the API server can preserve authorisation boundaries after a GPT receives tokens. The GPT is only a runtime client; the resource server must remain the source of truth for token validity, audience, issuer and scope. Practitioners should treat this as delegated identity design, not as a conversation feature.

Token lifecycle is the hidden governance problem in custom GPT integrations: The default 10 minute session timeout, refresh behaviour and manual privacy settings show that access persistence is still being managed as identity lifecycle, not prompt lifecycle. That matters because the risk is not just access, but stale access that continues after the user no longer expects the GPT to hold authority. Lifecycle control, not model sophistication, is what bounds the blast radius.

OAuth does not remove the need for server-side authorization policy: This article demonstrates that the authorisation boundary still has to live with the resource server even when the user experience is mediated by a GPT. If endpoint scope checks are weak, then natural language becomes a front end for privilege misuse. The implication for IAM teams is that machine-to-machine delegation must remain policy-enforced at the API, regardless of how the client presents itself.

Custom GPTs create a new class of delegated NHI that should be governed like any other service client: The identity subject is not the language model alone, but the combination of GPT, token issuer, proxy and backend API. That chain needs inventory, scope minimisation, expiry control and revocation paths the same way service accounts do. The practitioner conclusion is simple: if it can call your API, it is part of your NHI estate.

Scope control is the named concept that deserves programme-level attention: The article’s real lesson is that OAuth only stays safe when scopes are precise enough to separate read, write and operational actions. Broad or reusable scopes turn delegated access into ambient access, which is exactly what identity governance is supposed to prevent. Security teams should measure whether their API scopes reflect actual task boundaries rather than generic application convenience.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Scoped delegation is the control boundary: Teams building GPT-driven API access should assume the conversation layer is untrusted and design around server-side enforcement, not model-side promises. That means inventorying which actions are exposed, constraining each one to a narrow scope and making revocation available when the workflow ends.

Custom GPT integrations also surface a familiar identity governance problem in a new wrapper: access persists long enough to become stale unless expiry, consent and reauthentication are actively managed. For AI-facing APIs, the practical question is no longer whether the model can call the endpoint, but whether the delegated access can be proved to stop when intended.

For practitioners

• Define endpoint-level OAuth scopes Map each GPT action to a narrowly bounded scope and avoid reusing broad scopes across unrelated operational tasks.
• Enforce JWT validation on every request Validate signature, issuer, audience and expiry in the backend before processing any GPT-originated API call.
• Treat refresh tokens as governed credentials Set session expiry, revocation and reauthentication rules so delegated access ends when the task or consent should end.
• Keep proxy logic inside the trust boundary Review callback handling, redirect construction and state preservation as security-sensitive controls, not integration convenience.

Key takeaways

• Custom GPTs can reach protected APIs safely only when the API, not the model, owns token validation and authorization decisions.
• The article’s security model depends on narrow scopes, JWT verification and bounded session lifetimes rather than on the conversational interface itself.
• For IAM and NHI programmes, GPT integrations should be governed as delegated machine clients with revocation, expiry and scope minimisation built in.

Key terms

• Delegated API Access: Delegated API access is permission granted to a software actor to act within the authority of a human operator. The important control question is whether the platform enforces the operator’s true entitlement scope at runtime and preserves a clear audit chain back to the requester.
• JWT Validation: JWT validation is the process of checking that a token is signed correctly and that its claims match what the application expects. For OIDC, that means verifying issuer, audience, and expiration, not just decoding the token and trusting its contents.
• Scope Enforcement: Scope enforcement is the technical and procedural control that keeps a testing system within the boundaries it was authorised to evaluate. It includes environment allow-lists, redirect handling, production exclusions, and stop controls that prevent an automated tool from wandering outside its intended remit.
• Consent flow: A consent flow is the authorization journey that records and enforces what a user or agent is allowed to access. In multi-tenant MCP, different tenants may require different consent steps, scopes, or assurance levels, so consent becomes part of identity design rather than a UI 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.