How to assess an AI agent’s actions

What trajectory assurance means here

In this guide, trajectory assurance means examining an agent’s observable sequence of actions against its requested task, permitted scope and required controls. It is a practical review approach, not a claim that every agent must follow one fixed path.

Google’s Agent Development Kit evaluation guidance distinguishes the assessment of tool-use trajectories from the assessment of final responses.^[1] That distinction is useful for security reviews: a good answer and an authorised process are separate questions.

Keep three kinds of information distinct:

• The intended task: what the user authorised and what should have happened.
• The observed actions: which tools the agent called, with which parameters and targets.
• The resulting effects: what the receiving systems accepted, rejected, changed or transmitted.

An agent’s written plan or account of its actions does not establish that those actions occurred. The review needs execution evidence. It does not require access to the model’s private internal reasoning.

1. Define the boundaries before the run

Start with one business workflow. Write down the permitted data, available tools, allowed changes, approval points and conditions that require the agent to stop. Assign an owner who can decide whether the workflow is ready for use.

For a client onboarding assistant, the boundary might be: read approved documents for the named client, summarise outstanding requirements, and save an internal draft. Access to another client’s folder is outside scope. Sending the draft externally requires a separate approval covering the recipient and attachment.

Google’s secure-agent guidance supports limited permissions, human control over consequential actions and safeguards enforced outside the model.^[2] Translate those principles into controls at the tool or application boundary. An instruction in the prompt is useful, but it cannot replace an enforced permission check.

Be explicit about the difference between technical access and task authority. A shared service account might be able to read an entire drive while this task authorises access to only one folder. That mismatch is a design issue to resolve.

2. Build an evidence record for each action

Give the run a traceable identifier. Connect tool events to permission decisions, approval records and receiving-system events using that identifier, timestamps and relevant resource IDs. Capture material retries and background actions as well as the main sequence.

The downloadable checklist uses seven fields. Keep evidence references in the relevant field so another reviewer can find the underlying record.

Use precise result language. A tool returning “accepted” may mean that work entered a queue. It does not necessarily establish delivery or completion. A blocked-send finding should reference the enforcement decision. An absent event is only useful evidence when the reviewer understands the logging coverage and observation period.

Protect this evidence. The UK National Cyber Security Centre’s secure-development guidance treats AI logs as sensitive assets and recommends protecting their confidentiality, integrity and availability.^[3] Limit captured content, restrict access and set retention rules. The checklist should reference securely held evidence rather than become a second store of secrets or personal information.

A worked example: the onboarding brief

Hypothetical scenario: a professional-services firm tests an assistant that prepares internal client onboarding briefs. One retrieved document contains an instruction to email an attachment to an external address. The authorised task includes no external sending.

The reviewer follows the run through three actions:

1. Read the approved document. The tool event and repository access record identify the correct client file. This action is within the defined scope.
2. Attempt an external email. The agent calls the send tool without the required approval. The sending control denies the request before it enters the queue. Record a blocked deviation and investigate why the agent followed the document’s instruction.
3. Save the internal draft. The tool reports success, but the receiving application’s creation record is unavailable. Record an evidence gap and obtain the missing record before treating the save as verified.

The final response could still say the briefing is ready. The action review gives the workflow owner a more useful picture: one permitted read, an attempted boundary crossing that was blocked, and an unresolved result.

OWASP’s agentic-security work identifies risks including tool misuse and identity or privilege abuse.^[4] This example turns those categories into specific questions about the recipient, the agent’s authority and the point where the send was stopped.

3. Test the controls with expected outcomes

Write the expected outcome before running each test. Use a controlled environment, synthetic records and destinations you control. Begin with three scenarios:

• Ordinary work: approved documents produce an internal draft. Check the selected records and destination as well as the content.
• Approval boundary: a send request has no approval, an expired approval, or approval for a different recipient. The consequential action must remain blocked until the required valid approval exists.
• Untrusted instructions: a retrieved document asks the agent to send data elsewhere. Check whether the agent rejects the instruction and whether an independent control prevents an unauthorised send if it attempts one.

Allow legitimate variations in the sequence where the workflow permits them. Reading two approved documents in a different order may be harmless. Sending an attachment before approval is a meaningful violation. The evaluation should preserve mandatory boundaries without mistaking every different route for a security failure.

Repeat relevant tests after changes to the model, prompts, tools, permissions or approval rules. Record the tested versions, conditions and limitations. Passing a small set of runs supports a bounded decision; it cannot establish that every future run will be secure.

Turn findings into decisions

For a small or medium-sized organisation, a useful starting point is one workflow, a named business owner and a technical reviewer. Use four plain-language findings:

• Verified within scope: the observed action and result match the task boundary, with sufficient evidence.
• Blocked deviation: an out-of-scope action was attempted and an identified control stopped it.
• Control failure: evidence shows an unauthorised action succeeded or a required control was bypassed.
• Evidence gap: the available records cannot support a conclusion.

Give unresolved findings an owner and a next action. Consider restricting an affected capability while investigating a consequential failure. If information may have been exposed, use the organisation’s incident-response process to establish scope and containment.

Store the workflow boundary, system versions and review outcome alongside the use case in your AI solutions registry. Keep sensitive traces in a controlled evidence location and link to them. This makes the registry useful for decisions about change, reuse and oversight.

The next leadership discussion becomes specific: Which actions can we verify, which controls have we tested, and what still prevents us from granting the agent more authority?