An Ask policy pauses an action and requires a human decision before the action can complete. In agentic workflows, it is a runtime control that turns a tool call into a review point rather than a silent execution step.
What Ask Policy Does in an Agent Workflow
An ask policy inserts a human review point into an otherwise automated flow. Instead of letting the agent complete a tool call immediately, the workflow pauses and waits for approval, which makes the action explicit, interruptible, and auditable.
Why Ask Policy Exists
Ask policy is used when an action is important enough that automation should not be allowed to execute it silently. It creates a controlled pause for decisions that may affect data access, external side effects, cost, or irreversible changes, while still preserving the speed and context of agentic workflows for lower-risk steps.
In practice, the policy matters most when the agent is about to cross a trust boundary, modify state, or invoke a tool with meaningful consequences. It turns autonomy into supervised autonomy, which is often the right balance when the workflow is useful but not yet trusted end to end.
How Ask Policy Changes Runtime Behaviour
At runtime, ask policy changes the control flow, not the underlying intent of the agent. The agent can still plan and propose the action, but execution is deferred until a human confirms, rejects, or edits the request. That makes the approval itself part of the operating model, rather than an afterthought in a separate review process.
This distinction is important because a well-designed ask policy can be applied selectively. A workflow may allow harmless or low-impact steps to proceed automatically while reserving human approval for actions that touch production systems, sensitive data, money, or privileged operations.
Ask policy is therefore a governance mechanism as much as a technical one, because it defines which actions require human accountability and which do not.
Design Limits and Common Failure Modes
Ask policy is only effective when the pause is meaningful. If approvals are vague, overused, or too frequent, users may approve reflexively and the control becomes ceremonial. If the policy is too broad, it can also slow the workflow enough that people bypass it through workarounds or shadow automation.
The other common failure mode is inconsistent scope. If only some risky actions are gated, an agent may still reach the same outcome through a different sequence of allowed steps. That is why ask policy should be defined around the actual impact of the action, not just the surface API or tool name.
Risk and Threat Considerations
Ask policy reduces the blast radius of mistaken or malicious agent actions, but it also creates a decision point that can be manipulated. An attacker may try to shape the prompt, task context, or approval wording so the human reviewer sees the request as routine, time-sensitive, or harmless.
Failure mechanism: If the approval step is poorly framed, over-frequent, or easy to approve without scrutiny, it becomes a weak checkpoint rather than a real control. The agent can then convert a dangerous action into an apparently normal review event.
Impact: The organisation may approve unsafe tool use, privileged actions, or unintended side effects, especially when the human reviewer lacks enough context to evaluate the request accurately.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Ask policy governs when an agent may proceed with a privileged action. |
| ASI02 — Tool Misuse | Ask policy interrupts risky tool calls before they complete. | |
| Recommendation — Gate privileged agent actions behind human approval before execution. Require review before executing tool calls that can cause side effects. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management, Least Privilege, and Authorization | Ask policy is an authorization checkpoint for sensitive actions. |
| GV.RM-01 — Risk Management Strategy | Ask policy reflects a risk-based decision about when humans must approve automation. | |
| Recommendation — Apply authorization checkpoints to restrict high-impact actions to approved cases. Set approval thresholds based on the risk of the action being attempted. | ||
Practitioner Guidance
Governance implication: Define ask policy around the consequence of the action, not just the tool being called. The clearest policies are tied to actions that are materially sensitive, externally visible, or hard to reverse.
What to watch for: Review fatigue, repetitive approvals, and requests that are phrased too abstractly for a human to assess quickly. Those are signs that the policy is either too broad or not giving reviewers enough context to make a sound decision.
Practitioner takeaway: Ask policy works best as a narrow, high-signal control, not as a blanket substitute for least privilege or safer tool design.