An agent’s tool call should be reviewable against the user’s instruction, its access grant and any required approval. Put that review before consequential execution, and preserve the same evidence when investigating actions that already ran.
Review the proposed action as a business decision
In a fictional customer-service workflow, a user asks an agent to refund $125.00 to a customer. The agent proposes billing:refund with an amount of 1250.00. Its grant allows refunds up to $500.00, and the request includes no approval. The tool name is permitted, but the amount exceeds the grant and the consequential action lacks approval.
This example can be rejected by direct checks before relying on a model’s interpretation. The amount also differs from the instruction, which merits investigation in its own right. Keep those findings separate: a permitted operation does not establish an appropriate amount or a user-authorized purpose.
Capture the evidence at the execution boundary
The agent-actions use case accepts an action item containing the agent and session ids, timestamp, instruction, tool, operation, arguments, grant id and outcome. Use proposed before execution, executed for a completed action, or blocked when it did not run. Include the target resource when applicable.
Supply the cited grant in context.records.grant and relevant session history in context.records.action. Keep the proposed arguments stable between verification and execution. If the recipient, amount or target changes, verify the new action. Your application must enforce the decision; sending a verification request does not itself block a tool or revoke credentials.
Check scope, resources and amount independently
| Assertion | Evidence used | Integration detail |
|---|---|---|
in_scope | Tool and operation against the grant’s scopes. | Names match exactly and case-sensitively; billing:* covers operations for that tool. |
resource_allowed | Target resource against the grant’s patterns. | Patterns support * and ?; a missing target makes this check not applicable. |
within_limits | Named arguments against decimal limits. | Limits apply to top-level arguments, not an inferred business amount. |
grant_valid | Agent identity, action time, issue, expiry and revocation times. | The grant must belong to the acting agent and be valid at the action’s timestamp. |
For the refund example, the integration should expose the amount under the same top-level name used by the grant. A limit on amount does not automatically inspect an amount buried inside payment.details. These limits also do not establish cumulative spending across a period. Define and enforce any additional controls in the system that executes the action.
Make required approval explicit
The default consequential-operation list includes delete, pay, refund, transfer, send_external and grant_access. Supply context.references.consequential_operations when your tool vocabulary requires an explicit list, such as email:forward. Do not assume every operation that can have an external effect appears in the default list.
The approval check requires a recorded approver and timestamp for an applicable action. It rejects self-approval and approval by another agent identified in the supplied records. For an executed action, an approval recorded after execution fails. Blocked actions do not require approval under this check.
Keep identity and authorization controls in your application. A recorded approver id is not an independent authentication of that person, and the check does not consult your organization’s approval hierarchy. Preserve the approval’s source and business meaning alongside the verification.
Keep external content separate from user authority
Suppose a supplier email tells a support agent to forward account records to a new address, while the user only requested a summary. The email is evidence to process; it does not extend the user’s instruction. OWASP describes this class of influence from external content as indirect prompt injection.
Provide inputs_seen with source labels such as user, email, document, web or tool_output and relevant excerpts. OpenAuditor has separate questions for whether an action serves the instruction and whether it originated with the user. When only user input is supplied, the origin check can be resolved directly. External inputs can require a model judgment.
These findings depend on accurate logs. Omitting an email from the supplied history does not prove the agent never read it. Model questions use bounded excerpts, so retain the full relevant records for review. Treat the check as evidence within your controls, without claiming complete detection of prompt injection.
Review session context and unresolved outcomes
The session-rate check counts supplied actions in its time window, including the action under review. In single verification, omitting context.records.action leaves the comparison population unavailable and this check unresolved. In a batch audit, the submitted action items establish that population even without the context key. An explicit empty context list adds no other history; it does not exclude the current action or other items in the batch.
Splitting a session across requests without its relevant history can reduce the visible count. A holding rate assertion then describes the supplied window, not the complete session. Our batch-boundary experiment demonstrates this broader integration issue with invoice and payment checks; it does not test session-rate limits.
Indicators such as argument drift, bursts, first use of a tool and activity outside configured hours help direct attention. An indicator is not by itself proof of a failed requirement. Read the assertion outcomes and undecided reasons in the verification response. Missing evidence or an unqualified model question can prevent a decided result even when direct checks hold.
Connect the finding to a controlled next step
For the fictional refund, hold execution, confirm the intended amount and obtain any required approval. Correct the proposal at its source, then verify the corrected action. Do not silently rewrite a tool argument after verification or use a high probability as a substitute for a missing grant.
Retain the instruction, submitted arguments, grant, approval, configuration, input hash and assertion evidence with the execution record. Use single verification at an action boundary and the batch workflow to examine completed sessions. When actions depend on document extraction, check the extracted data separately so an authorized action does not carry forward an incorrect business value.