Represent the actor and the delegator
A support agent may act for a particular employee during a ticket workflow. Carry the agent’s service identity and the delegating employee identity separately. The policy check can then verify the agent’s allowed actions, the employee’s access, and any narrower task constraints. If a service acts on its own behalf, record that fact explicitly.
Use identities and resource claims established by trusted components. Treat role names or customer IDs generated in an agent message as proposed request data. Bind the grant to the tenant and task, and give it an expiry that fits how long the task should run.
Give the decision its own record
A tool response can show that a record changed. A separate authorisation record explains the rule and the scope that permitted it. Use a request identifier to connect the two and capture the actor, delegator, resource, policy rule or version, decision and any approval reference. Include a stable operation identifier when one is available.
Distinguish allowed from executed. An allowed call could time out, fail downstream, or be skipped after a later check. A denied call should never have a downstream execution record. If execution is ambiguous, keep that status visible until the outcome can be reconciled.
Keep the record useful during an incident
Start with the questions an engineer needs to answer. Which principal was involved? Did the request match the original task? What policy was in force? Did a reviewer intervene? Store enough detail to answer those questions while excluding access tokens and unnecessary customer data.
Test the trace with an allowed request, an out-of-scope request, and a request approved by a reviewer. Reconstruct each outcome from the records alone. If a shared service identity makes two actors indistinguishable or the downstream outcome is missing, close that gap before depending on the audit trail.
Track changes to grants and policy
A decision record is easier to interpret if it points to the policy version and grant that were in effect at the time. Include a stable reference to each, and keep change history available for the same operational window. During a policy rollout, sample equivalent requests under the old and new versions so an unexpected change in allow or deny behaviour can be traced to a specific revision.