Make consequential agent actions accountable

Separate evidence from authority in an invoice workflow

Suppose an assistant reads supplier invoices and prepares payment records. An invoice asks it to replace the supplier's bank account. The assistant can extract that request into a draft, but the invoice does not authorize a change to the payment destination. The proposed change still needs the established verification process.

Follow the full path: external document → retrieval and model context → proposed action → policy enforcement → business system. Whether the model interprets the invoice correctly or incorrectly, the change must encounter the same authorization check. A prompt warning can influence the model. The business system still needs to enforce permission outside the model, before the destination changes.

Record the authority exposed by each tool

Inspect the operations and credentials actually exposed by direct APIs, MCP servers and local execution. Record each operation's enforced limit and the evidence that will show its outcome. Revisit this when a tool version adds capabilities. An old description may no longer account for what the tool can do.

Observe enforcement through the complete action

In a test environment, place conflicting instructions in a retrieved document. Check whether the consequential operation is denied when authority is absent. Repeat through a tool result and stored memory, then check ordinary authorized work. A system that rejects everything is not a useful solution. The comparison should show both effective enforcement and which input paths were tested.

Approval must refer to the exact action and arguments that will execute. If the amount or destination changes, obtain a new decision. Check tenant scope and authorization at execution time, and enforce the agreed limits on runtime, tool calls, retries and spending. After a timeout, reconcile an uncertain result and use idempotency to avoid duplicates. An unknown outcome is not permission to perform the same action again.

Connect the request and relevant evidence to approval, execution and the observed result in the audit record. Also test whether credentials can be revoked and outstanding work stopped. Keep enough information to explain what happened without putting unnecessary secrets in the traces.

Describe the tested combinations and their limits

OWASP's 2026 LLM list includes prompt injection, excessive agency and other application risks. Use it to inform test selection; it does not certify the system. Passing one injection case establishes behavior under that case's conditions. Other instruction paths and permission combinations remain separate work.

Record excluded tools, untested combinations and decisions that rely on a human process. A change to the model, tool description, credentials, retrieval or memory can alter how an input reaches an action. Review the affected authorization check when that happens. An earlier result remains useful only where its assumptions still apply.