Govern sensitive changes with approvals
A policy activation can change live traffic, a budget change can alter a financial control, and a PII operation can reveal or destroy protected data. DVARA Flightdeck requires two people for these changes so one signed-in user cannot request and authorize the same sensitive action.
Not included in DVARA Open Source.
This approval lane governs human changes in Flightdeck. It is separate from MCP and A2A approvals, which pause tool calls and agent actions on the request path.
Know which changes need approval
The approval gate is always on. It is not an organization setting and cannot be disabled.
| Change | Requester | Approver | When it takes effect |
|---|---|---|---|
| Activate a policy | A person who can manage the policy in its scope | A different person who can manage that policy | The approval activates the exact reviewed version |
| Create a budget | A person who can manage budgets in that scope | A different person who can manage budgets there | The requester executes the approved creation |
| Change a budget's period, hard limit, or enabled state | A person who can manage budgets in that scope | A different person who can manage budgets there | The requester executes the approved change |
| Delete a budget | A person who can manage budgets in that scope | A different person who can manage budgets there | The requester executes the approved deletion |
| Export audit evidence | A person who can view the selected evidence | A different person authorized to resolve governance approvals | The requester downloads the approved result |
| Detokenize PII in Flightdeck | A person who can manage PII in that workspace | A different person who can manage PII there | The requester executes the approved reveal |
| Purge stored PII tokens in Flightdeck | A person who can manage PII in that workspace | A different person who can manage PII there | The requester executes the approved purge |
Changing only a budget's name or soft-limit percentage does not require approval. The period, hard limit, and enabled state are material because they change when the cap applies or whether it can stop spend. Creation and deletion are always material.
Request a sensitive change
Start on the page where you normally perform the action. Review the values, enter a reason, and submit the approval request. Flightdeck records the exact action, workspace, target, version, and values being requested.
If your last interactive sign-in was more than 10 minutes ago, Flightdeck asks you to sign in again. This check proves that the person behind the session is still present; having an older open browser session is not enough.
The request stays pending for 15 minutes. This short window keeps an unattended approval from becoming a standing authorization that can be used later.
Review and decide as the second person
The approver opens Governance → Approvals, checks the scope and proposed values, and records an approval or denial with a decision reason. Flightdeck requires a recent sign-in here as well.
The approver must be a different authenticated person, not merely another browser or authentication method used by the requester. They must also still hold the capability and workspace access required for the action. These checks make the second review a real separation of duties rather than a second click.
Denial closes the request and leaves the policy, budget, export, or PII store unchanged. The requester must submit a new request if the team later decides to proceed.
Complete an approved action
Policy activation and the other protected actions complete differently.
Activate an approved policy
For policy activation, the approver's Approve action activates the exact policy version shown in the review. The requester does not return for a separate execution step. Flightdeck validates the policy again before activation so a stale or invalid version cannot enter live enforcement.
Execute an approved budget, export, or PII action
For a budget change, audit export, detokenization, or purge, approval grants permission but does not perform the operation. The original requester returns to the action and executes it before the 15-minute approval expires. Flightdeck checks the requester's recent sign-in again at execution.
The approver cannot execute on the requester's behalf, and the approval works once. Splitting decision from execution preserves a clear record of who asked, who authorized, and who completed the operation.
Except for policy activation, the original requester must return and complete the approved action before the 15-minute window closes.
What happens when the protected values change?
Flightdeck binds approval to the values the approver reviewed. It refuses the action when those values no longer match.
| Change after the request | Result |
|---|---|
| The policy has a different version | The policy is not activated; reload it and request approval for the current version |
| A budget field, version, target, or workspace changes | Execution is refused; submit a new request containing the intended values |
| The audit plane, workspace, event filter, time range, or format changes | The export is refused; request approval for the new selection |
| The PII input or purge workspace changes | The operation is refused; request approval for the new scope |
| The approval expires, is denied, or has already been used | Nothing runs; create a new request if the action is still needed |
This binding prevents a harmless-looking request from being approved and then changed into a broader or more destructive operation. It also prevents an old approval from authorizing a resource that changed in another session.
Follow the approval lifecycle
| State | What it means | What you do next |
|---|---|---|
| Pending | The request is waiting for a different authorized person | Review it before its 15-minute deadline |
| Approved | The exact request is authorized | For non-policy actions, the requester executes it before expiry |
| Executing | A non-policy action has started | Wait for its result; do not submit it again |
| Executed | The approved operation completed | Verify the resulting resource and audit evidence |
| Denied | The reviewer refused the request | Read the decision reason and submit a new request only if appropriate |
| Expired | The 15-minute lifetime ended | Review the current values and create a new request |
If execution fails before the protected change completes, fix the underlying problem and retry while the approval is still valid and its scope is unchanged. Changing the request or waiting past expiry requires a new approval.
Verify the audit evidence
Open Governance → Audit and filter by the approval ID. A general sensitive action records the request, approval or denial, execution start, and completed execution as separate linked entries. Policy activation records its request and approval or denial; the approval entry is also the point at which the exact policy version becomes Active.
The completed operation writes its normal evidence too, such as
BUDGET_CAP_CREATED, BUDGET_CAP_UPDATED, BUDGET_CAP_DELETED,
PII_DETOKENIZE_REQUESTED, or PII_TOKENS_PURGED. This lets you follow the
approval history and then verify the resulting domain change.
The approval evidence identifies the approval, action, actors, and a digest of the approved scope. It does not copy revealed PII, exported evidence, or full form contents into the approval record. DVARA HMAC-signs and hash-chains these records so later edits, removals, insertions, and reordering are detectable.