See what one person's agents are doing

Most investigations start with a person, not an event. Someone's Claude Code is burning tokens, someone's agent tripped a policy, someone left the company and you need to know what their agents still reach. Users under Agent Security in the sidebar is the surface pinned to that question: a list of everyone in the organization, and a per-person page that scopes every chart to them.

The page needs the view_users permission. Without it, the nav item doesn't appear.

The Users list

The list shows every user the gateway knows about, with Name, Email, Groups, and Created. Sort by name, email, or creation date; search by name; filter by Group to see one team at a time. Clicking a row opens that user's page.

You'll also arrive here from elsewhere: the Top Users table in Analytics, and any user's name in Agent Trail, Agent Instances, or an Agent Registry detail page, all link to the same per-user page.

The per-user page

The header carries the person's display name, email, group badges, and the date-range picker that drives everything below it. Five stat cards summarize the selected period, each with a comparison against the previous one:

• Agent Instances — how many of their clients were active
• Tool Executions — how many calls those clients made
• Total Tokens and Total Cost (USD) — what their LLM usage cost, from agent telemetry
• Models Used — how many distinct models they touched

Three tabs go deeper:

• Overview — a Recent Activity feed of that user's audit events, plus their agent instances (agent, runtime, and when each was created). Click through to any instance for its identity and history.
• MCP Usage — tool executions over time against the previous period, an hourly distribution, and their Top Tools, Top MCPs, and Top Agent Instances.
• LLM Usage — tokens and cost over time, a token breakdown, session metrics, Top Models by Tokens and Top Models by Cost (USD), and the individual sessions behind the totals.

How this differs from Agent Trail

Agent Trail is the org-wide event stream: every action, newest first, with chips to narrow it down. It answers what happened. The Users page answers who — it starts from one person and pre-scopes the analytics, the instance list, and the activity feed to them, so you don't rebuild the same filter every time. When a per-user chart raises a question, Agent Trail is where you read the underlying events, including the policy decision on each call.

Where users come from

The gateway doesn't create users, and there is no invite flow. A user appears here the first time someone signs in — whether they came from your workspace's identity pool or a federated directory: the gateway provisions them from the token, keyed on the external ID the issuer sends. Display name, email, and group membership are refreshed from the claims on subsequent requests, so the list tracks identity upstream rather than drifting from it.

Groups

Groups arrive the same way — straight from the IdP claims on each user — and the gateway records the names it sees. They do two jobs:

• Policy scoping. Scope a rule to a group so it applies to everyone in it, current and future members alike. See Policies for the Group subject and the user.groups CEL condition.
• Filtering. The Group chip narrows the Users list, Analytics, and Agent Trail to one team.

Because membership comes from the IdP, a group-scoped policy follows your directory: move someone into the contractors group there and their agents pick up the contractor rules on their next request. The gateway has no group editor of its own.

Next steps

• Policies — scope rules to a group instead of naming people one by one.
• Agent Trail — the org-wide event stream behind every per-user chart.
• Identity and sign-in — where users and groups come from.
• User portal — what those same people see when they sign in.