Approve sensitive governance changes

Some control-plane actions expose evidence, change financial limits, or reveal sensitive data. DVARA Flightdeck holds these actions until a second authorized person approves the exact change.

Enterprise only

Not included in DVARA Open Source.

Which actions need a second person?

The gate is always on for these Flightdeck actions:

Action	Who can request it	Who can approve it
Export audit events	A user who can view the audit trail	A different user who can resolve approvals
Create, materially change, or delete a budget cap	A user who can manage budgets	A different user who can manage budgets
Detokenize PII	A user who can manage PII	A different user who can manage PII
Purge stored PII tokens	A user who can manage PII	A different user who can manage PII

Policy promotion has its own approval flow. MCP and A2A approval gates govern request-path actions rather than Flightdeck changes. See Agentic governance for those gates.

Request and complete an approval

1. Start the action from its normal Flightdeck page and enter a reason.
2. Reauthenticate if your interactive sign-in is more than 10 minutes old.
3. Ask a different authorized user to open Governance → Approvals and approve or deny the request with a decision reason.
4. Return to the original action and execute it before the approval expires.

An approval expires 15 minutes after it is requested. The original requester must execute it; the approver cannot execute it on the requester's behalf.

The approval is bound to the exact workspace, target, action type, and submitted values. If any of them change, Flightdeck refuses the execution and asks for a new approval. An approval can be executed once.

An approval does not run the action

Approval only authorizes the submitted action. The original requester must return and execute it before the 15-minute window closes.

Verify the decision and execution

Open Governance → Audit and filter by the approval ID. A completed action writes separate events for the request, decision, start, and result:

SENSITIVE_ACTION_REQUESTED
SENSITIVE_ACTION_APPROVED
SENSITIVE_ACTION_EXECUTION_STARTED
SENSITIVE_ACTION_EXECUTED

A denial writes SENSITIVE_ACTION_DENIED. The audit payload identifies the action type, approval ID, actor, and a digest that binds the approved scope. It does not copy PII, export contents, or the submitted form into the approval record.

If execution fails, correct the underlying problem and retry with the same approved request while it remains valid. If the scope changes or the approval expires, request a new approval.