Sandboxing Appeal Tools So the Agent Reads but Cannot Move Money

Write the model on one page before writing the tools. Tier 0 is the agent's own loop: it plans, reads, and writes recommendations. Tier 1 is the small set of tools it can call directly, each with narrow arguments and no side effects outside the case record. Tier 2 is data it can only read, through credentials that cannot update or delete. Tier 3 is a separate payout service the agent has no credentials for at all.

The model is a direct application of autonomy boundaries: a definition of what an agent may do independently, what requires human approval, and what it must never do, with access policies enforcing those boundaries and access denied by default MongoDB's governance course on autonomy, identity and access. The same source's LeafyBank example is a usable decision rule: lookups and small refunds can be delegated, refunds above a threshold route to a specialist, and actions like changing a stored payment method or closing an account remain human-only. Copy the thresholds, not the numbers.

Two scoping rules keep Tier 1 honest. First, cap each tool's arguments to the case in hand: fetchOrder takes an order ID already on the case, not an arbitrary customer ID, so the agent cannot enumerate the customer base even when injected with a tempting instruction. Second, split read and write for the same resource into different tools, because an agent allowed to look up an order should not automatically be able to modify billing information just because both functions sit behind the same API MongoDB.

A third rule is cheaper than it sounds: give the agent its own identity. Agents should authenticate as distinct principals rather than reusing user sessions or long-lived API keys, with capability-based scopes narrowing tokens to specific verbs on specific resources WorkOS on AI agent access control. When an appeal goes wrong, you revoke one principal and the rest of the support floor keeps working.

Keep the tool surface small enough to list in a design review. A workable set for appeal review:

• getCase(case_id): returns the appeal, the order, the customer's masked profile, and the policy version in force.
• fetchOrder(order_id): order lines, delivery events, and refund history for the one order on the case.
• getPolicyRules(vertical, effective_date): the rule set, read-only, versioned.
• getPriorAppeals(customer_id, limit): the last N decisions for this customer, with outcomes.
• draftDecision(case_id, outcome, amount, rationale, evidence_refs): writes a structured recommendation to the case, changes no money.
• submitForApproval(case_id): moves the draft to the approval queue and stamps the agent identity, model, prompt version and timestamp.

That is the whole loop. Notice what is missing: no issueRefund, no updateOrder, no sendEmail. Every one of those would widen the blast radius of a single successful injection, which is the failure mode that permission misuse describes, namely an agent reaching beyond its intended scope with no access review catching the overreach Dataiku on human-in-the-loop design patterns.

Above several hundred cases a day, a second opinion from a different model is cheap. Route the appeal text and the draft rationale through a summarizer model and through a different vendor's model, so that an injection tuned to one tokenizer's quirks has to beat two independent readers. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key (https://quantaintelligence.ai/inference), which makes the second-reader pattern a configuration change rather than a second procurement cycle. Keep the cross-check advisory: the approval decision stays with the human, not with the second model.

Tool descriptions are part of the attack surface too. A connected MCP server's tool description is untrusted input, and an agent that trusts it can be steered by whoever wrote it Bridewell. Pin tool descriptions in your own repo, hash them, and fail the deployment if the hash changes without a review.

Sentences in a system prompt are not access control. The database has to enforce the scope, so that authorization narrows every request to the current customer or tenant and the data service refuses anything wider, with no path to read another customer's data even through a badly formed query MongoDB.

Start with a dedicated role, a dedicated user, and a set of views rather than tables.

-- Read-only role for the appeal agent's data path
CREATE ROLE appeal_agent_ro;
GRANT USAGE ON SCHEMA appeals, orders, ledger TO appeal_agent_ro;
GRANT SELECT ON appeals.v_agent_case, orders.v_agent_order,
                ledger.v_refund_history TO appeal_agent_ro;
-- No INSERT, UPDATE, DELETE, TRUNCATE or sequence grants.
-- Row scope is enforced by a policy function, not by the prompt.

Three implementation details decide whether this holds.

Row-level security, not query etiquette. Attach a policy to each view that filters on the customer or tenant carried in the request context, so the agent physically cannot retrieve rows outside the case. If your store supports it, set the scope in the session and let the engine enforce it.

Masked columns in the view, not in application code. The agent usually needs order facts and refund history, not full card numbers or home addresses. Strip them at the view layer and the question of what the model saw becomes answerable from schema.

Short-lived credentials. Prefer minute-scale token lifetimes and just-in-time issuance over long-lived secrets, and track every cache where a credential might persist WorkOS. A read-only key is still a key: if it leaks, an attacker gets a mirror of your customer table, so rotation belongs in the same sprint as the role.

Then test the boundary adversarially. Run injection payloads in an isolated sandbox with synthetic data, mock tools and logging stubs that record what the agent would have done, and judge success on whether injected text reaches a tool call, not on whether the model produced unsafe prose Sweet Security's prompt injection guide. Add a test that asserts the read-only role has no write grants, so a migration cannot quietly widen it.

The payout service is the only component that can move money, and it should be boring, small and slow. It exposes one endpoint, executeApprovedPayout(approval_id), which looks up a signed approval record and executes exactly what that record says. It does not accept amounts, payees or reasons from a caller, so there is nothing for an injected agent to influence.

Payout execution, ordered steps
1. Receive approval_id only.
2. Load approval record; verify signature and status = APPROVED.
3. Check the record has not expired and has not already been executed (idempotency key).
4. Compare requested amount to the policy ceiling for that vertical.
5. Re-resolve the beneficiary and payment instrument from master data.
6. Execute through the payment provider.
7. Write the result, provider reference and reviewer identity to an append-only log.
8. If any check fails, refuse and alert the review channel.

Step 5 matters because an approved record can still be turned into a payment to the wrong account if the beneficiary is taken from text someone typed. Resolve it from master data you control.

The approval record itself should capture the originating actor, the agent identity, the requested action, the case, the reviewer, the decision and the policy basis MongoDB. Evidence of human review means logs showing who reviewed, what context they saw, what they approved or rejected, when escalation occurred, and which identity the agent used; an audit trail should prove the review happened before execution Sweet Security on human oversight.

Choose the oversight pattern deliberately. Interrupt-and-resume pauses the agent at a predefined point and hands the human the proposed action with the context behind it, plus authority to approve, modify or reject; approval flows and fallback escalation cover exceptions Dataiku. For appeals, use a queue rather than a pause, so a reviewer's lunch break does not hold a worker process open.

The numbers that justify the design are simple. If your median appeal is a $40 credit and 2 percent of appeals carry injected text, a single successful payout to an attacker-controlled account costs more than the manual review time saved on the other 98 percent. That trade is why human approval belongs on the money, and why the agent's value sits in the drafting.

Human approval is a control only when it is rare, specific and backed by enforceable limits; telemetry on approval behavior suggests most confirmation designs fail that test Bridewell. A queue where reviewers click approve 400 times an hour is theater with an audit log attached. The same failure is described in the governance literature: if a support representative clicks approve on every request without checking the amount, customer, reason and evidence, the organization has created the appearance of oversight without the benefits MongoDB.

Four mechanics keep approval honest.

Draft quality over queue volume. The recommendation should carry the case facts the reviewer needs: order value, delivery evidence, policy clause cited, prior decisions, and the agent's confidence with the passages it relied on. If the reviewer has to open three systems, they will stop opening them.

Banding by amount and risk. Low-value, standard-outcome drafts can move to a sampling queue with post-hoc review. Unusual amounts, account changes and any case where the agent's draft diverges from policy go to named reviewers with the authority to reject. The pattern mirrors arrayed oversight: people do not watch every step, but they must be available at defined decision points with enough context to act quickly Menlo Security on agent oversight.

Separation of duties. The person who tunes the agent's prompts should not be the person who approves its production payouts, which is one of the five elements the governance literature lists for governed human-AI collaboration Dataiku.

Measurable approvals. Log time-to-decision and the rate of edits to the agent's draft. A reviewer who changes the amount 30 percent of the time is telling you the extraction or the policy retrieval is wrong. A reviewer who never changes anything in a month is a signal to re-train or re-band, not a sign the agent is perfect.

For teams that want the review layer built rather than assembled, an expert that reads case context and hands back a finished decision pack is a natural fit; Quanta Experts at https://quantaintelligence.ai/agents is one route, provided the payout credentials stay outside it.

Three operational controls determine whether the sandbox survives contact with production.

Revocation you can actually perform. The most important control when something goes wrong is the ability to terminate an agent's access across all connected systems at once, without a per-account manual sweep Ninth Wave on agent access control in banking. Practically, that means one registry of agent identities and scopes, one revocation call, and a quarterly drill where you kill the agent mid-queue and confirm the approval path still works for humans.

Limits and circuit breakers. Agent identities should have rate limits, spend caps per period, and circuit breakers that trip on unusual volumes or off-pattern requests, and authorization decisions should be context-aware and expressed as versioned, testable policy WorkOS. A payout ceiling enforced in the payout service, not the agent, is the version that survives an injection.

A test suite built from transferred attacks. Because winning injection techniques transfer across domains, your regression set should include plausible-pretext one-liners, fake pre-approval memos, and encoding tricks, run against your actual tool schemas in a sandbox Lambda. Assert on tool calls, not text. A draft that says "recommend full refund" is a normal outcome. A createRefund call is a bug that should fail the build.

Finally, expect the review step to move human attention to higher-consequence moments as routine drafting is automated, and staff for that rather than for volume Menlo Security. The reviewer's job changes from assembling facts to judging intent, which is exactly the judgment a permissions model cannot encode.