Build an explicit approval boundary before an agent tool runs

An agent can propose a tool call without having permission to execute it. This distinction matters when the tool sends a message, changes a record or spends money. Put the decision in application code and bind approval to the exact action; do not rely only on a prompt that asks the model to behave.

Scenario

Illustrative lab: an assistant proposes a payment action. The application checks both an approval decision and a maximum amount. No real payment API is used.

Worked example

Standalone Node.js JavaScript policy demonstration. No LLM, credentials, network calls or payment operations required.

function authorize(action, approval) {
  if (action.type !== 'payment') return 'unsupported';
  if (!Number.isInteger(action.amountPaise) || action.amountPaise <= 0)
    return 'invalid_amount';
  if (!approval || approval.actionId !== action.id || !approval.approved)
    return 'approval_required';
  if (action.amountPaise > approval.limitPaise) return 'over_limit';
  return 'allowed';
}
const action = {id: 'demo-1', type: 'payment', amountPaise: 5000};
console.log(authorize(action, null));
console.log(authorize(action, {actionId: 'demo-1', approved: true, limitPaise: 4000}));
console.log(authorize(action, {actionId: 'demo-1', approved: true, limitPaise: 6000}));

Expected output

approval_required
over_limit
allowed

Walk through the code

1. Reject unsupported action types before evaluating approval.
2. Use integer smallest-currency units in the toy example and reject invalid amounts.
3. Require a positive approval tied to the same action identifier.
4. Compare the approved limit with the proposed amount. Return a decision; this function deliberately does not execute a payment.

Reason about the design

This small function demonstrates a boundary, not a complete authorization system. A production service must load approval from trusted server-side storage, bind it to immutable action parameters and the authorized user, enforce expiry and single-use rules, and recheck permissions at execution time. A browser-supplied approved flag is not trustworthy. The action identifier alone is insufficient if an attacker can change the recipient while retaining that identifier.

Common mistakes

• Treating model-generated approval text as a human decision.
• Putting an irreversible side effect before a workflow pause and repeating it when the workflow resumes.
• Retrying a timed-out external operation without an idempotency key or a reconciliation check.

Troubleshooting checklist

• Trace the exact action parameters that were proposed, approved and executed. Redact secrets from logs.
• Check replay behaviour: the same approved action should not produce repeated external effects.
• Test changed recipients, expired approvals, rejected actions and permission changes between approval and execution.

Try it yourself

Add trusted approval expiry and an action fingerprint to a test-only version. Change the recipient after approval and make the test reject the request. Keep real API calls out of the unit test.

Interview follow-up

How do you prevent a resumed workflow from repeating a previously completed external action?

Questions learners ask

Does human approval eliminate all agent risk?

No. Reviewers need understandable parameters, and the execution service still needs authorization, validation and replay protection.

Where does LangGraph fit?

Its interrupt mechanism can pause a workflow for input. Application-level permission checks and safe handling of side effects remain necessary.

Primary reference

Official documentation for this topic. Check the documentation for your deployed product version before applying the example.