Coding Agent Governance policies

Coding Agent Governance policies tell hooks how to react to risky agent activity in real time. Each policy combines a template, a set of patterns, and an action. When a matching event arrives, the hook applies the action before the agent runs the operation. Endor Labs ships nearly 50 system policies. Almost all ship enabled by default, so enforcement starts as soon as you deploy hooks. They block destructive commands, secret and credential access, risky git and publish operations, known-malicious MCP servers, and attempts to bypass the Package Firewall. They also ask before riskier-but-routine actions, such as installing packages or force-pushing a branch. See Out-of-the-box policies for the complete list. You can change any system policy for your namespace. You can override it with a policy of the same name and a different action, turn it off in the policy list, or author your own from the same templates. See Policy propagation across namespaces. The following templates are available:

• File Access: control reads, writes, edits, and deletes in the workspace.
• Command Execution: control the shell commands an agent runs.
• MCP Server Access: control which MCP servers and tools an agent calls.
• MCP Server Posture: match MCP servers by name or by Endor Labs score.
• Skill Access: control which skills run, by name or by Endor Labs score.
• Session Posture: match sessions by user, sandbox, and models.
• Malware: check the packages an agent installs against the Endor Labs malware feed.
• Secrets: scan content the agent writes or reads for leaked secrets.

Hooks evaluate events against the policy snapshot they read from the namespace.

​

Manage Coding Agent Governance policies

To open Coding Agent Governance policies:

1. Select Policies & Rules from the left sidebar.
2. Select Agent Governance.

​

View Coding Agent Governance policies

On the Agent Governance listing, you can view policies grouped by what they govern:

• All Policies for every policy in scope.
• Coding Agents for command execution policies.
• File Access for file-operation policies.
• MCP Servers for MCP server and tool access policies.
• MCP Server Posture for policies that match MCP servers by Endor Labs score.
• Sessions for session posture policies.
• Skills for skill policies.

​

Create a Coding Agent Governance policy

1. Click Create Agent Governance Policy.
2. Under Define a Policy, choose a template under Policy Template:
   • File Access under Coding Agents: Control reads, writes, deletes, and edits in the workspace.
   • Command Execution under Coding Agents: Control the shell commands the agent runs.
   • MCP Server Access under MCP Servers: Control which MCP servers and tools the agent can call.
   • MCP Server Posture under MCP Servers: Match MCP servers by name or by Endor Labs score.
   • Skill Access under Skills: Control which skills can run, by name or by Endor Labs score.
   • Session Posture under Sessions: Match sessions by user identity, sandbox, and models.
3. Under List Type, choose Allowlist to permit only matching items, or Blocklist to block matching items.
4. Fill in the pattern fields the template exposes. See Templates and patterns for field names and syntax.
5. Under Choose an Action, select the action your hook should take when an event matches:
   • Block stops the action and returns a deny response to the agent.
   • Alert lets the action proceed and records the event under Policy Violations.
   • Ask Permission pauses the agent until the developer approves or denies.
6. Optional: Under Inventory Classification, choose Allow, Block, Suspicious, or Malicious to tag the MCP servers or skills the policy matches. None, the default, applies no tag. The selector appears for the MCP Server Posture and Skill Access templates. See Inventory classification.
7. Optional: Fill in User Message. The developer sees it when the policy fires, and the agent receives it inside a standard deny response that names the policy category and tells the agent not to work around the block. Endor Labs stores the Agent Message field on the policy but does not currently deliver it to the agent.
8. Under Name Your Policy, enter a Name that describes the policy intent.
9. Click Create Agent Governance Policy.

The policy is now active. Local hooks pick it up at the next session start.

​

Coding Agent Governance templates and patterns

Each template targets one activity type and exposes the fields that activity uses. All pattern fields use regular expressions, not globs. Anchor with ^ and $ to match the full string, and escape literal characters such as . and /.

​

File Access

Use this template to govern reads, writes, deletes, and edits in the workspace.

• File Operation: Choose Any, Read, Write, Delete, or Edit.
• File Name Patterns: Regex patterns matched against file paths. Add one pattern per row with + Add file pattern.
• Example blocklist patterns: .*\.env$, .*\.pem$, .*/secrets/.*.

​

Command Execution

Use this template to govern shell commands the agent runs.

• Custom Command Patterns: Regex patterns matched against shell commands. Add one pattern per row with + Add command.
• Example blocklist patterns: ^rm\s+-rf\s+/, ^curl\s+.*\|\s*(sh|bash)\b.

​

MCP Server Access

Use this template to govern which MCP servers and tools your agents can call.

• Server Name Patterns: Regex patterns matched against MCP server names. Add one pattern per row with + Add server pattern.
• Tool Name Patterns: Regex patterns matched against MCP tool names. Add one pattern per row with + Add tool pattern.
• Example blocklist patterns: .*-prod$ for any production server, or .*delete.* for tool names that include delete.

​

MCP Server Posture

Use this template to match MCP servers by name, by Endor Labs score, or both. It scores server-level posture rather than individual tool calls, so reach for it when you want to gate on how risky a server is.

• Server Name Patterns: Regex patterns matched against MCP server names.
• Overall score at or below: Match when the server’s Endor Score (1-10, higher is safer) is at or below this value. Leave blank to ignore the overall score.
• Per-dimension thresholds: Optionally match on one dimension instead of the overall score: Supply Chain & Provenance, Authentication & Authorization, Operational Hygiene, or Input Validation & Injection.

When you set both a name pattern and a score threshold, a server must match the name and a threshold. See Endor Score to learn how Endor Labs computes MCP server scores.

​

Skill Access

Use this template to control which agent skills can run, by name, by Endor Labs skill score, or both.

• Skill Name Patterns: Regex patterns matched against skill names.
• Overall score at or below: Match when the skill’s Endor Score (1-10, higher is safer) is at or below this value. Leave blank to ignore the overall score.
• Per-dimension thresholds: Optionally match on one dimension: Instruction Integrity, Data Protection, Permission Boundaries, or External Dependencies.

When you set both a name pattern and a score threshold, a skill must match the name and a threshold. See Endor Score to learn how Endor Labs computes skill scores.

​

Session Posture

Use this template to match agent sessions by posture: who runs the session, whether it is sandboxed, and which models it uses. Each group is optional, so leave a group empty to ignore it.

• User name patterns: Regex patterns matched against the session user, such as svc-.* or .*@example\.com.
• Sandbox enabled: Match sessions where the sandbox is enabled, disabled, or either.
• Default model patterns: Regex patterns matched against the session’s default model, such as gpt-.*.
• Available model patterns: Regex patterns matched against the models offered to the session, such as claude-.*.

​

Match on more session configuration through the REST API

The policy form exposes the four criteria above. Through the REST API, a session policy can match on more of the session’s configuration, read from the agent’s config at any level (repository, user, or enterprise). Every group you set must match, and an empty group is ignored. Set these fields on the session activity.

• composer_mode_matchers: Regex matched against the composer mode, such as agent, ask, or edit.
• source_matchers: Regex matched against how the session started, such as startup, resume, or clear.
• is_background_agent: Match sessions by whether they run as a background agent.
• sandbox.fail_if_unavailable: Match sessions by whether they require the sandbox to be available.
• sandbox.allowed_host_matchers: Regex matched against the sandbox’s allowed network hosts, to catch overly permissive rules such as .*.
• permissions.default_mode_matchers: Regex matched against the permission default mode, such as bypassPermissions.
• permissions.bypass_disabled: Match sessions by whether permission bypass is disabled.
• permissions.allowed_command_matchers and permissions.denied_command_matchers: Regex matched against the session’s allowed and denied command lists.
• hook.event_name_matchers: Regex matched against configured hook event names, such as PostToolUse.
• hook.command_matchers: Regex matched against configured hook command strings, such as curl .* | bash.

Manage a policy that uses these fields through the API end to end. Saving a policy from the form rebuilds its activity from the fields the form exposes, which silently drops any REST-only criteria.

​

Match on developer identity

When you enroll the Anthropic Compliance API integration, session policies can also match the developer’s organization identity. Endor Labs syncs your Claude Enterprise directory on a schedule and resolves each Claude Code session to a directory entry by email. The hook reads the developer’s email from the local git configuration (falling back to the GIT_AUTHOR_EMAIL and EMAIL environment variables), and Endor Labs matches it against the corporate email in the synced directory, so resolution depends on developers committing under their corporate email. Set these criteria through the REST API. The policy form does not expose them yet.

• role_matchers: Regex patterns matched against the developer’s organization roles. Any match counts.
• group_matchers: Regex patterns matched against the developer’s organization groups. Any match counts.
• managed_status_match: Match sessions from a managed account (in your directory) or an unmanaged one (a Claude account outside your directory, a shadow-AI signal).

Every identity criterion you set must match. When hooks can’t resolve a session’s identity, they skip policies that use identity criteria, so they never block an unresolved session by mistake. Identity matching applies to Claude Code sessions and to session-level events only. To enroll, create an integration with your Anthropic Compliance API access key through the REST API. The sync stores directory entries (email, display name, roles, and groups) in your Endor Labs namespace, so review that data flow with your privacy team.

​

Malware

Use this template to check the packages an agent installs against the Endor Labs malware feed. The policy carries no patterns to author. Matching the activity means running the check, and the block or allow verdict comes from the feed.

• Ecosystems: Optional list that narrows the check to specific ecosystems, such as npm or pypi. An empty list checks every ecosystem.

Create and edit malware policies through the REST API. See Secure coding checks for what the check inspects, the evidence a violation carries, and a full creation example.

​

Secrets

Use this template to scan content the agent writes or reads for secrets, using the Endor Labs secret detection rules. The policy carries no patterns to author. Matching the activity means running the scan, and the verdict comes from the detection rules.

• Include file patterns: Optional regex list that limits scanning to matching paths. An empty list scans every file the event covers.
• Exclude file patterns: Optional regex list that skips paths such as test fixtures or vendored directories. Exclusions apply after inclusions.

Create and edit secrets policies through the REST API. See Secure coding checks for what the scan detects and what a violation carries.

​

Allowlist or blocklist

Choose Allowlist when you want to permit a small, known set of items and block everything else. Use it for sensitive areas, such as production credentials or a curated set of approved MCP servers. Choose Blocklist when you want to permit most activity and block known-dangerous items. Use it for destructive commands, leaked-secret paths, and unapproved MCP servers.

​

Actions

Each policy applies one of three actions on a match.

​

Inventory classification

A policy can tag the MCP servers and skills it matches in your inventory, in addition to taking an action. Choose a value under Inventory Classification when you create a policy from the MCP Server Posture or Skill Access template. The tag is independent of the action, so a policy can block and tag, tag only, or act only. The tag lands on the inventory record on one of two independent axes:

• Review status: Allow marks the item Approved. Block marks it Blocked (skills show Unapproved).
• Threat level: Suspicious or Malicious.

When several policies match the same item, the strongest value per axis wins: Block beats Allow, and Malicious beats Suspicious. The inventory record keeps the name of the policy that set each tag as evidence. Classification follows your current policy set, so turning a policy off lets the next event reclassify the item. Items no classification policy has matched show Unreviewed. These tags feed the Approved & Blocked and Suspicious & Malicious summaries on the inventory pages. See Review your agent inventory to read them.

​

Scope a policy by repository or user

Through the REST API, a policy can carry a scope that limits which events it applies to. A scope holds two regex lists:

• scope.repository_matchers: The event’s repository must match at least one pattern.
• scope.user_matchers: The event’s user must match at least one pattern.

Within a list, any match counts. When you set both lists, both must match. A policy without a scope applies to every event, and an event that misses the scope skips the policy for both allowlists and blocklists. The policy form does not expose scope fields yet, but editing a scoped policy in the form preserves its scope. Repository scoping does not yet take effect for Claude Code sessions, which report no repository value. User scoping works across agents today. Scope differs from the Session Posture template: a session policy matches session events only, while a scope restricts a policy of any template.

​

Out-of-the-box policies

Every namespace inherits these system policies. Most ship enabled by default and appear in the Agent Governance policy list next to the policies you create, under the exact names shown below. An override matches on the policy name, so use these names verbatim when you override one. To change a policy for a namespace, override it instead of deleting it. See Policy propagation across namespaces to scope an override.

​

MCP server policies

These policies govern MCP server and tool calls.

​

Command execution policies

These policies govern the shell commands an agent runs. Blocked commands stop outright. The rest ask the developer to confirm.

​

File access policies

These policies block access to sensitive paths. They match reads, writes, edits, and deletes, unless noted.

​

Package Firewall bypass protection

These policies stop an agent from bypassing the Endor Labs Package Firewall by changing where a package manager fetches packages. They ship enabled and block on a match. The table groups the protection by theme. The Agent Governance policy list shows the 10 underlying system policies under their own names, each prefixed with Package Firewall.

​

Malware protection

This policy runs the malware check instead of matching authored patterns.

​

View, edit, or delete a policy

1. Select Policies & Rules from the left sidebar, then select Agent Governance.
2. Select the policy name to open its full configuration.
3. To change the policy, edit any field and click Update Agent Governance Policy.
4. To remove the policy, confirm in the Delete this Policy? prompt. Hooks pick up the deletion at the next session start.

Every policy has a shareable URL that includes the namespace and policy name, so you can send a teammate a direct link to a specific policy.

​

Local policy cache

When the agent starts a session, endorctl ai-audit pulls a snapshot of your policies and writes it to ~/.endorctl/aigovernance/endor-policies.jsonl. The hook evaluates every event in that session against the cached snapshot, so pattern-based enforcement happens without a network round-trip. Malware policies are the exception: a matching install triggers a live malware feed lookup, and the check fails open if the feed is unreachable. The cache file uses one JSON object per line, each representing a single policy. You do not need to edit it. If the policy download fails at session start, the hook keeps the last snapshot it fetched, so your overrides stay in effect.

​

Policy propagation across namespaces

Policies you create in a namespace automatically propagate to its sub-namespaces. The policy form always saves with propagation on, so any policy you save in acme shows up for acme.team-a, acme.team-a.proj-1, and every other descendant. Through the REST API, set the propagate field to false to keep a policy out of sub-namespaces. When the Agent Governance policy list loads for a namespace, it returns:

• Policies authored in that exact namespace.
• Policies authored in any ancestor namespace.
• In-built system policies that Endor Labs ships.

If two policies share the same name across these layers, the closest match wins. For namespace acme.team-a.proj-1, a policy named block-rm-rf saved in acme.team-a overrides the same name in acme or the system catalog. A copy saved in acme.team-a.proj-1 itself overrides all three. Use this to scope a change narrowly:

• To turn a system or inherited policy off in one namespace, toggle it off from the Agent Governance policy list. This creates a local override in that namespace and leaves the policy unchanged in ancestors and siblings.
• To change a system or inherited policy, override it: save a policy with the same name in the namespace where you want the change. Use a team’s namespace to scope it to that team, or the tenant root to apply it tenant-wide.
• Toggle a system policy off rather than trying to delete it.

​

Next steps

Continue with the following pages:

• See Deploy hooks for Cursor, Claude Code, Codex, or GitHub Copilot to put your policies in front of agent activity.
• See Triage policy violations to set your daily review workflow.