# Give an agent a small tool, not an administrator console

A useful agent capability describes a business operation with clear limits. General administrative access makes mistakes harder to contain and results harder to explain.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Begin with one permitted change

Consider an assistant helping staff update delivery instructions. It needs to add a note to an open order. It does not need permission to alter prices, change the customer or cancel the order. A general order-update endpoint may expose all of those fields even when the prompt describes a narrower task.

Create a tool around the permitted operation: add a delivery note to an eligible order. The server loads the order, checks the caller's access and verifies its state. It constructs the allowed change instead of forwarding a generated object into a broad update API.

This boundary is useful even when the model behaves well. It gives engineers a small contract to test and lets support explain exactly what an agent was capable of changing.

## Keep identity and limits outside generation

Resolve the user and organisation from the authenticated session. Load the target's ownership and current state from trusted records. A model-supplied organisation identifier is an input to validate, not evidence that access is permitted.

Limit note length, target count and the number of mutations in a run. Where the operation requires approval, bind the decision to the proposed note and order version. A general instruction to "be careful" cannot substitute for these checks.

### A bounded order tool

The application turns a narrow proposal into an authorised change and returns a recorded result.

1. **Propose note**: Order identifier and delivery text only
2. **Check eligibility**: Caller access, order state and field limits
3. **Commit operation**: Apply once using a durable operation identifier
4. **Report result**: Return the recorded status and changed version

## Design the uncertain result

A downstream timeout does not reveal whether the write happened. If the tool simply returns "failed", the agent may submit the same note again. Use an operation identifier and a downstream idempotency contract where available, or reconcile the target state before deciding whether to retry.

An operation record should distinguish rejected, pending, completed and uncertain outcomes. The assistant can then tell the user that a change is still being checked rather than claiming failure and starting a duplicate action.

Do not rely solely on the conversation to remember completed work. A restarted process or compressed transcript can lose that information. The business operation needs durable state outside the model context.

## Expand only when the next task is understood

A narrow tool may initially require more implementation work than exposing a generic API. That cost buys a smaller authority surface, clearer validation and better recovery. It also reveals when two tasks genuinely have different approval or access requirements.

Add another operation when a real workflow needs it, then review how it combines with existing tools. A read operation and a write operation can together create a capability neither suggests in isolation. Keep the tool set aligned with the work users intend, and make each effect traceable to an authorised request.

## Sources

- [OWASP: authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [AWS Builders' Library: idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)