Action Authentication and Security

Status as of November 5, 2026: GPTs are in their final weeks. OpenAI is retiring custom GPTs on December 11, 2026 (February 11, 2027, for certain Enterprise workspaces with an exemption). Personal, Free, Go, Plus, and Pro accounts can no longer create or publish new GPTs; in Business, Enterprise, and Edu workspaces, creation depends on settings, and it ceased on October 26, 2026, in affected Enterprise workspaces. Existing GPTs remain usable and editable if your plan allows, until retirement; your conversations with them will remain accessible afterward. The migration (Migrate to plugin, in My GPTs) converts instructions into a skill, the knowledge base into reference files, and connected applications into apps; custom actions are not transferred. This lesson explains how GPTs work to help you maintain them, migrate them, and apply their principles to a plugin (Lessons 15–17).

Why authentication is non-negotiable

In the previous lesson, you connected your GPT to a public API—a comfortable scenario because the API responded to anyone. The professional reality is different: your CRM, calendar, and database require proof of identity before releasing any data. It stands to reason—you wouldn’t want just any GPT reading your customer records. Without proper authentication, your GPT will receive access denials instead of data. This lesson covers the three authentication modes for actions, followed by the security rules that must accompany every Action.

The three authentication modes

The first mode, no authentication, matches the previous lesson’s case: public APIs that require no identification, such as certain weather APIs, open data sets, or free services. Reserve this for prototyping and truly public APIs—no serious professional tool operates this way.

The second mode, API Key, is the most common in practice. The principle: the external service issues you a secret key, which the GPT attaches to every request to prove its identity. In the editor, configuring an API key takes just a few fields, and the key can be transmitted via Basic, Bearer, or a custom header:

• Auth Type: API Key
• API Key: your key (stored securely by OpenAI)
• Header name: the header name, typically Authorization, X-API-Key, or api-key
• Prefix: the optional prefix, often Bearer with a space

Once these fields are filled, the GPT automatically adds the key to every call. A critical point for confidentiality: the end user never sees the key—your identity is used, regardless of who is chatting with the GPT.

The third mode, OAuth 2.0, addresses a different need: having the GPT act on behalf of each user, not on your behalf. This is the mechanism used by services like Google, Microsoft, or Salesforce. Specifically, when a user launches the GPT for the first time, they are redirected to the external service’s login page, where they personally authorize access to their own data. Configuration requires elements provided by the service: a Client ID and Client Secret, the Authorization URL (the login page), the Token URL (for token exchange), and the Scope—that is, the requested permissions, such as read-only or read/write. It is more complex to set up than an API key, but it is the only correct mode whenever each user must access their own data.

Securing your Actions

Connecting a GPT to your tools entrusts it with access—and all access deserves safeguards. The first is the principle of least privilege: request only the permissions strictly necessary. If your GPT only needs to read CRM contacts, write permission is an unnecessary risk; if it consults a calendar, it has no business touching emails. On the OAuth side, this translates to scopes reduced to the minimum—a detail that counts doubly, because a GPT requesting excessive permissions also scares users at the authorization step.

The second safeguard concerns your API keys themselves. The absolute rule: never paste a key into the GPT instructions. Instructions are extractable by any curious user—it often suffices to ask the GPT to recite them—and your key would become public. Use exclusively the editor’s secure authentication field. In the same spirit, create a key dedicated to your GPT, separate from your personal keys: the day you need to revoke it, your other tools will continue to function. And if the service allows it, impose rate limits on this key, so abnormal usage cannot spiral out of control.

Third safeguard: constrain write operations. If your API allows creating, modifying, or deleting data, the GPT can do so—including by misinterpretation. Build locks directly into the instructions: “Always ask for confirmation before creating a contact in the CRM,” “Never delete data without explicit user validation,” or “Limit modifications to 5 per conversation.” These seemingly innocuous phrases are what separate a minor incident from a trashed database.

One final point, this one regulatory: if you publish a GPT using Actions publicly, OpenAI requires a URL to a privacy policy. It must explain what data is collected via the Actions, how it is processed, and who has access. Without it, your GPT will be rejected from the GPT Store.

Your turn: a complete read-only chain

A dedicated key, minimal access. The best exercise is to build a complete chain under real-world conditions but without risk. Create a developer account on a service with an API—Airtable, Notion, or HubSpot work well—and generate a dedicated token or access key with minimal, read-only permissions. Next, configure API key authentication in your GPT, then test a simple call, such as reading a list of data. Finish with a verification that too many creators neglect: open the service logs and confirm that the calls are indeed coming from your GPT. This habit of monitoring usage will serve you continuously going forward, to detect abnormal behavior or over-consumption before they become a problem.

Official sources: Configuring actions in GPTs (OpenAI Help Center: authentication, OpenAPI schema, testing, limits) · Sharing and publishing GPTs (privacy policy required for public actions)

Key takeaways

• Three authentication modes: none, API key, OAuth 2.0
• Apply the principle of least privilege—request only necessary permissions
• Never put API keys in GPT instructions
• Add safeguards for write and delete operations
• Any action in a publicly shared GPT must have a valid privacy policy URL