Coding Agent Governance policies

Coding Agent Governance policies tell hooks how to react to risky agent activity in real time. Most policies combine 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 provides more than 50 system policies. Almost all are enabled by default, so enforcement starts as soon as you deploy hooks. They restrict destructive commands, secret and credential access, risky git and publish operations, known-malicious MCP servers, and attempts to bypass the Package Firewall. These policies also ask before riskier-but-routine actions, such as installing packages or force-pushing a branch. See Out-of-the-box policies to review 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 to scope an override to one namespace. 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.
• Auto Mode: Let an AI judge review shell commands, with context about your deployment.
• 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 User menu > 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 and auto mode policies.
• MCP Servers for MCP server and tool access policies.
• File Access for file-operation policies.
• Skills for skill policies.
• MCP Server Posture for policies that match MCP servers by Endor Labs score.
• Sessions for session posture policies.
• Malware for malware check policies.
• Secrets for secrets check 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.
   • Auto Mode under Coding Agents: Let an AI judge review shell commands. This template has no list type or action steps. See Create an auto mode policy to fill in its fields.
   • 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 to look up the field names and pattern syntax for each template.
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, where the agent supports it.
   • AI Judged hands the matched command to the AI judge, which decides the action. It appears for Command Execution policies and is unavailable when Intent is Governance. See AI Judged action to review how it behaves.
6. Optional: Fill in User Message. The developer sees it when the policy fires, if the agent hook response can carry the message. A Block policy also sends it to the agent inside a deny response that names the policy category and warns against working around the block. An AI Judged policy has no message fields, because the agent sees the judge’s reason instead.
7. Optional: For a Command Execution policy, choose Risk or Governance under Intent. Risk is the default. See Policy intent to choose between them.
8. 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 to review how each tag affects inventory.
9. Under Name Your Policy, enter a Name that describes what the policy does.
10. Click Create Agent Governance Policy.

The policy is now active. Local hooks pick it up at the next session start. Endor Labs stores the Agent Message field on the policy but does not currently deliver it to the agent. The form groups templates by what the agent is doing, while the Agent Governance policy listing groups them by what they govern. You can view File Access under Coding Agents in the form, but its policies appear under File Access in the listing.

​

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.

​

Auto Mode

Use this template to turn on the AI judge for shell commands. The policy carries no patterns, list type, or action.

• Judge Scope: Choose which commands the judge reviews: Off, Matched commands only, or All commands.
• Deployment Context: Optional facts about your environment, such as which hosts and registries are yours. Separate entries with a blank line.

See Auto mode and the AI judge to review what each scope does and the limits on deployment context.

​

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 Endor Labs ignores an empty group. 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 connect the Anthropic Compliance API, session policies can also match the developer’s organization identity. Endor Labs resolves each Claude Code session to a synced directory entry by the developer’s Claude account email and attaches the roles and groups it finds. Set these criteria on the session activity’s top_level group through the REST API. The policy form does not expose them yet.

• role_matchers: Regex patterns matched against the developer’s Anthropic organization role, such as admin or claude_code_user. Any match counts.
• group_matchers: Regex patterns matched against the developer’s organization groups, such as platform or security. Any match counts.

Every identity criterion you set must match, together with any other session criteria on the policy. When the hook cannot resolve a session’s identity, it skips policies that use identity criteria, so it never blocks an unresolved session by mistake. Identity matching applies to Claude Code sessions and to session-level events only. See Connect the Anthropic Compliance API to enroll your organization, learn how the hook resolves the email, and see a full policy example.

​

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. An empty list checks every ecosystem. The valid values are npm, pypi, go, nuget, packagist, cargo, gem, apk, debian, and rpm, and Endor Labs rejects any other value when you save the policy.

Create and edit malware policies through the REST API. See Secure coding checks to review 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.

• File operations: Optional list of the operations to scan. An empty list scans writes and edits. Add FILE_OPERATION_READ to also scan the files the agent reads. Read scanning is opt-in because it reads each file from disk.
• 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.
• Include rule IDs: Optional list that limits the policy to specific detection rules, matched exactly against rule IDs such as aws-access-token. An empty list acts on every rule in your effective ruleset.
• Exclude rule IDs: Optional list that mutes rules whose matches are false positives in your codebase. Exclusions apply after inclusions.

Create and edit secrets policies through the REST API. See Secure coding checks to review 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 except an auto mode policy applies one of the following actions on a match. AI Judged applies to Command Execution policies only. See AI Judged action to review how each label maps to an outcome. Agents differ in where they can pause for an Ask Permission policy. See Enforcement behavior to review the per-agent behavior.

​

Auto mode and the AI judge

The AI judge is a large language model (LLM) that reviews a shell command and labels it benign, review, or suspicious. Command patterns catch what you anticipated, and the judge weighs what the command actually does in context. Judging is off by default. Turn it on with an auto mode policy whose Judge Scope is not Off, or with a Command Execution policy that uses the AI Judged action. See How the AI judge reviews commands to review what the hook sends and how judging affects latency.

​

How the judge’s label decides the outcome

What the judge reviews, and what its label does, depends on how you turned it on. A released match contributes no action, so the command runs unless another policy matches it. Under All commands, an ask or block from the judge replaces every Risk command match and appears under Policy Violations against the auto mode policy. When a review or suspicious label comes back, the agent sees the judge’s reason in the ask or block message. The judge never overrides a Governance policy, under any scope. A Governance match keeps its own action next to whatever the judge decides. See Policy intent to mark a policy as Governance. The judge reviews shell commands only. File access, MCP, session, malware, and secrets policies keep their own actions. When audit-only mode is on (ENDOR_AI_AUDIT_NO_BLOCKING=true), a suspicious label records an alert instead of blocking. A review label still asks.

​

Create an auto mode policy

An auto mode policy chooses which commands the judge reviews and gives it context about your environment.

1. Click Create Agent Governance Policy.
2. Under Define a Policy, choose Auto Mode under Policy Template.
3. Under Judge Scope, choose which commands the judge reviews:
   • Off: The judge rules on nothing by itself. The policy only supplies deployment context to AI Judged command policies.
   • Matched commands only: The judge rules on commands that a command policy flagged, and its label replaces that policy’s action. Governance policies keep their action.
   • All commands: The judge rules on every command, and command policies no longer decide, except Governance policies.
4. Optional: Under Deployment Context, enter facts about your environment, such as your internal hosts and registries. Separate the entries with a blank line.
5. Under Name Your Policy, enter a Name.
6. Click Create Agent Governance Policy.

Keep the following rules in mind when you write auto mode policies:

• Only one auto mode policy applies to each event: the one with the most scope fields set, with the alphabetically first name breaking a tie. Other matching auto mode policies stay enabled but do nothing.
• Endor Labs rejects an unscoped auto mode policy with Judge Scope set to Off and no deployment context, because it does nothing. A scoped policy with the same settings is valid, and it turns judging off for the repositories or users it matches.
• Deployment Context holds at most 64 entries, each 4,096 bytes or fewer, and 8,192 bytes in total. In the form, an entry that contains a blank line splits into two entries.

The system policy Auto mode: judge commands that matched a risk policy uses Matched commands only and ships disabled. Enable it to start judging without writing your own policy.

​

AI Judged action

The AI Judged action hands a command policy’s own matches to the judge, which picks the outcome. Use it for patterns that are too broad to block outright, such as remote access commands, where the context decides whether the command is safe. The action has the following constraints:

• It applies only to Command Execution policies with Risk intent. Endor Labs rejects it on a Governance policy.
• The form offers AI Judged when you create a policy, and when you edit a policy that already uses it. To move an existing policy to AI Judged, create a new policy with that action.
• If the judge returns no answer, the hook releases the match, because an AI Judged policy has no action of its own to fall back to.
• The judge reads the deployment context of the auto mode policy that applies to the event, if any.
• endorctl versions earlier than v1.7.1173 do not recognize the action and let the matched command run.

​

Policy intent

Each Command Execution policy has an intent that controls whether the AI judge can override it:

• Risk: The policy flags commands that might be dangerous, and the AI judge can override its action. Risk is the default.
• Governance: The policy enforces an organizational rule, and its action is final. The judge never releases a Governance match.

Choose Governance for rules that hold regardless of how safe the command looks, such as no direct pushes to main or no package publishing from a developer machine. Intent changes nothing until you turn on the judge. Set the intent under Intent when you create or edit a Command Execution policy. Through the REST API, set the intent field to POLICY_INTENT_RISK or POLICY_INTENT_GOVERNANCE. Endor Labs rejects an intent on an auto mode policy. Several system policies ship with Governance intent. The Intent column in Command execution policies lists them, and every command policy in Package Firewall bypass protection is Governance.

​

Inventory classification

Besides taking an action, a policy can tag the MCP servers and skills it matches in your inventory. 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 more than one policy matches 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 Blocked summary cards on the MCP Servers and Skills inventory tabs. 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 are enabled by default and appear in the Agent Governance policy list next to the policies you create, under the exact names shown below. The tables mark the exceptions, which are disabled by default: the auto mode policy, the malware policy, both secrets policies, and the environment variable export and recursive-grep policies. Enable a disabled policy to turn it on for a namespace. 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, and Endor Labs records alerted commands as they proceed. Asked commands wait for the developer to confirm, where the agent supports it. The Intent column shows whether the AI judge can override the policy. See Policy intent to review what each intent means.

​

File access policies

These policies guard sensitive paths. Each blocks on a match and covers 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 are enabled by default and block on a match. Every command policy in this group has Governance intent, so the AI judge never overrides it. 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.

​

Auto mode policy

When enabled, this policy turns on the AI judge for commands that a Risk command policy matched.

​

Malware protection

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

​

Secrets protection

These policies run the secrets check instead of matching authored patterns.

​

View, edit, or delete a policy

1. Select User menu > 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-<namespace>.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 AI judge also calls Endor Labs for each command it reviews. 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.
• Built-in system policies from Endor Labs.

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 the closest-match rule 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.
• See Connect the Anthropic Compliance API to match session policies on your developers’ organization roles and groups.