Review your agent inventory

The Coding Agent Governance inventory is a live picture of what your developers run on a workstation. Each entry aggregates events from the deployed hooks so you can answer the question, “What AI is in my organization right now?”

Open the inventory

Select Agent Governance from the left sidebar, then select Inventory. The page opens on the Workstation Inventory tab. Switch tabs to choose what you want to review:

Workstation Inventory to see installed agents and their activity.
MCP Servers to see the MCP servers your agents call.
AI Models to see the underlying models invoked through agents.
Skills to see the skills your agents loaded during sessions.
Sandboxing to see whether your developers run their agents inside a sandbox.

Each tab lets you filter, search, and pivot into the Coding Agent Governance overview, policies, or policy violations. Every tab also opens a detail drawer on row click. On the item tabs, every drawer carries a Usage section that lists who uses the item. A download icon in the drawer header exports the item’s events as a CSV report. The Sandboxing tab lists developers rather than items, so its drawer shows that developer’s sessions instead.

Workstation Inventory

The Workstation Inventory tab shows every agent and AI tool your hooks have observed. The Developers with Coding Agents pie chart breaks down the agents your developers use. The Sessions trend compares this week’s sessions against last week’s.

Branded logos appear only for governed agents such as Cursor, Claude Code, Codex, and GitHub Copilot. Every other row (including discovered tools and any agent type the user interface has not yet learned to recognize) shows a generic AI model icon. Use the table to spot agents that are out of date, developers whose agent has stopped reporting, and tools your developers added that you have not adopted. Select a row to open the agent’s detail drawer. The header shows a Governed or Discovered status chip. Below the chip, the drawer shows:

Last Active and Sessions cards, with the reported version when the agent sends one.
A Usage section. Select Distinct Users to open the users panel.
An Activity section. Select Recent Events to open the event list in a side panel, or Policy Violations to jump to that agent’s violations.

Claude Code agent detail drawer showing the Governed status chip, the Last Active and Sessions cards, the version, and the Activity and Usage sections

Adoption status

Every row carries an adoption status indicator beside the name. Hover over the indicator to read the status. The indicator reports whether Endor Labs governs the item, not how risky the item is. Only coding agents carry the Approved status. See Platform and agent coverage for the agents that support policy enforcement.

MCP Servers

The MCP Servers tab shows every MCP server your agents have called. The following cards summarize the MCP servers your agents called in the last month:

Risk: A donut chart that buckets servers by the risk band derived from their Endor Score.
By Source: A pie chart that breaks servers down by where they come from.
Blocked: The count of servers your policies block.

Use the Risk filter to focus on the riskiest servers. Policies set the review and threat labels. A policy with an inventory classification tags the servers it matches as Approved, Blocked, Suspicious, or Malicious, and servers with no matching policy show Unreviewed. See Inventory classification to set the tags. The label and the score are different signals. The label records your organization’s decision, applied by your policies. Endor Labs derives the Endor Score and its risk band from the server’s configuration and source. A low-scoring server stays Unreviewed until a policy classifies it. To connect the two, write an MCP Server Posture policy that matches on a score threshold and carries an inventory classification. For example, tag every server scoring 4 or lower as Blocked.

Identify unsanctioned MCP servers

The following steps enable you to identify unsanctioned MCP servers.

Select a server to open its detail drawer. It opens with Last Active and Tool Calls cards.
Review the details section: the source, server type, host, transport, launch command, available tools, and environment variable names.
Under Usage, select Distinct Users to open the users panel.
Under Risk, select Policy Violations to open that server’s violations, or Endor Score Factors to open the per-dimension Endor Score breakdown in a side panel.

See Write a policy to gate access to specific servers.

MCP server detail drawer showing the Last Active and Tool Calls cards, the server details, and the Risk and Usage sections

MCP server sources

The Source column, the By Source pie chart, and the drawer’s Source field classify each server by where it comes from. Whether the server runs locally or remotely is a separate signal, shown as Server Type in the drawer. A server shows a dash until a policy classifies it. That covers servers last seen before your hooks picked up source classification, and events the hook had no configuration snapshot to check against. The classification updates as new events arrive. Endor Labs doesn’t score agent plugins as a single unit. It evaluates the MCP servers and skills a plugin contributes. See How Coding Agent Governance works for related inventory limits.

AI Models

The AI Models tab shows the language models invoked through your agents. Above the table, a Top Models by Sessions list ranks the most-used models and a Top Providers by Sessions list ranks their providers in the selected time range. Every column in the table is sortable, and the filters narrow the table to one agent or provider.

Use the table to track model adoption and to flag models that fall outside your approved set. Select a row to open the model’s detail drawer: Last Active and Tool Calls cards, and a Usage section whose Distinct Users entry opens the users panel.

Skills

The Skills tab shows the skills your agents loaded during sessions. The following cards summarize the skills your agents loaded in the last month:

Risk: A donut chart that buckets skills by the risk band derived from their Endor Score.
Top 5 Riskiest Skills: The lowest-scoring skills by Endor Score.
Blocked: The count of skills your policies block.

Use the Risk filter to focus on the riskiest skills. As with MCP servers, policies set the review and threat labels. See Inventory classification. These labels are separate from the score bands (Unauthorized, Caution, Safe) that come from the Endor Score.

Use the table to triage low-scoring skills and to coordinate with developers on which skills your organization trusts. Policies can flag or block skills by name or by Endor Score. See Skill Access to write those rules.

Review a skill

The following steps enable you to review a skill’s metadata, content, users, and risk.

Select a row to open the skill’s detail drawer. It opens with Last Active and Sessions cards. The Sessions card counts sessions in the selected time window, such as Sessions (Last Month).
Review the frontmatter metadata: description, allowed tools, license, compatibility, file count, and file path.
Under Content, open the captured SKILL.md in a side panel.
Under Usage, select Distinct Users to open the users panel.
Under Risk, select Endor Score Factors to open the per-dimension score breakdown.

Skill detail drawer showing the Last Active and Sessions (Last Month) cards, frontmatter metadata, and the Risk section

How skills are discovered

At every session start, the hook scans for SKILL.md files in two directory scopes and reports every skill it finds on the session-start event. Cursor scans across the common agent skill directories so that a skill installed for any supported agent appears in the inventory.

`SKILL.md` format

Each skill is a directory that contains a SKILL.md file with YAML frontmatter.

---
name: my-skill
description: One-line summary of what the skill does.
license: Apache-2.0
compatibility: Requires Python 3.14+
allowed-tools:
  - Bash
  - Read
---
# Skill body in Markdown

The frontmatter exposes these keys to the Endor Labs inventory:

name: Used as the skill identifier. If it’s missing, the inventory uses the parent directory name instead.
description: Shown on the skill row and detail page.
license: Surfaced alongside the skill for compliance review.
compatibility: Free-text dependency requirement.
allowed-tools: List of tools the skill may call. Accepts a YAML list or a space-separated string.

Discovery limits and behavior

Skill discovery works within the following limits:

A single event carries up to 100 skills. The hook skips any additional skills.
The hook truncates each skill’s content to 128 KiB and caps a single event payload at 10 MiB. When a skill’s content would push the payload past the cap, the hook reports that skill with metadata only.
The hook skips directories named .git, node_modules, vendor, __pycache__, and .venv to keep discovery fast.
The hook doesn’t follow symbolic links.
If two skills share the same name, the first one encountered wins. Workspace directories scan before user-home directories.
The hook skips SKILL.md files it cannot read, so a single corrupt skill doesn’t break inventory. A readable file with malformed frontmatter still appears, using the directory name as the skill name.

The hook doesn’t capture skills the agent loads at runtime from outside the scanned directories.

Sandboxing

The Sandboxing tab shows whether your developers run their coding agents inside a sandbox. Each row is one user identifier that an agent reported, and the tab covers session start events from the last 30 days. Search by user to find a developer, and filter by Last Active, Agent, Policy Name, Sandbox Coverage, or Sandbox Name.

The following cards summarize sandbox use:

Sandbox Sessions: A pie chart that breaks sandboxed sessions down by the sandbox that protected them. The center figure is the share of sandboxable sessions that ran inside a sandbox. Select a slice to filter the table to that sandbox.
Sessions by Sandbox Posture: A daily trend of Sandboxed, Not sandboxed, and Unknown sessions.

Sandbox posture

Every session carries a sandbox posture that the agent derives from its configuration at session start. A sandboxable session is one with a determined posture, either Sandboxed or Not sandboxed. The Sandbox Sessions center figure measures sandboxed sessions against sandboxable sessions only. Sandbox Coverage measures them against every session, so unknown sessions lower a developer’s percentage.

Sandbox coverage

Sandbox Coverage is the share of a developer’s sessions that ran inside a sandbox, counted against every session the developer started. The detail drawer reports the same figure as one of four statuses. A developer with unknown sessions never reaches 100%, even when every determined session was sandboxed. Treat a coverage gap as a question about reporting as well as about sandbox use.

Sandbox names

The Sandbox Name column and the Sandbox Sessions chart name the sandbox that protected each session. A built-in sandbox takes the name of its agent, so Cursor, Claude Code, and Codex each mean the agent’s own sandbox. When an agent reports a sandbox that Endor Labs does not recognize, the column shows the name the agent reported. Only a sandboxed session contributes a name. A developer whose sessions all ran outside a sandbox, or whose agents never determined posture, has an empty Sandbox Name column.

Policy outcomes

The Policy Name column counts the session policies that matched a developer’s sessions and shows the action those policies took. It reads as a count with the action, such as 2 blocked. When policies with different actions matched, the column shows the most severe action, with block ahead of ask and ask ahead of alert. Hover over the value to list the names of the policies that took that action. A dash means no session policy matched. Only policies that match on the session appear here. A session event can also carry a skill match or an MCP server match, and neither shows in this column. See Write a policy to create the rules behind these outcomes.

Review sandbox use for one developer

Use the detail drawer to review one developer’s sessions and the sandboxes that protected them.

Select a row to open the developer’s detail drawer. The header shows the developer and their coverage status.
Review the Sandboxed sessions card for the coverage percentage and the session counts behind it.
Review Agents, Sessions, and Last active for the developer’s activity.
Under Sessions, review each session start event. An entry shows the agent, a shortened session identifier, the sandbox that protected the session, and the date. An entry marked Unknown had no determined posture. An entry with no sandbox ran outside a sandbox.
Optional: Narrow the list with the Sandbox Name, Policy Name, and Last Active filters. Select Reset to clear them.

Sandboxing detail drawer showing the Sandbox status unknown indicator, the Sandboxed sessions card, and two session entries marked Unknown

Export sandbox usage

Select Export Usage above the table to queue a CSV report of the session start events behind the tab. See Export violations to follow the export steps and find the finished report. The dialog carries your Last Active and Agent filters, plus Policy Name when session policies exist, and the export applies your user search. The dialog does not offer Sandbox Coverage or Sandbox Name. Endor Labs computes both in your browser instead of storing them on the event, so the export job cannot filter on them. The report carries each session’s sandbox posture and sandbox fields, so you can derive both from the CSV.

See who uses an item

Every item detail drawer carries a Usage section with a Distinct Users entry showing the all-time count of developers observed using the item. Select the entry to open the users list in a side panel. The list shows every developer who has used the item, when they were first seen, and how active they have been over the last 30 days. When an item looks risky, it tells you which developers to talk to and whether they still use it.

Distinct Users panel listing each user of the Claude Code agent with first seen, last active, and active days

The list itself is all-time, and the two activity columns cover the last 30 days. N/A in the activity columns means the user has been idle on the item for over a month, not that data is missing. Agents report different user identifiers, so one developer can appear as more than one row. Cursor reports the developer’s email. Claude Code reports the Claude account email, and Codex reports the ChatGPT account email. GitHub Copilot reports the GitHub login. When Claude Code, Codex, or Copilot cannot read the signed-in account, the hook falls back to an environment variable your managed settings can set, then to the operating system login.

Next steps

Continue with the following pages:

See Write a policy to act on what the inventory shows.
See Read the Coding Agent Governance overview to track inventory trends across a time range.

Introduction

Set up

Operate

Open the inventory