Multi-Party Approvals for High-Risk AI Actions

Not every AI agent action should be automatically approved or denied. Some actions live in a middle zone where the risk is too high for automatic approval but the action is legitimate enough that outright denial is wrong. These actions need human review.

Intended calls this middle zone escalation. When a policy evaluation results in an ESCALATE decision, the action is held, a notification is sent to designated reviewers, and the action proceeds only when a human approves it. This sounds simple. The implementation details matter enormously.

Why Escalation Exists

Consider an AI agent that manages infrastructure. It has authority to deploy to staging without approval and is denied access to delete production resources. But what about deploying to production? Denying all production deployments defeats the purpose of having an automation agent. Allowing all production deployments is reckless. The right answer is: allow production deployments with human approval.

Escalation is the authorization outcome between allow and deny. It acknowledges that the agent might be making the right decision but that the stakes are high enough to warrant a human checkpoint.

Without escalation, organizations are forced into binary governance. Everything is either trusted or blocked. This leads to over-permissive policies (because teams need their agents to work) or over-restrictive policies (because security teams need control). Neither is correct.

Single-Approver Escalation

The simplest escalation pattern is single-approver. The action is held. One designated reviewer receives a notification. The reviewer approves or denies. The action proceeds or is permanently blocked.

In Intended, single-approver escalation looks like this in policy:

policy:
  intent: infrastructure.deployment.production
  decision: escalate
  escalation:
    type: single
    reviewers:
      - role: deployment-approver
    timeout: 30m
    timeout_action: deny
    notification:
      channels: [slack, email]

The `timeout_action` is critical. What happens if nobody reviews the escalation within 30 minutes? Intended defaults to deny. The action expires. The agent is notified that the escalation timed out. This prevents the queue from accumulating stale escalations that get rubber-stamped hours later when the context has changed.

When the reviewer receives the notification, they see the full context: the agent identity, the action being attempted, the risk scores, the policies that triggered the escalation, and the evidence bundle. They make an informed decision, not a blind approve/deny based on a one-line summary.

Multi-Party Approval

For the highest-risk actions, a single approver is not sufficient. Multi-party approval requires multiple independent reviewers to approve before the action proceeds.

policy:
  intent: financial.transfer.international
  decision: escalate
  escalation:
    type: multi-party
    required_approvals: 2
    reviewers:
      - role: finance-approver
      - role: compliance-officer
      - role: department-head
    timeout: 2h
    timeout_action: deny

In this configuration, an international transfer requires two approvals from the pool of three reviewer roles. Any two of the three can approve. If either of the first two reviewers denies, the action is permanently blocked without waiting for the third reviewer.

Multi-party approval prevents collusion and single points of failure. A compromised approver account cannot unilaterally approve a high-risk action. An approver having a bad day cannot rubber-stamp something that should be blocked. The second reviewer provides an independent check.

Intended tracks which reviewers have approved and denied, ensuring that the same person cannot approve twice. The approval chain is recorded in the audit trail, so compliance teams can see exactly who approved what and when.

Delegation Chains

In real organizations, the designated approver is not always available. They are in a meeting. They are on vacation. They are in a different time zone. Delegation chains handle this by defining fallback approvers.

policy:
  intent: data.customer.bulk-export
  decision: escalate
  escalation:
    type: single
    delegation:
      primary: user:alice@company.com
      fallback_after: 15m
      secondary: role:data-governance-team
      fallback_after: 30m
      tertiary: role:engineering-directors
    timeout: 1h
    timeout_action: deny

The escalation goes to Alice first. If Alice does not respond within 15 minutes, it broadens to anyone on the data governance team. If nobody on that team responds within 30 minutes, it escalates further to engineering directors. If nobody responds within an hour, the action is denied.

Delegation chains prevent escalation queues from becoming blockers. The action always has someone who can review it, and the fallback is automatic. The full delegation chain is recorded in the audit trail.

Conditional Approval

Sometimes approval should come with conditions. A reviewer might approve a deployment but require that it uses canary mode. A reviewer might approve a data export but require that PII fields are masked. Intended supports conditional approval where the reviewer attaches conditions to their approval.

The conditions are enforced by the authority runtime. If the reviewer approves a deployment with the condition "canary required," the authority token includes that condition. The agent or the deployment system must verify and fulfill the condition. If the condition is not met, the token is invalid.

This prevents the common pattern where an approver says "yes, but only if..." and the "but only if" gets lost. The condition is cryptographically bound to the approval. It cannot be separated or ignored.

Escalation Analytics

Over time, escalation patterns reveal important information about your governance configuration. Intended tracks escalation metrics including:

• Average time to review by reviewer, intent type, and time of day
• Approval rate by intent type (if 99% of escalations for a given intent are approved, maybe that intent should be auto-approved)
• Denial rate by reviewer (if one reviewer denies significantly more than others, the policy might need adjustment)
• Timeout rate by intent type (if escalations frequently time out, the reviewer pool might be too small or the timeout too short)
• Delegation frequency (if escalations frequently fall to the tertiary reviewer, the primary might need to be reassigned)

These analytics feed back into policy tuning. Organizations that start with aggressive escalation policies (escalate everything) can use the data to identify which intents are safe to auto-approve, narrowing the escalation scope to truly high-risk actions.

The Human Experience

Escalation only works if humans actually review escalations. That means the review experience must be fast, informative, and low-friction.

Intended escalation notifications include a one-click approve and deny interface. The reviewer does not need to log into a dashboard, find the escalation, read through a form, and click three buttons. They receive a Slack message or email with the full context and two buttons: approve and deny.

The context includes the agent identity, the specific action being attempted, the risk scores with explanations, the policies that triggered the escalation, the agent's recent activity (to check for anomalies), and any relevant historical decisions for similar actions.

The reviewer should be able to make an informed decision in under 30 seconds. If the review takes longer, the context presentation needs improvement, not the reviewer.

Designing Your Escalation Strategy

Start broad and narrow. Begin by escalating more actions than you think you need to. Review the escalation analytics after a week. Identify the intents where you approve 100% of escalations. Move those to auto-approve. Identify the intents where you deny 100% of escalations. Move those to auto-deny.

The steady state should be that escalated actions are genuinely ambiguous: actions where human judgment adds real value. If your escalation queue is full of obvious approvals, your policies are too restrictive. If your escalation queue is empty, your policies might be too permissive.

Escalation is not a sign of an immature governance system. It is a sign of a governance system that knows its limits. Some decisions should not be made by machines. The authority runtime's job is to make the easy decisions automatically and route the hard decisions to humans, with full context, so the humans can make good decisions quickly.