A Catalog Answer Should Not Be Able to Change an Accession Record
A museum assistant helps staff look up a historical object while the same application also contains tools that can update descriptions and create export jobs. A visitor asking for a date should never cause a write operation just because the model inferred it might help. OpenAI Responses supports a tool_choice option with type allowed_tools that limits which supplied tool definitions can be called for a particular request. It is a control on model tool selection, not an authorization framework for your database. The practical design is to let the model use an approved read-only lookup for a catalog question, require the backend to enforce privileges, and keep edit operations behind a separate authenticated human workflow. Our diagrams show hypothetical records, not live model activity.
Distinguish Available Tools From Tools the Model Can Select
The Responses tools array defines what integrations or functions are presented to a model. The allowed_tools tool_choice configuration names a subset it may use for the current request while retaining a stable larger tools definition. OpenAI describes this partly as a way to preserve tool definitions and improve prompt-caching behavior. The selection can still be narrower than the total list available to the application. Build two logical groups: functions that only search public catalog data and functions that mutate records or access private donor details. For a public inquiry, allow only a safe lookup. Do not place broad administrator tools in the permitted subset and assume a polite system prompt is an adequate defense. The server should evaluate each call even after the model selects it.
Use auto and required for Different User Intentions
With an allowed_tools choice, mode auto permits the model to answer without calling a tool or to call from the permitted subset. Mode required demands that at least one permitted tool be called, but a call is not evidence that the returned record is accurate. An ordinary visitor may ask a general question where auto is acceptable; a staff request for the registered accession number could require a lookup before drafting a reply. Choose the requirement based on the application workflow, not on whether the model sounds confident. OpenAI documents required and auto as tool-selection behaviors, not as database validation or editorial approval statuses. If a required lookup returns no authorized result, the answer should say the record could not be confirmed instead of inventing a match.
Enforce Read-Only Semantics in the Tool Handler
A function called lookup_accession should receive a validated identifier and return only fields the caller is permitted to see. Even with allowed_tools, a compromised or buggy backend could accidentally turn lookup_accession into a broad query that exposes sensitive data. Implement separate read credentials, enforce row-level permissions in the application, validate inputs against a predictable schema, and block unsafe query composition. Do not give public users the ability to provide an arbitrary SQL fragment, index filter or internal object path. Make the tool handler produce a bounded result with an authoritative source ID and revision. The model should not interpret a returned result as permission to publish, correct or alter a catalog field. Approval remains an explicit human decision outside the tool-selection setting.
Compare Three States Instead of One Green Check
In one hypothetical state, the assistant receives a catalog question and is limited to a lookup tool; it retrieves a public object card. In another, a write tool is mistakenly included in the allowed subset even though the user is a visitor. The configuration would then permit the model to attempt that call, so the backend must still reject it. In a third case, the model performs a correct read but the record belongs to a restricted collection; the access layer should filter it out before it reaches the response. These are different failure boundaries. A model-level tool restriction can reduce accidental calls, but it cannot replace user identity, tenant isolation or the decision to release an archival description.
Keep the Tool Definition Stable Only When That Helps
The OpenAI function-calling guide notes that allowed_tools can reduce the need to rewrite an entire tools list across successive requests. The caching guide also describes why stable tool schemas and ordering can matter for reusable input prefixes. This is a performance and maintenance consideration, not a reason to expose unnecessary privileged functions to a public client. If a powerful function is part of a shared definition, do not rely on the model alone to keep it unused; separate services or credentials may be safer. Record the effective tool subset for each request so troubleshooting can establish what the assistant was actually allowed to call. Avoid logging private prompt text when a category and correlation ID suffice.
Test Missing Results, Rejected Calls and Conflicting Records
A useful test suite includes a published object ID, a nonexistent ID, a restricted item, two editions with inconsistent dates, and a request to change an accession note. Confirm that a read-only assistant never reaches the mutation handler even if the user explicitly asks it to. Next, test what happens when the lookup is unavailable, malformed or times out: an absence of evidence must not become a fabricated inventory record. Inspect both the model request configuration and the server’s authorization logs. These are proposed test cases rather than experiments performed for this guide. Treat a rejected call as an expected protection outcome, not as a reason to expand allowed_tools to get the task to pass.
Separate Drafted Answers From Authorized Editorial Changes
The assistant can cite a catalog card and suggest wording for a label. A curator should still review the source revision, rights statement and provenance before publishing that wording. Only an authenticated editorial route should offer write actions, with a distinct request context and a second permission check. Keep the resulting record history versioned so later reviewers can distinguish an AI suggestion from a real catalog correction. In a kiosk, hide private source fields even if the same underlying search system also serves staff. The right success criterion is not that a function executed; it is that the user received the minimum verified public information without being able to change the collection. Review the vendor documentation again before production because API schemas can evolve.
How We Research
For this guide, we reviewed the official product documentation on November 8, 2026: OpenAI Function Calling Guide, OpenAI Responses Create Reference, OpenAI Prompt Caching Guide. We checked the named setting or feature against its published behavior, mapped the documented constraints to the specific hypothetical scenario, and reviewed whether the topic duplicated titles in the supplied LabFin WordPress inventory or prior B0267–B0277 ZIPs. No authenticated vendor service was run; we did not perform a benchmark, observe real customer data, verify third-party rights or claim operational outcomes. All illustrated records and comparisons are teaching examples. Confirm product documentation and security requirements again before implementing a workflow in a real organization.
Frequently Asked Questions
It limits the subset of supplied tools that the model can choose for the request; the backend must still enforce access.
No. It means a permitted tool call is required. Source accuracy and approval require independent checks.
Not alone. Enforce read-only credentials, per-record permissions and strict input validation in the tool handler.
The documented configuration can avoid rewriting definitions across requests and may help reusable prompt prefixes.
Return an unconfirmed or no-result response. Do not claim that a restricted or absent record has been checked.