Skip to main content
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. Secret Validation Rules overview

​
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.
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.

​
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.
ConstraintDescriptionExample
Min LengthThe target must be at least N characters longValue must be at least 8 characters
Max LengthThe target must be at most N characters longKey must be at most 64 characters
Regex PatternThe target must match a regular expressionKey must match ^[A-Z][A-Z0-9_]*$
Required PrefixThe target must start with specific textValue must start with https://
Required SuffixThe target must end with specific textKey must end with _SECRET
Each constraint can be applied to either the secret key or 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

1

Navigate to Project Settings

Go to Project Settings and select the Secret Validation Rules tab.Navigate to Secret Validation Rules
2

Click Create Rule

Click the Create Rule button to open the rule creation form.Create Rule button
3

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., /**).
ConstraintsClick 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, or suffix). You can add multiple constraints to a single rule. All constraints must pass for a secret to be accepted.Rule configuration form
4

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.

​
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

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.
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.
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.
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.