Build the request from trusted facts
Authenticate the agent and resolve the principal it represents. Take tenant and delegated grant claims from a trusted source, then validate the proposed tool arguments against a known action and schema. Agent text may propose a customer ID, but it cannot grant access to that customer.
This example shows a conceptual input. An implementation must verify the values before using them to decide.
{
"actor": "support-agent",
"delegatedPrincipal": "staff-42",
"task": "ticket-1042",
"action": "crm.read_customer",
"resource": {
"tenant": "tenant-7",
"customerId": "cus_1042"
}
}Define explicit outcomes
Start from deny by default. An allow rule should match the identity, action and resource within the delegated grant. An approval-required rule should stop execution and produce a review request. In a design with overlapping rules, specify which decision wins and test that precedence.
For a support ticket, allow a read for the assigned customer within the ticket’s tenant. Deny an unknown tool, expired grant or cross-tenant target. Keep the grant as narrow as the task allows.
Check the boundary cases
Test missing and unexpected arguments, request fields that disagree with trusted claims, and a resource that changes ownership before execution. Define how the executor handles unavailable policy data. For privileged operations, hold execution when it cannot establish authorisation.