Describe the action in plain language

An assistant that finds a customer record is doing something different from one that edits the record. Start by listing the exact actions the proposed agent needs. Use concrete verbs: search, summarize, prepare, update or send. A broad instruction to manage customer support hides decisions that should be made explicitly by the people responsible for that workflow.

Keep proposals separate from execution

Let the agent prepare a draft where that is useful. Show the intended destination, important fields and likely consequence before a person approves an external action. Approval should apply to the specific proposal being reviewed. If the proposal changes, ask for a new review. This avoids turning a general go-ahead into permission for an action the reviewer never saw.

Use limited access at the tool boundary

Instructions in a prompt are not a substitute for actual access restrictions. Give the service only the operations and records needed for its task. Validate tool inputs on the server and check the current user permission for each action. If the agent reads external content, treat that content as information to inspect, rather than authority to grant itself new capabilities.

Keep a usable activity history

Record what was requested, what the agent proposed, who approved it and what the receiving tool reported. Avoid storing unnecessary private content in logs. Include a way to stop pending work and investigate an incomplete action. Test a request outside the permitted scope before launch. It should fail clearly at the tool boundary, even when the assistant produces a convincing explanation for doing it.

An approval card should answer four questions

Test the card with a fictional outgoing message. Read-only lookup, message drafting and message sending should remain distinguishable capabilities. An approval control is useful only when the server checks it against the action that actually runs.

  • What exact action will run, and in which account or system?
  • Which fields or recipients will change, and where did those values come from?
  • What can the reviewer inspect before approving, and what happens if the proposal changes?
  • Which reference can be used to investigate the result or stop pending work?

Translate permissions into rules the tool can enforce

List capabilities as individual business actions

Avoid a single permission called manage support. Break the task into finding an approved record, reading its allowed fields, drafting a response and sending that response. Ask which of those capabilities is actually required for the first version. This list supports both the product design and the server checks. It also helps a reviewer understand why a proposed tool is available. A capability should have a clear purpose, input and result. If one tool can perform several unrelated actions, consider a narrower interface so a request to look something up cannot accidentally become authority to modify it.

Bind an approval to the proposal that was reviewed

Show the target account, recipient or record, the values that will change and the expected consequence. Keep an identifiable version of that proposal. If the agent later changes an important value, the previous approval should not silently authorize the new action. Agree what counts as a material change with the business owner. Test the behavior with a fictional message whose recipient changes after the review. The execution check should reject an approval that no longer matches. This gives meaning to the approval screen instead of treating a general yes as permission for whatever action happens next.

Validate identity and scope on every execution

A tool boundary should check the current user, permitted record scope and allowed operation. Do not rely on the assistant remembering an instruction about restrictions. A model can produce a plausible tool request that the server must still reject. Keep the service credentials limited to the operations the product needs, and avoid placing secret values in prompts, client code or activity messages. When the user access changes, the application needs a way to enforce that change. Describe this behavior in the access design rather than assuming that a successful login permanently settles every later authorization question.

Make mistakes visible and pending work stoppable

Record enough history to investigate the business event

Keep a reference to the request, proposed action, approval and destination result. Distinguish a rejected tool call from one that started and has an uncertain outcome. An operator should know whether to correct a proposal, inspect the receiving system or stop pending work. Avoid retaining unnecessary private message content in logs merely because it might be convenient later. Define who can inspect activity and how long the relevant references remain available. Test an investigation using fictional records: another authorized person should be able to explain what occurred without needing the agent to invent a narrative after the fact.

Frequently asked questions

Can a prompt be the permission system?

No. A prompt can describe intended behavior, but execution controls need to enforce the actual allowed action. Validate requests at the tool boundary even when the assistant sounds certain that the action is appropriate. Test direct requests outside the permitted scope.

Do read-only tools need access checks?

Yes. Reading the wrong record can expose information even when nothing is changed. Define which sources and fields the current user may access, and ensure search and retrieval honor that scope as well as the final displayed answer.

A fictional approval review from start to finish

Imagine an assistant preparing a reply about an equipment request. It can read the permitted request record and draft a message, but sending is a separate operation. The reviewer sees the destination address, the exact wording and a reference to the supporting record. Before approval, they correct an unsupported delivery promise. The application now needs approval for that corrected proposal, rather than reusing permission associated with the earlier text. After execution, the activity record should show the destination response or the unresolved state.

Now change the test so a document the assistant reads contains an instruction to send the message to a different address. That document is source material, not an authority to alter permissions. The sending tool still needs to validate the recipient and the approved proposal. Ask the operator to investigate the rejected attempt using the activity reference. This exercise checks more than whether the assistant can draft a polite reply: it checks whether the product keeps interpretation, authorization and execution distinct when the input becomes misleading.

  • Record the expected recipient and message before the test.
  • Change one important value and confirm the old approval cannot authorize it.
  • Check that the result can be investigated without exposing unrelated records.

Explore related CoreBiz AI resources

The links below connect this guide to the relevant CoreBiz service and project. Check the project page for its current features and access requirements before using the live tool.

Prepared with AI assistance. Business and learning scenarios are illustrative; no customer results, hiring outcomes or performance guarantees are implied.

Discuss a focused implementation

Explore the service scope and share the process you want to improve.

Explore this service