Investigate AI coding sessions and actions

A workflow for AI Agent Security

When a developer runs an AI coding tool, that tool reads files, runs commands, and reaches the network on their behalf, and none of it appears in a code review. After an incident, "an AI agent did something" is not an answer your security team can act on. This workflow shows you how to pull the record of a session and walk through what the agent actually did.

Scope of this guide

This workflow covers finding a session worth investigating, reading its record, and following it down to an individual action. It does not cover changing what the agent records.

Prerequisites

You have administrator access to the tenant.
At least one developer has run an AI coding tool on an endpoint with the AI Agent Security agent.

Steps

Step 1: Find a session worth opening

Go to Intelligence > AI Sessions.
Check the Findings card first. It counts the actions a policy blocked or audited across the sessions in view, with the number rated High below. A single session with a High finding matters more than a dozen sessions that ran a lot of commands.
Set the time range. 30d is selected by default, so the page opens on a filtered view. Select 90d to reach older sessions.
Select High severity to show only sessions with a high-severity finding, or With findings to show every session with at least one finding.
Select the Exec heading twice to sort in descending order. This surfaces the sessions that ran the most commands, which is usually where the most happened without anyone watching.
Read Repo together with the path below it. A session working in a system directory rather than a project folder is worth opening, whatever its findings count.
Check the MCP and Egress columns for sessions that used more MCP servers or made more outbound connections than the work explains.

Step 2: Read the session record

Select the session to open its details panel. The panel lists the session's findings, where it reached on the network, which MCP servers it used, and which files it touched.
Select Open full session for the complete record, including the transcript, so you can trace a finding back to the prompt that led to it.
Walk through the record in order: the prompts, the files touched, the commands run, the network calls made, and the MCP calls issued.

Step 3: Follow an individual action

On the full session page, open the More actions menu and select View raw events. The Events page opens, filtered to this session.
Select an event to open its details panel. Process ancestry shows the chain of processes that led to the action, Matched policies shows whether a policy matched, and Actor & host shows the user and machine involved.
Note any action where no policy matched. The activity was recorded but not governed, which makes it a candidate for a new policy.

Verify the results

Confirm your security team agrees the record would be usable in a real incident response: that it answers what the agent did, in what order, under whose account, and on which machine.

Confirm the count above the list matches the findings filter and time range you selected. Every narrowing control stays active at once, so a short list may be the result of a filter and a time range rather than a quiet fleet. Duration runs from a session's first recorded event to its last, so a long duration reflects a long span of activity.

Next steps

Open each session with a High finding and confirm which policy fired, and on what.
Select Create policy from this on a finding, or create a policy from an event that no policy matched.
Select 90d to check whether a pattern you found in the last 30 days is new or long-running.