Power Automate Approval vs Runtime Approval for Copilot Studio Agents

Treat supervision as an examiner-evidence problem

Financial services teams building Copilot Studio agents need to show that consequential agent actions were reviewed by a human before they took effect. FINRA's 2026 Annual Regulatory Oversight Report lists AI agents acting autonomously without human validation and approval as a risk, and it refers to formal review and approval processes for generative AI. A separate FINRA Regulatory Notice reminds members of their regulatory obligations when using generative AI and large language models. Whether the firm's own procedures are met is the firm's determination, and compliance and legal teams own it.

For an architect, the practical consequence is that an approval must be demonstrable. An examiner reviewing a supervised agent action will want to see who approved what, when, and whether the action could have happened without that approval. A control that looks like supervision but leaves an unsupervised path to the same action is the gap to avoid. That is why the placement of the approval matters more than the existence of an approval screen.

Where Power Automate approvals fit well

A Power Automate approval step is a natural choice for business process approvals. If the organization already routes requests through established flows, with known approvers, notifications and escalation habits, then having an agent start one of those flows reuses a familiar mechanism. Approvers work in tools they already know, and business owners can adjust the flow without touching the agent.

This pattern suits decisions that are about a business request rather than a single tool call: approving a customer communication template, a policy exception, or a new request type. The approval is a step in a process, and the process is what the firm supervises.

The design question is the relationship between the agent and the flow. The agent is configured to call the flow. If the action being protected can also be reached by another route, or if the agent's configuration changes so the flow is no longer invoked, the approval is only as strong as that configuration. Architects should confirm that the flow is the only path to the consequential action, not an optional one beside it.

Where inline runtime approval is the stronger fit

Inline runtime approval places the decision in the execution path. The agent can propose an action, but a policy component independently checks scope, privilege and approval state before the action executes. This follows the separation of proposing from executing that OWASP's agent security guidance recommends. Because the check sits where the call is made, the agent cannot proceed by choosing not to ask.

The guidance also sets out what a sound approval looks like. A simple confirmed flag is insufficient. The approval should belong to the current actor and the exact tool call, remain valid, and be consumed atomically so concurrent or repeated requests cannot reuse it. A change to the target or parameters should require new approval. Unknown tools or missing approval requirements should fail closed.

This is the model Trussed implements: policy enforcement in the execution path that can allow, redact, block, or escalate for human approval on individual interactions and tool calls, producing audit-ready evidence. The enforcement is at runtime, not reviewed after the fact. Any inline option should be assessed against the criteria below, whatever the vendor.

Side-by-side comparison

The table compares the patterns as designs. Specific products differ, so each row is a question to test against the implementation under review.

• Enforcement point: Workflow step: a flow the agent is configured to call. Inline runtime: the path that executes the tool call.
• Bypass risk: Workflow step: depends on whether the action is reachable without the flow. Inline runtime: the executing component checks approval state before the action runs.
• Scope of approval: Workflow step: typically a business request. Inline runtime: the specific interaction or tool call and its parameters.
• Approver context: Workflow step: whatever the flow presents. Inline runtime: the actual action, so the approver is not relying only on the agent's own explanation.
• Evidence produced: Workflow step: a decision record, whose link to the agent action must be verified. Inline runtime: a record tied to actor, tool, target and parameters.
• Operational fit: Workflow step: established processes and existing approvers. Inline runtime: high-consequence tool calls needing per-action control.

Approver context and the limits of human review

A human approval is only as good as the information the approver sees. The OWASP Top 10 for Agentic Applications describes cases where confident, polished explanations misled operators into approving harmful actions, and it labels this human-agent trust exploitation. An approval request that shows the agent's narrative but not the underlying action invites that failure.

For supervisory purposes, the approver should see the actual tool, target and parameters, not only a summary. Supervisory procedures should also address approver training and the quality of the information presented. Neither pattern fixes this by itself. A flow-based approval can show the right details if it is built to. An inline approval can show them by construction, because it sits at the call.

The same applies to regulation. Neither pattern alone constitutes FINRA compliance. As of November 2026, the firm remains responsible for its supervisory system, its written procedures, and for confirming which rules apply to each agent action, including Rule 3110.

A neutral decision framework

Start by classifying agent actions. Financial, administrative and externally visible actions are the ones that warrant approval; applying approval uniformly adds friction without adding supervision. For each consequential action, ask three questions. Can the action be reached without the approval? Does the approval bind to this action and these parameters? Can the firm produce the evidence for a reviewer without reconstructing it?

Where the answers are yes, yes and yes under an existing flow, a Power Automate approval can be a defensible part of the control, particularly for process-level sign-off. Where the action is a tool call that takes effect immediately, or where the agent could reach the action by another route, inline runtime approval gives a stronger enforcement point. Many firms will use both, with flows for business processes and runtime approval for tool-level control.

Test negative paths before relying on either: an unknown tool, a missing approval requirement, changed parameters after approval, and repeated execution under one approval. Then map the result to the firm's written supervisory procedures. The mapping is the firm's work, and the architecture only has to make it possible.