Vault EGP (Endpoint Governing Policy): Endpoint-Level Control in Practice

EGP leverages the Sentinel integration in Vault Enterprise to add flexible, per-endpoint pre- and post-evaluation on top of the API.

This article covers how EGP differs from ACL, the evaluation flow, path/operation targeting, policy authoring patterns, safe rollout, and operational pitfalls from an Ops perspective.

EGP basics and how it splits responsibilities with ACL/RGP

EGP (Endpoint Governing Policy) adds extra governance to Vault API endpoints (for example, secret/data/*, sys/mounts/*). Policies are written in Sentinel and can branch on request context such as the call payload and the calling identity (when Identity integration is enabled).

ACL is the foundation of authorization, granting or denying capabilities (read, create, update, delete, list, sudo). EGP runs after ACL passes the request and tightens control with additional conditions (time of day, path naming conventions, labels, issuer attributes, and so on). RGP (Role Governing Policy) is best for governance per authentication role, while EGP is best for governance per endpoint. Both EGP and RGP are Vault Enterprise features.

• EGP is an Enterprise/HCP Vault feature (not available on OSS alone)
• ACL says "what you can do"; EGP says "under what conditions you may"
• RGP is role-centric, EGP is path (endpoint)-centric

Evaluation flow and application points (pre and post)

In general, EGP runs as a "pre" evaluation after the ACL check and as a "post" evaluation after the backend processing. Post evaluation can be used to validate the response (within the metadata that is exposed), enabling checks such as "the number of returned secret keys does not exceed a limit" (subject to what the target endpoint supports).

EGP supports Sentinel enforcement levels (advisory / soft-mandatory / hard-mandatory). A safe rollout is to start with advisory, monitor, and only then escalate to hard-mandatory.

• The evaluation order is a common exam topic (ACL → EGP(pre) → backend → EGP(post) → response)
• Post evaluation does not behave identically on every endpoint, so verify applicability against requirements

EGP evaluation flow in Vault (conceptual)

Targeting: paths, operations (capabilities), and namespaces

EGP narrows the target endpoint by path (patterns that can include wildcards) and operation (capabilities). Commonly used operations are read, create, update, delete, list, and sudo. For example, you can target only create and update on secret/data/prod/*.

Combining EGP with Vault Enterprise namespaces lets you define the same EGP at a higher level and inherit it into child namespaces, or apply it to a specific namespace only. In larger environments, "loose globally and strict below" is a manageable two-tier pattern.

• Example path patterns: secret/data/prod/*, sys/mounts/*, auth/oidc/*
• Narrowing the operations (such as limiting to create/update) reduces side effects
• Decide the namespace scope early in design to avoid rework

Sentinel EGP policy authoring patterns

EGP policies are written in Sentinel. The example below conceptually allows writes to prod paths only when the calling entity belongs to the prod-writers group. It assumes Identity integration is enabled (be sure to verify that the group attribute is actually attached during testing).

The key authoring tip is to clearly target a path and operation, pass non-matching cases through, and only strictly judge the matching cases. This avoids unnecessary side effects.

• The main rule is the final decision (true to allow, false to deny)
• EGP assumes ACL has already allowed the request — it is an "extra check"
• Start the enforcement level at advisory, confirm scope and logs, then escalate gradually

Sentinel policy for EGP (conceptual example)

import "strings"

# Whether the path is under prod
prod_path = strings.has_prefix(request.path, "secret/data/prod/")

# Whether the operation is a write (create/update)
is_write = rule { request.operation in ["create", "update"] }

# Whether the caller belongs to the required group (when Identity integration is enabled)
allowed_writer = rule { identity.groups contains "prod-writers" }

# Main decision: when the path is under prod AND the operation is a write, require group membership
main = rule {
  !(prod_path and is_write) or allowed_writer
}

Safe rollout and testing procedures (Ops practice)

Start small and tighten gradually. Apply the policy first as advisory to a limited path (for example, secret/data/prod/app1/*) and watch audit logs and metrics. Once you have confirmed there are no false positives, move to soft-mandatory and finally to hard-mandatory.

Always manage changes as code and run replay tests in staging (playing back representative API scenarios). Post evaluation in particular depends on the response structure of the target endpoint, so regression tests that minimize the impact of version differences are useful.

• Do not over-broaden the scope with wildcards — start pinpoint
• Start enforcement at advisory
• Combine audit logs with metric threshold alerts (detect deny spikes immediately)
• Rehearse your rollback procedure (reverting to the previous policy)

Pitfalls and exam-ready points

Hard-mandatory EGP cannot be bypassed even by a root token. Emergency response should "remove the policy from scope or temporarily lower the enforcement level" — a common point of confusion in real Ops work.

Understanding the evaluation order (ACL → EGP(pre) → backend → EGP(post)) and that EGP is an "extra check" is also a frequent exam topic. When configuring policies, keep the split clear: ACL grants basic permission, EGP tightens conditions.

• Response metadata for post evaluation is endpoint-dependent — avoid over-relying on assumptions
• When relying on Identity attributes, verify attribute attachment differs by auth path
• Track advisory hits in audit logs and visualize the blast radius before tightening

Check Your Understanding

Frequently Asked Questions