Trusted action gates for retrieval-assisted answers

Last updated: 7 Oct 20265 min read

tutorial

A model can propose an action after reading a document. A separate application gate must check user authority and scope before any side effect.

Take authority from the request

An authenticated operator may ask the assistant to summarize a runbook. A retrieved runbook cannot expand that request into sending logs or changing a service. Represent user-approved operations, target service and data scope in trusted application state. A model proposal is an untrusted suggestion until an action broker checks those fields. Retrieved-text boundaries keep document content available as evidence without promoting it into a permission source.

Bind target and arguments

Checking the action name alone is insufficient. “Open incident 47” and “export every incident” may use the same tool with different scope. Validate action, target ID, destination, data classification and maximum volume against the authenticated request. Require explicit user approval for a side effect when policy says so. The broker should fail closed if a required field is missing or if a proposed argument was sourced only from retrieved text. Preserve the decision and evidence IDs for audit.

Separate answer generation from execution

A runbook answer can describe a command without executing it. Keep read-only generation and effectful tools in separate paths. If the model output contains a command, render it as quoted source material or a proposed plan for human review. Do not parse arbitrary natural language back into a tool call without a typed request. An attacker can hide instructions in a document, search result title or translated snippet, so the same gate must cover every retrieval route.

Test the gate under change

Run cases where an injected passage requests a different target, an external destination or a larger data scope. Also test legitimate user-authorized actions to avoid a gate that blocks everything. Report unauthorized execution count, false denials and missing audit records by source type. The retrieval boundary project checks the full answer-and-action path after document and model updates.

Implementation

def authorize_proposal(proposal, trusted_request):
    required = {"action", "target_id"}
    if not required <= proposal.keys():
        return {"state": "deny", "reason": "missing-fields"}
    if proposal["action"] != trusted_request["user_requested_action"]:
        return {"state": "deny", "reason": "user-intent"}
    if proposal["action"] not in trusted_request["capabilities"]:
        return {"state": "deny", "reason": "capability"}
    if proposal["target_id"] != trusted_request["target_id"]:
        return {"state": "deny", "reason": "target-scope"}
    return {"state": "eligible-for-approval"}

request = {"user_requested_action": "summarize-runbook",
           "capabilities": {"open-incident"}, "target_id": "incident-47"}
proposed = {"action": "open-incident", "target_id": "incident-47"}
assert authorize_proposal(proposed, request)["reason"] == "user-intent"
request["user_requested_action"] = "open-incident"
assert authorize_proposal(proposed, request)["state"] == "eligible-for-approval"

Performance and operating cost

For a fixed set of fields, the gate is expected O(1) time and space. A real broker also checks authentication, destination, data volume and user approval, which may require database or policy lookups. The returned eligible state is not execution; an application must complete its own approval and audit process.

Common Mistakes

Accepting tool arguments solely because a model emitted valid JSON.
Checking the action name while ignoring target and data scope.
Treating a retrieved document as user approval.
Equating a proposed plan with permission to execute it.