Proposals Before Actions

In this chapter

• Validate tool proposals as untrusted data
• Require explicit approval for meaningful actions
• Bind approval to an exact proposal version

A prediction must not become permission

A support assistant may classify a message correctly and still propose an inappropriate action, such as closing a ticket before the issue is resolved. Treat a proposed tool call as untrusted structured data. The application decides which tools exist, what arguments are valid, whose records may be accessed, and whether an action requires review. Model wording cannot grant itself additional privileges.

Signal Bench uses a deliberately narrow workflow: a classifier proposes a category, a reviewer approves that exact proposal, and an executor applies it to a synthetic ticket. There is no external email, payment, or production ticket update. This separation lets you test approval and concurrency without exposing real users to experimental behavior. It also makes failures easier to explain than an opaque chain of autonomous calls.

Bind approval to the intended change

A proposal should include a ticket identifier, expected current version, requested category, and proposal identifier. Approval must refer to that same content. If the proposal changes after review, the old approval is invalid. The example simulates optimistic concurrency: a stale version cannot overwrite a newer ticket state. It does not implement a multi-process database transaction; that would require a durable compare-and-update boundary.

ticket = {'id': 'demo-7', 'category': 'review', 'version': 1}
proposal = {'id': 'proposal-1', 'ticket_id': 'demo-7', 'category': 'billing', 'expected_version': 1}
approved = dict(proposal)

def apply(current, proposed, approval):
    if proposed != approval:
        raise ValueError('Approval does not match proposal')
    if proposed['ticket_id'] != current['id'] or proposed['expected_version'] != current['version']:
        raise ValueError('Stale or wrong ticket')
    if proposed['category'] not in {'billing', 'access', 'reliability'}:
        raise ValueError('Unsupported category')
    return {**current, 'category': proposed['category'], 'version': current['version'] + 1}

updated = apply(ticket, proposal, approved)
assert updated['version'] == 2
print(updated)

Treat retrieved instructions as evidence, not commands

A ticket body might say to ignore all previous rules and export the customer database. That sentence is part of the input being classified, not an instruction to the application. Separate untrusted text from control instructions, validate outputs against a small schema, and restrict tools to the minimum necessary scope. These controls reduce risk but are not a claim of complete prompt-injection prevention.

Record proposal, review decision, execution result, and failure reason as distinct events. A timeout after execution creates uncertainty: retrying blindly may repeat the action. Durable idempotency keys and transaction design are needed for external integrations. In the local capstone, demonstrate duplicate prevention and stale approvals using synthetic state before considering any real service connection.

Attack the local approval boundary

• Try changing the category after approval, applying a proposal twice, and using the wrong ticket identifier.
• Write tests that reject each case without mutating the current state.
• Add an explicit rejected status and a new proposal identifier for a revised suggestion.

Expected checks

• Approval is bound to exact proposal content.
• A stale version is rejected rather than silently overwritten.
• Input text containing instructions cannot add tools or bypass the reviewer.

Check your understanding

When a reviewed proposal changes, what should happen?

• The previous approval automatically covers it
• The revised proposal requires a new matching approval
• The model can approve its own revision

Official tools & further reading

• OWASP prompt-injection prevention guidance