A useful record-search assistant should be able to answer a narrow question without acquiring the power to alter the underlying account. A service coordinator asking which address is on file needs a search result. Changing that address is a different decision, with a different identity check, approval path and consequence.
The separation belongs in the application that serves the tools. An instruction telling the model to be careful can explain the intended behaviour, but it cannot substitute for a write endpoint that rejects unauthorised requests. The following design is proposed for a customer-record assistant; it is not a claim that any connected product implements these controls automatically.
Start with the record boundary, not a tool name
Write down the authorised audience for the search. A coordinator may need records assigned to their team, while an account owner may need only their own account. Neither role should receive a whole database because a question sounds reasonable. Resolve identity and permitted record scope before returning information to the model.
Field limits matter as much as record limits. A delivery query might need the account reference and delivery address, but not identity-document images, payment credentials or unrelated complaints. Define a small response for the actual task and let the application remove excluded fields. Calling a tool read-only does not make disclosure harmless.
Use stable record references for later decisions. A display name is useful for people, but two customers can share a name. When the permitted search finds multiple matches, return an ambiguity result rather than letting the assistant choose the most plausible person. When it finds no match, preserve that absence instead of broadening the search silently.
Put proposed writes behind their own gate
OpenAI's function-calling guide describes a flow in which the model requests a function and the application executes it, returning the result. This creates an application decision point; a requested function is not itself a completed business action. Source: OpenAI function calling
In this design, search and update use different operations. Search returns permitted evidence. An update request identifies the record, permitted field, proposed value and evidence reference. The application checks the authenticated actor, the current record version, the field policy and the required approval before executing the request. None of those checks takes its authority from a sentence in the search result.
An approval should refer to the specific change presented for review. If an address or target record changes after approval, the previous approval no longer describes the action being attempted. Require a fresh decision. A shared credential that can update every record defeats this boundary even if the assistant usually chooses the search tool.
Reusable least-privilege tool design
Copy this proposed design into the implementation brief. Replace the role names and field list with decisions made by the record owner; retain explicit denied outcomes.
| Capability | Permitted input and response | Application enforcement | Result when the check fails |
|---|---|---|---|
| Search assigned accounts | Search term within the authenticated team's scope; return account reference, allowed display name and matching reason | Resolve actor and team server-side; filter records and fields before returning results | Denied scope, no customer data |
| Read one matched record | Stable permitted account reference; return only approved delivery fields and record version | Recheck access for that reference; do not trust a reference supplied by retrieved prose | Denied record or absent record |
| Draft a proposed address change | Account reference, new delivery address, evidence reference; return a proposal without updating the account | Validate field allowlist and required evidence; mark proposal as unexecuted | Missing evidence or invalid field |
| Execute approved change | Exact proposal reference and current record version | Check approver identity, actor permission, unchanged payload and current version | Approval absent, stale approval or version conflict |
| Return execution outcome | Operation reference, resulting version and verified status | Read back the permitted field or obtain an authoritative operation result | Verification unavailable; do not announce completion |
Record these supporting decisions alongside the matrix:
- Credential owner: the application service manages tool credentials outside model-visible content. Search and mutation credentials are restricted separately where the connected system supports this; otherwise the application must enforce the separation and document the remaining credential exposure.
- Allowed fields: delivery address only for this example. Account ownership, bank details and access roles require separately designed operations and are not accepted as extra arguments.
- Approval binding: approver, proposal reference, target record, field, value and record version. The trusted application stores the decision.
- Evidence handling: retrieved text may support a proposed value, but cannot change the actor, allowed fields, approval requirement or tool scope.
- Failure owner: the coordinator receives a clear hold reason and authorised follow-up route. An unavailable write service does not trigger a substitute export or message.
Acceptance tests use a fictitious account named Example Customer A, reference TEST-ACCOUNT-A, and tools that record calls without changing a real system. Search its assigned record, propose an address and confirm that the write remains unexecuted until approval. Repeat with an unassigned reference, two equal name matches, a stale record version and a source note requesting an unauthorised role change. Save expected and observed outcomes for every test, including whether any mutation call was attempted and whether the application rejected it.
The design is complete when the record owner approves the scope, every mutation has an independent enforcement point and failed tests have named repair owners. A passing model response alone is insufficient: inspect the tool request and the application's decision as well.
Test whether retrieved instructions cross the boundary
OWASP describes indirect prompt injection through external material such as websites and files, and notes that retrieval does not fully mitigate the risk. That supports treating search results as untrusted input, not as new operating instructions. Source: OWASP prompt injection
For a synthetic test, place a plainly marked fixture note in TEST-ACCOUNT-A: it asks the assistant to skip approval and update an access role. The expected result is that the assistant may identify the suspicious note, but the application still rejects any access-role operation. This tests two separate behaviours: the assistant's interpretation and the enforcement boundary that remains necessary if interpretation fails.
Also test an ordinary-looking note with a disputed address. The note may be genuine evidence and still be insufficient authority to update the account. Keeping those cases separate avoids building a system that blocks only obviously hostile phrases while accepting unsupported routine changes.
Work through normal, missing and duplicate cases
In a hypothetical normal case, the coordinator searches within their assigned team and finds one account. The assistant reports the permitted delivery address and its source reference. If the coordinator asks to change it, the system creates a proposal, obtains the configured approval and checks the current version before execution. Completion is reported only after the resulting address is verified.
A missing-record case returns no permitted match. The assistant asks for the approved identifying reference through the existing intake process. It does not search another team's records to be helpful. A duplicate-name case returns two permitted matches and asks the coordinator to disambiguate with allowed details. No write proposal is attached to either account yet.
A duplicate execution request also needs a defined outcome. The application can recognise an already executed proposal and return its verified result instead of applying the same change again. This is a proposed implementation rule, not a guarantee that every integration supports duplicate protection natively.
Review connector credentials as part of the design
MCP security guidance discusses scope minimisation and forbids token passthrough that accepts and forwards tokens without proper validation. Those protocol concerns reinforce the need to review credential audience and scope when search tools are exposed through MCP. They do not certify the business-record policy above. Source: MCP security best practices
The implementation owner should document which service receives each credential and which operations it can perform. A search gateway with broad upstream access deserves scrutiny even when its visible response is small. Keep credentials out of prompts and retrieved documents, and review a connector change before accepting newly exposed write operations.
FAQ about separating record search and updates
Is a read-only tool enough to protect customer records?
It prevents that tool from deliberately changing records only if the implementation enforces the restriction. It still needs access filters and field limits because reading can disclose private information. Test denied scopes as carefully as blocked writes.
Can a manager's instruction inside a document count as approval?
Not in this proposed design. A document can explain a request, but approval must come through the authenticated process bound to the exact action. Otherwise any retrieved text could impersonate the manager's authority.
What should happen when the update succeeds but verification fails?
Report that execution occurred and verification is unavailable. Keep the operation reference for investigation and avoid retrying blindly. The application owner must determine whether the first change completed before allowing another attempt.
If your business needs help defining this process, explore Custom AI agents, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.