Skip to main content
Coding Agent Governance gives security and engineering teams visibility and control over how AI coding agents work inside your organization. Endor Labs collects events from agents, builds an inventory of your developers’ AI use, and applies your policies to risky activity in real time. Use Coding Agent Governance to answer questions such as:
  • Which AI coding agents and MCP servers are running on developer machines?
  • Are agents reading sensitive files, executing dangerous commands, or talking to unapproved MCP servers?
  • When a policy fires, what was the developer trying to do, and which agent was responsible?
Coding Agent Governance has the following components:
  • Hooks that run on developer machines and capture events
  • Coding Agent Governance policies that govern these events
  • Dashboards that show what your agents are doing
Together, these components let you control and view the activities of AI agents across your organization.

​
What Coding Agent Governance is (and isn’t)

Coding Agent Governance puts guardrails around what coding agents do so it can catch accidental or unintended actions before they cause damage. It reduces the chance an agent does something it shouldn’t while working through a task. It is not a sandbox, firewall, or hardened security boundary. Policy controls lower risk and blast radius, but they do not guarantee that a risky action is impossible. Hard guarantees require isolation at the operating system, system call, or sandbox level. Coding Agent Governance works alongside that kind of isolation. It does not replace it. Coding Agent Governance targets accidental agent behavior. It is not designed to stop a determined user who deliberately tries to defeat the controls.

​
Lifecycle of an event

When a developer starts a session, an Endor Labs hook runs alongside the agent and emits a normalized event for every meaningful action. Each event carries the agent type, the user, the workspace context, and the tool, command, or file the agent acted on. The event takes two paths in parallel:
  • Local evaluation: The hook checks the event against a cached copy of Coding Agent Governance policies. If a policy matches, the hook can stop the action, alert the user, or pause for the developer to approve before the agent proceeds.
  • Centralized aggregation: The hook forwards the event to Endor Labs, where it updates the inventory, the Coding Agent Governance overview, and the policy violation log.
Together, these methods enforce policies on developer machines in real time and give your security team a single place to monitor activity and plan their response. As your AI agent inventory evolves, your security team can refine policies and roll out changes. The following diagram shows the data flow in Coding Agent Governance.

​
Hooks and what they govern

A hook is a small script Endor Labs deploys to your developers’ machines. It runs whenever the agent starts a session, submits a user prompt, calls an MCP tool, runs a shell command, or reads, writes, or deletes a file. For each event, the hook can apply a policy locally before the agent acts. Hooks enforce guardrails such as blocking dangerous commands or gating MCP tool use. They are instruction-based controls that the agent and host honor, not a tamper-proof runtime. You can write policies for the following activities:
  • Shell commands the agent tries to run, matched by regex.
  • File reads, writes, deletes, and edits, matched by regex on the file path.
  • MCP server and tool calls, matched by regex on server name and tool name.
  • Package installs, checked against the Endor Labs malware feed.
  • File content the agent writes or reads, scanned for secrets.
The malware and secrets checks carry no authored patterns. Their verdict comes from Endor Labs data. See Secure coding checks. When a policy matches, the hook applies the action you chose:
  • Block stops the action and returns a deny response. The response tells the agent the action was denied by a governance policy and not to work around the block.
  • Alert logs the event without stopping the agent.
  • Ask Permission pauses for the developer to approve or deny.
See Write a policy for allowlists, blocklists, and how to override in-built system policies.

​
Example: a blocked malicious package install

The following session shows the lifecycle end to end. A developer asks a coding agent to install an npm package, the hook checks the install against a malware policy on the developer’s machine, and the block stops the install before any package code runs.
The example shows four things about how enforcement behaves:
  • The hook evaluated the install at the moment the agent ran it, so no package code executed. Nothing depended on the agent choosing to check the package first.
  • The verdict came from the Endor Labs malware feed rather than a pattern someone authored. See Malware check.
  • The deny response tells the agent what category of action was denied, gives the evidence and the feed source, names the policy that fired, and instructs the agent not to route around the block or disable the check. The agent stopped and reported the block instead of retrying with a different registry or --force.
  • The event reached Policy Violations with the package, ecosystem, and feed source alongside the agent and user, so your security team sees the attempt even though nothing was installed.

​
Data sent to Endor Labs

Each hook event carries the metadata Endor Labs needs for inventory and policy evaluation:
  • Agent name, version, and (where available) model
  • Session and sub-session IDs
  • Device (endpoint) identifier
  • Session configuration, such as permission mode and sandbox state
  • User identifier when the agent provides one
  • Repository name (not populated for Claude Code sessions) and working directory
  • MCP server name, tool name, and call counts
  • Shell command line (regex-matched against your policies)
  • File path and operation type (read, write, delete, edit)
  • Secrets check match (rule, line, column, and fingerprint, never the secret value)
  • Policy match outcome and the action applied

​
Secret redaction

Endor Labs runs every command line, file path, URL, environment value, and MCP tool input or output through a regex-based redactor before it leaves the developer’s machine. Environment variables and keys named like a secret (such as TOKEN, SECRET, API_KEY, PASSWORD, or AUTHORIZATION) become [REDACTED]. The redactor also matches common secret formats in place: URL and database-connection credentials, AWS access keys, JWTs, PEM private keys, and provider tokens such as GitHub (ghp_*), OpenAI, and Anthropic keys. Redaction of event payloads is best-effort regex pattern matching. A secret that does not match a known pattern or key name can still reach the backend. The secrets check is separate from redaction: it detects secrets in file content on the developer’s machine, and its violations carry the rule and location, never the value.
On Cursor, the sessionStart hook returns the Endor Labs credential values to Cursor in plaintext under an AGENT_HOOK_ENDOR_* prefix, so subsequent hooks in the session inherit them. The values never leave the developer’s machine, but anything that captures Cursor hook stdout (such as debug logging or screen recording) can see them.
The hook writes two Coding Agent Governance files to a developer’s disk. The hook refreshes the local policy cache (~/.endorctl/aigovernance/endor-policies.jsonl) at session start. When the event cache is enabled, as the recommended Cursor and Claude Code configurations do, the hook also queues events in ~/.endorctl/aigovernance/localdb/cache-<namespace>.db and flushes them in batches within about 30 seconds of hook activity, and fully at session start and end.

​
What you see in Endor Labs

After you deploy hooks and at least one policy exists, select Agent Governance from the left sidebar: Policies live with the rest of your platform policies. To open them, select Policies & Rules from the left sidebar, then select Agent Governance.

​
Limitations of Coding Agent Governance

Coding Agent Governance currently has the following limitations.

​
Platform and agent coverage

Coverage has the following boundaries:
  • Hooks run on macOS, Linux, and Windows developer machines. CI runners are not supported. See Supported agents and platforms for the full matrix.
  • Policy enforcement covers Cursor, Claude Code, Codex, and GitHub Copilot. Other AI tools (such as Continue, Cody, Gemini CLI, and Amazon Q) are still discovered at session start. They appear in the Workstation Inventory table with a Discovered • Not governed status, and no hook fires for them.

​
Enforcement behavior

Keep the following enforcement behaviors in mind:
  • Policy edits take effect at the next session start on a developer’s machine, when the hook refreshes the local policy cache. Tell developers to restart the agent to pick up policy changes.
  • Enforcement hooks fail open. If the hook cannot run, or a malware policy cannot reach the Endor Labs API for a verdict, the action proceeds. An unreadable local policy cache does not disable enforcement, because the hook falls back to the built-in system policies. When the hook cannot run, the agent and the IDE keep working, but the event is missing from inventory and policy violations until the cause is fixed.
  • In Cursor, Ask Permission pauses for approval on shell commands and MCP tool calls. It does not pause on file reads, where an Ask policy proceeds and is recorded, the same way Alert behaves.
  • In Codex, Ask Permission cannot pause a tool call, so it fails closed and denies the call with the ask message. At Codex’s own approval prompts, an Ask policy defers to that prompt instead. See Deploy hooks for Codex.
  • In GitHub Copilot, Ask Permission prompts in VS Code agent mode only. The Copilot CLI honors deny but not ask, so an Ask policy on a CLI session proceeds and lands under Policy Violations, the same way Alert behaves. See Deploy hooks for GitHub Copilot.
  • Policies match commands and patterns, not the end effect. An agent can occasionally reach the same result another way. That trade-off comes with best-effort, pattern-based controls.

​
Attribution and visibility

Attribution has the following gaps:
  • User attribution is populated when the agent’s hook payload includes a user identifier. Cursor supplies one on most events. Claude Code, Codex, and GitHub Copilot attempt to derive one from the local environment and may succeed depending on the version and configuration, but the value can still be empty. The User column on Policy Violations and the user count on the Overview stay empty for events without an identifier.
  • endorctl captures device (endpoint) attribution on every event, but Coding Agent Governance does not surface it in the user interface. You cannot filter or scope inventory or policy violations by device.
  • Claude Code sub-agent activity may carry no user identity, and the hook does not record sub-agent MCP tool calls that a policy cleanly allows. Policies still evaluate and enforce on sub-agent activity.

​
Inventory and scoring

Inventory and scoring have the following limits:
  • Endor Labs computes MCP server risk scores only for servers it finds in an agent’s configuration files. A server invoked without a discoverable configuration entry can appear in inventory from its tool calls without a score.
  • Endor Labs discovers MCP servers that enabled Claude Code plugins contribute, from the installed-plugin registry (~/.claude/plugins) and from skills-directory plugins. Each server appears in inventory under the name Endor Labs derives from its runtime (the command binary or URL host), falling back to <plugin>/<server> when it cannot derive one, attributed to the level that installed the plugin. Endor Labs does not inventory disabled plugins or marketplace plugins that are not installed locally.
  • Endor Labs does not assess agent plugins as a single unit. It evaluates the MCP servers and skills a plugin contributes, not the plugin itself.
  • File access matching is regex-based on path. The secrets check adds content-aware secret detection, but Endor Labs does not redact or rewrite the content an agent reads.
  • Skills inventory reflects skills discovered in the workspace and user-home directories at session start. Skills loaded at runtime by the agent, or installed outside those directories, might not appear. See Skills for the exact paths scanned.
  • Hooks capture session configuration such as permission mode and sandbox state. Use Session Posture policies to match sessions by sandbox setting. Richer client-posture context in the inventory is limited today.