Field note
Custom GPT Actions: A Small Business Review
A Custom GPT action is an API integration with a conversational front end. Review it like an integration, not like a prompt.
A Custom GPT action is an API integration with a conversational front end. Review it like an integration, not like a prompt.
What an action is
A Custom GPT is a saved configuration of ChatGPT: instructions, optional files and, optionally, actions. An action is an OpenAPI description of an API. When a conversation calls for it, ChatGPT builds a request from what the user said, sends it to that API, and uses the response to reply. OpenAI's documentation states that parts of the conversation may be sent to the action's endpoint. That single sentence is why this needs a review.
Authentication is set per action in the GPT editor and can be none, an API key, or OAuth. ChatGPT asks the user to allow a request before it is sent. Where an operation is marked consequential in the schema (x-openai-isConsequential: true), ChatGPT always asks and does not offer an "always allow" button. Where the flag is absent, GET requests default to not consequential and everything else defaults to consequential. Requests reach your API from the ChatGPT-User agent.
A realistic example
A small accountancy practice builds a GPT so staff can ask "what is the status of client X" and get an answer from the practice management system. The builder pastes in an API key with full access because that was the key to hand. The GPT is shared with the whole firm by link. Now every person with the link, and any prompt injected into a document they upload, can reach every endpoint that key allows: client records, bank feeds, the lot. The GPT itself is harmless. The integration is wide open.
The review checklist
- Owner. Name who built it and who is accountable for it. A GPT left behind by someone who has left the firm is a live integration with no owner.
- Authentication. Never a master key. Use a key scoped to the endpoints the GPT needs, or OAuth so each user acts as themselves. OpenAI stores the client secret encrypted, but the client ID is visible to users, so treat it as public.
- Data sent. List the fields the schema accepts. Every parameter is a place where conversation content, including uploaded documents, can end up in your API logs or a third party's.
- Read and write separation. Put write operations in their own action with their own credential where possible. Mark every write as consequential in the schema. Do not set the flag to false on a write to make the GPT smoother.
- Always allow. Decide whether staff may use "always allow" on read actions. It is convenient and it removes the one moment where a person sees what is being sent.
- Domains. OpenAI's production notes say that, with a few named exceptions, OAuth domains must match the API domain. Read the schema's server URL and confirm it is the system you think it is.
- Logging on your side. ChatGPT gives you very little. Your API gateway should log each call with the caller, timestamp and endpoint so you can answer "what did the GPT do last Tuesday".
- Sharing scope. Only me, workspace, anyone with the link, or the GPT store. A link is public. A workspace-only GPT is the right default for anything touching business data.
- Third-party GPTs. A GPT from the store with actions sends your staff's conversation content to someone else's API. Read its privacy policy, and treat it as a supplier. Our AI chatbot vendor due diligence note has the questions.
- Kill switch. Confirm you can revoke the API key, remove the action, and unpublish the GPT, and that each step has been tried once.
Limits to design around
At the time of writing OpenAI documents these constraints for actions: custom headers are not supported, request and response payloads are limited to 100,000 characters each, requests time out after 45 seconds, and only text can be exchanged. A GPT that fails intermittently is often hitting the timeout on a slow endpoint or the size limit on a large response. Return compact structured data from the API rather than prose; the model writes the prose.
What IT or the workspace admin should check
- On Enterprise workspaces, whether GPT sharing and action domains are restricted by admin policy; on Team and personal plans, whether anyone is publishing GPTs to the store with company APIs behind them.
- Key rotation: when the key in the GPT editor was last changed and whether it is the same key used elsewhere.
- Gateway logs for calls from the ChatGPT-User agent that hit endpoints the GPT was not meant to use.
- Whether any GPT with actions has been shared by link outside the workspace.
- That the schema is in version control, so a change to it is a reviewed change and not an edit in a text box.
The NCSC's secure AI development guidelines apply the usual system-security rules to AI components: know what is connected, limit what it can do, log it, and plan for compromise. That is the whole review in one line. If you want the access matrix, ownership and stop conditions written up as a control set, an AI governance review is the place to do it.