# Review the tool schema against the business rule

A typed tool can still expose too much authority. Compare every accepted field and side effect with the operation the user is actually permitted to request.

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

## Read the schema without the prompt

Ask a reviewer to infer the tool's power from its input contract and executor. A delivery-note tool should not accept price, customer ownership or order cancellation fields. If it accepts an arbitrary update object, its authority is broader than its friendly name suggests.

Check unknown-field handling, collection limits and target identifiers. A schema that validates string types but accepts unlimited targets can turn a small task into a bulk operation. Limits should reflect the business use, not merely the parser's capabilities.

The prompt may explain intended behaviour, but the review should establish what the code actually permits when the generated arguments are wrong.

## Follow the target into trusted state

Inspect how caller identity is obtained and how ownership is verified. Look for fields supplied by the model that are incorrectly trusted as proof of organisation, role or approval.

Check the eligibility rule at the time of mutation. An order can move from open to dispatched after the proposal was generated. The executor needs a concurrency rule that prevents stale checks from authorising an inappropriate change.

Ask what happens when the caller has read permission but lacks mutation permission. This case often exposes overly broad access helpers reused across different operations.

## Examine result and retry contracts

The tool should return a recorded status that distinguishes denial, completion and uncertainty. Review whether a timeout can lead to a fresh operation identifier and a duplicate effect.

Inspect idempotency scope, payload matching and retention. A repeated identifier with changed arguments should not silently return a misleading result or execute a new action under an old approval.

Review output fields too. The executor may enforce the write correctly while returning an entire sensitive record that the task did not require.

## Require one complete failure demonstration

Choose a lost response after commit, a stale target version or a cross-organisation identifier. Run it through the executor and inspect the target state and operation record. A diagram alone cannot show that these rules are enforced.

Finish with the capability inventory. Identify any alternate tool that can perform the same effect with weaker checks. The review should leave a clear account of the permitted mutation, its authority checks and its recovery behaviour, so future schema changes can be assessed against a concrete baseline.

## 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/)