Skip to main content
Secret Validation Rules let you define constraints that secrets must satisfy before they can be created, updated, or generated. 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, that database connection strings always start with a specific prefix, or that passwords generated by a dynamic secret or rotation always match a particular pattern. Secret Validation Rules overview

​
Rule Types

Infisical supports three rule types, each targeting a different kind of secret:
  • Static Secrets — applied when a user-managed secret is created or updated.
  • Dynamic Secrets — applied to the credentials generated when a dynamic secret lease is issued, for selected dynamic secret providers.
  • Secret Rotations — applied to the credentials generated on each rotation, for selected rotation providers.
For dynamic-secret and rotation rules, you must select one or more providers the rule applies to. Currently supported providers:
Rule TypeSupported Providers
Dynamic SecretsSQL Database (PostgreSQL, MySQL, Oracle, Microsoft SQL Server), Milvus
Secret RotationsPostgreSQL Credentials
When a dynamic-secret or rotation rule covers a provider, any user-configured password configuration / password requirements on that dynamic secret or rotation are ignored — the rule’s constraints take precedence. The UI surfaces a warning in the affected forms when this is the case.

​
How It Works

​
Static Secrets

When a static 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 describing which rule and constraint was violated.
Static-secret validation rules are enforced on mutations only (create or update). Existing secrets that were created before a rule was added are not retroactively validated.

​
Dynamic Secrets and Secret Rotations

For dynamic secrets and secret rotations, validation rules drive the generation of credentials rather than rejecting input. When a lease is issued (dynamic secret) or credentials are rotated (rotation), Infisical generates a password that satisfies the matching rule’s constraints, replacing the default password generation logic. If the rule has a Regex Pattern constraint, the password is generated directly from that pattern, and min/max length constraints are ignored for that rule. To enforce length when using a regex, express it inside the pattern itself (e.g. [A-Z0-9]{16,24}). If the rule’s constraints are statically infeasible (e.g. an invalid regex, or a min length larger than the max), the rule is rejected at save time so the issue surfaces immediately rather than at lease/rotation time.

​
Constraint Types

Each rule contains one or more constraints. A constraint specifies what to check and how to check it.
ConstraintDescriptionExampleStatic SecretsDynamic SecretsSecret Rotations
Min LengthTarget must be at least N charactersAt least 8 characters✓✓✓
Max LengthTarget must be at most N charactersAt most 64 characters✓✓✓
Regex PatternTarget must match a regular expression^[A-Z][A-Z0-9_]*$✓✓✓
Required PrefixTarget must start with specific texthttps://✓✓✓
Required SuffixTarget must end with specific text_SECRET✓✓✓
Prevent Value ReuseNew value must not match any of the last N versionsLast 10 versions✓——
Applies To target by rule type:
  • Static Secrets — each constraint applies to the secret key or value. Prevent Value Reuse only applies to the value.
  • Dynamic Secrets and Secret Rotations — constraints apply to the generated password.

​
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).
  • Providers (dynamic-secret and rotation rules only): One or more providers the rule applies to. A rule fires only when the dynamic secret / rotation in scope also matches one of the selected providers.
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, or require longer generated passwords for rotations on production databases.

​
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 — Static Secrets, Dynamic Secrets, or Secret Rotations.
  • Providers (dynamic-secret and rotation rules only) — Select one or more providers the rule applies to.
  • 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 static-secret rules, select whether each constraint applies to the secret key or value. For dynamic-secret and rotation rules, constraints apply to the generated password, then provide the constraint parameter (length, pattern, prefix, or suffix). You can add multiple constraints to a single rule. All constraints must be satisfied — for static secrets the value/key must satisfy them, and for dynamic/rotation rules the generated password is built to satisfy them.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, 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. For dynamic-secret and rotation rules, two rules also conflict only if their selected provider sets intersect. For example, a Postgres-only rotation rule on /db/* and a separate Postgres rotation rule on /** overlap on Postgres + the path glob, and the second one would be rejected. A Milvus-only rule on the same path would not conflict with a Postgres rule, because the providers don’t overlap.

​
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.
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.
Create a Dynamic Secrets rule scoped to all environments and /**, with SQL Database selected as a provider:
  • Min Length: 24
  • Required Prefix: INF_
Every SQL dynamic-secret lease issued in the project will now produce a password that is at least 24 characters long and starts with INF_. The password configuration on individual SQL dynamic secrets is ignored while the rule is active.
Create a Secret Rotations rule scoped to the production environment, with PostgreSQL Credentials selected as a provider:
  • Regex Pattern: ^[A-Z][A-Za-z0-9]{19,29}$
Postgres rotations in production will now produce passwords that start with an uppercase letter and are 20–30 characters of mixed-case alphanumerics. Because a regex is set, separate min/max length constraints would be ignored — express the length window inside the pattern instead.