Skip to main content
A Signer with an approval policy makes signing a two-party operation: someone asks, someone else says yes, and the request becomes an active access window with limits on how much and how long. This page covers everything that happens inside a Signer’s Approvals tab. Concretely, approvals govern three things:
  1. The policy: who has to approve, in what order, and how strict the per-access limits are.
  2. The path to access: either an Administrator pre-approves an access window for a specific member, or an Operator requests one and approvers sign off.
  3. The active access record: once approved, it’s the row in the Approvals table with its own expiry, signature count, and revoke button.
Signers without an approval policy don’t use this flow. Members with sign rights sign directly and you’ll still see a full audit trail under the Signer’s Activity tab.

​
When you want an approval policy

Production releases

Two security leads must sign off before a release artifact is signed.

Separation of duties

Developers request to sign; managers approve. Audit shows both actors.

Compliance

SOC 2, PCI-DSS, or internal SDLC frameworks that require documented approval.

Bounded CI access

Pre-approve a CI identity for “10 signings within the next hour” instead of standing access.

​
How an approval flow works

Each step runs in order. Once the last step’s required approvals are reached, Infisical issues an active access record bounded by the policy’s per-approval limits. The Operator can then sign through the PKCS#11 module or the Sign API. Administrators can also pre-approve signing directly when the approval flow isn’t a fit, for example during an incident response where waiting on approvers would block recovery.

​
Configure the approval policy

Open the Signer’s Approvals tab and click the pencil icon on the Approval Policy panel. The editor is a 2-step sheet.
1

Approvers

Define one or more approval steps. To turn the policy off entirely, delete every step. The Signer reverts to direct signing.For each step:Add more steps to run multiple sign-offs in sequence. For example: Step 1 Team Lead Review (1 approval), then Step 2 Security (2 approvals).Required-approval validation:
  • A step must have at least one approver.
  • Required approvals must be ≥ 1.
2

Approval limits

Per-approval caps that apply to every access record this policy issues:You can combine both. For example: maxSignings=10 with signing window=1h issues access good for at most 10 sign calls within one hour of approval, whichever comes first.Scoping is not configured here. Whoever opens a request or pre-approval chooses, per request, which signing parameters to lock it to.
Press Save policy. The new policy applies to new requests; existing active access keeps its original terms until it expires or is revoked.

​
Scoping an approval

By default an approval means “this member may sign N times before it expires”. Expanding Scope this request on a request or pre-approval lets you narrow that to a specific signing situation. Every parameter is optional, and the ones you fill in are the only ones that get restricted.
A parameter you fill in has to match every time. If a scoped approval still has 999 signatures left but you switch to a different machine, tool, or command than the one you declared, those sign calls are denied. When signing suddenly stops working under an approval that clearly has signatures remaining, compare your current signing setup against the scope on the request: that mismatch is almost always the cause. To sign in a different situation, open a new request describing it.
A command scope is compared exactly. Only whitespace is forgiven: a run of spaces or a tab where the approval has a single space still matches. Everything else counts as a different command and needs its own approval, including reordering the options, invoking the tool by a different path, changing an argument, and writing --flag value as --flag=value. Infisical cannot know which flags take values in an arbitrary tool, so it does not try to guess whether a rearranged command is equivalent.
On a self-hosted instance, an IP Address scope is only reliable once TRUSTED_PROXY_CIDRS names the reverse proxies in front of Infisical. Until it is set, forwarded-IP headers are honored from any source for backwards compatibility, so a caller can present an address that is not theirs.
A command is stored on the approval and on the signing operation, where approvers and auditors can read it. Infisical strips the values of credential arguments it recognises, and the signing clients strip them before sending too, but recognition is best-effort on both sides. Keep secrets off the command lines you sign with.

​
Scoping to one artifact

Pinning an approval to a Data Hash is the tightest option: the approver signs off on one file rather than on a window of time, and no other payload can be signed under it. The PKCS#11 module and the Windows KSP fill this in for you. When signing is denied, the request they open is already scoped to the artifact of the denied attempt, along with the command and machine it came from, so you approve it in Infisical and re-run the same command.
For release pipelines, pair a data hash scope with a signature count of 1. The approval then covers exactly one signature over exactly one file.
Filling in a digest by hand is fiddly, because a sign call carries a digest rather than the file, so the value to declare is the hash of the bytes the call submits and not sha256sum yourfile. If you are calling the API directly, see the Sign API reference.

​
When the scope needs to change

A request’s scope is fixed once it is open. Nobody edits it during review, including the approvers: an approval means the parameters shown on the request, so if they are wrong the request is rejected and a new one is opened with the parameters you want. For a pipeline that signs a different artifact on every run, do not fight this per request. Tell the signing client which parameters to leave out in the first place, with approval.exclude_scope_fields in the PKCS#11 module or the Windows KSP. Excluding data_hash is the common case: a timestamped signature changes the digest between runs even for the same file, so pinning it would mean a fresh approval for every build. Exclude one parameter at a time. Each one you drop widens what the approval covers, and because an approval belongs to the identity rather than to a machine, dropping all of them grants that identity any signature it asks for until the window or count runs out.

​
Access lifecycle

Every approved request becomes an active access record. On the Approvals tab it’s a row in the Requests table with its own status, expiry, and signature counter.

​
Statuses you’ll see

​
Approval paths

There are two ways someone gets active access on a Signer: Administrators pre-approve signing directly for someone else, or members open a request to sign that runs through the approval policy.
An Administrator gives a specific member access up-front. No approval workflow runs. The access is created Active immediately and the recipient can sign right away.
1

Click Pre-approve signing

From the Signer’s Approvals tab, click Pre-approve signing.
2

Pick the recipient

Select the user or machine identity that should receive access. The list includes every Signer member except Auditors (including users reachable via a group).
3

Set the access terms

Per-access values cannot exceed the policy ceilings. Requesting maxSignings=10 against a policy that allows 3 returns a 400 with a clear message. Omitting a field that the policy caps simply clamps to the ceiling, never silently unlimited.
4

Issue the access

Press Pre-approve. The recipient can sign immediately.
Typical use: pre-approving a CI machine identity for “10 signings within the next hour” right before a release pipeline runs.

​
Approving or rejecting

If you’re an eligible approver for the current step of a pending request, an Approve or Reject action is visible on the request row.
1

Open the request

Click the row on the Signer’s Approvals tab. Full details: requester, recipient, justification, requested signings, requested duration, and which step is currently pending.
2

Review

Verify who’s asking, for how many signings, for how long, and why. If the requester scoped the request, the detail page lists every parameter the access will be limited to, so you can see exactly which signing situation you are approving.
3

Decide

  • Approve counts toward the current step’s required approvals. When the last step’s count is reached, the access record is created.
  • Reject terminates the workflow. No access is created. The requester can submit a new request.
You can never approve your own signing request, even if you are listed as an approver for the current step. This is always enforced and cannot be disabled. (Pre-approving signing for yourself is allowed. It is an administrator action, not an approval of your own request.)

​
Revoking access

Administrators can revoke an active access record (or cancel a pending request) at any time. Hover the row on the Approvals tab; an X icon appears. Confirm in the dialog and:
  • Pending request cancels the workflow. No approver can act on it after that.
  • Active access is immediately revoked. Subsequent sign calls return 403 with a clear message.
In-flight sign calls already in progress complete normally; revocation is checked at request entry, not mid-operation. The row stays visible in Revoked status so the audit trail is preserved.

​
FAQ

The policy has more than one step and yours wasn’t the final step. Open the request to see which step is currently pending; the access record is issued only after the last step’s required approvals are reached.
Three possibilities:
  1. The Signer has no approval policy, so signing is direct and no request is needed.
  2. You already have active access. Sign directly under it.
  3. You don’t have sign permission. Check that your role on this Signer is Operator or Administrator (not Auditor).
Have an Administrator pre-approve access for that identity in advance with appropriate per-approval limits. The CI identity then signs under the access record directly without going through the review workflow.
No. Access records are immutable once issued. If you need more time or more signatures, submit a new request (or have an Admin pre-approve a new one) and revoke the old one if you want to be tidy.
Expired is automatic: the window ended or the signature count was reached. Revoked is explicit: an Administrator (or the requester via cancel) ended the access before its natural expiry. Either way, signing under it is no longer possible. The status difference shows up in the audit log.
If the error mentions your access being scoped to specific signing parameters, the request was scoped and your sign call does not match one of the declared values. Open the request to see the scope, and compare it against what you are signing with now: a different machine, tool, command, IP address, or payload is enough to be denied even when signatures remain. Either sign in the situation that was approved, or open a new request describing the one you need.
Pending requests run under the policy that was active when they were submitted. Edits affect only new requests. To force a refresh, revoke the pending request and have the requester submit again.

​
What’s next

Signers

Manage the Signer itself: members, certificate, lifecycle.

PKCS#11 Module

Have the module auto-open signing requests on denied calls.