Secret Validation Rules - Infisical

Secret Validation Rules let you define constraints that secrets must satisfy before they can be created or updated. This helps teams enforce consistent naming conventions, prevent weak or malformed values, and maintain compliance standards across environments — all automatically at write time.

For example, you can require that all secret keys in production follow UPPER_SNAKE_CASE, that values meet a minimum length, or that database connection strings always start with a specific prefix.

How It Works

When a secret is created or updated, Infisical checks it against all active validation rules whose scope (environment and folder path) matches the secret's location. If any constraint is violated, the secret is rejected and an error is thrown. When a secret is rejected, the actor will see an error describing which rule and constraint was violated.

<Note> Validation rules are enforced on mutations only (such as create or update events). Existing secrets that were created before a rule was added are not retroactively validated. </Note>

Constraint Types

Each rule contains one or more constraints. A constraint specifies what to check (the secret key or value) and how to check it.

Constraint	Description	Example
Min Length	The target must be at least N characters long	Value must be at least 8 characters
Max Length	The target must be at most N characters long	Key must be at most 64 characters
Regex Pattern	The target must match a regular expression	Key must match `^[A-Z][A-Z0-9_]*$`
Required Prefix	The target must start with specific text	Value must start with `https://`
Required Suffix	The target must end with specific text	Key must end with `_SECRET`
Prevent Value Reuse	The new value must not match any of the last N versions	Value must not match the last 10 versions

Each constraint (except Prevent Value Reuse) can be applied to either the secret key or the secret value. Prevent Value Reuse applies only to the secret value.

Scoping Rules

Every rule is scoped to control where it applies:

Environment: Restrict the rule to a specific environment (e.g., production), or apply it to all environments.
Folder Path: Restrict the rule to a specific folder path. Supports glob patterns (e.g., /** for all paths, /services/* for immediate subfolders of /services).

This means you can have different validation standards for different parts of your project. For instance, you might enforce stricter naming in production while keeping development more flexible.

Creating a Rule

<Steps> <Step title="Navigate to Project Settings"> Go to **Project Settings** and select the **Secret Validation Rules** tab.

![Navigate to Secret Validation Rules](/images/platform/secret-validation-rules/settings-tab.png)

</Step> <Step title="Click Create Rule"> Click the **Create Rule** button to open the rule creation form.

![Create Rule button](/images/platform/secret-validation-rules/create-button.png)

</Step> <Step title="Configure the rule"> **Rule Details**

- **Name** — A descriptive name (e.g., "Production key naming convention").
- **Description** (optional) — A brief explanation of what the rule enforces and why.
- **Rule Type** — Currently supports **Static Secrets**.
- **Environment** — Choose a specific environment or "All Environments".
- **Folder Path** — The path scope, supporting glob patterns (e.g., `/**`).


**Constraints**

Click **Add Constraint** and choose from the available constraint types. For each constraint, select whether it applies to the secret **key** or **value**, then provide the constraint parameter (length, pattern, prefix, suffix, or number of previous versions).
You can add multiple constraints to a single rule. All constraints must pass for a secret to be accepted.


![Rule configuration form](/images/platform/secret-validation-rules/create-rule-form.png)

</Step> <Step title="Save the rule"> Click **Create Rule** to save. The rule is immediately active and will be enforced on all subsequent secret writes within its scope. </Step> </Steps>

Overlapping Rules

Infisical prevents you from creating rules that would conflict with each other. If two rules apply to the same scope (overlapping environment and folder path) and share a constraint of the same type targeting the same field (key or value), the second rule will be rejected.

For example, you cannot have two separate "Regex Pattern on key" constraints in overlapping scopes, as they could contradict each other. Instead, combine the patterns into a single rule.

Example Use Cases

<AccordionGroup> <Accordion title="Enforce UPPER_SNAKE_CASE naming"> Create a rule scoped to all environments with a **Regex Pattern** constraint on the **secret key**:

- Pattern: `^[A-Z][A-Z0-9_]*$`

This ensures all secret keys follow the `UPPER_SNAKE_CASE` convention (e.g., `DATABASE_URL`, `API_KEY`), rejecting names like `mySecret` or `api-key`.

</Accordion> <Accordion title="Require minimum value length"> Create a rule with a **Min Length** constraint on the **secret value**:

- Minimum: `8`

This prevents secrets with very short or empty-like values from being saved, helping catch accidental pastes or placeholder values.

</Accordion> <Accordion title="Enforce URL format for connection strings"> Create a rule scoped to a specific folder path (e.g., `/database/*`) with a **Required Prefix** constraint on the **secret value**:

- Prefix: `postgresql://`

This ensures all secrets in the database folder contain valid PostgreSQL connection strings.

</Accordion> <Accordion title="Enforce environment-specific key suffixes"> Create a rule scoped to the `production` environment with a **Required Suffix** constraint on the **secret key**:

- Suffix: `_PROD`

This helps distinguish production secrets from those in other environments.

</Accordion> <Accordion title="Prevent reuse of old secret values"> Create a rule with a **Prevent Value Reuse** constraint on the **secret value**:

- Previous versions: `10`

When a secret is updated, its new value is validated against the specified number of prior versions. This is useful for enforcing rotation policies and ensuring that secrets are not recycled.

</Accordion> </AccordionGroup>