An AI agent piloted for internal helpdesk queries shows strong capability. However, every time it interacts with an external service, a confirmation dialog asks: "Allow this operation?" An operator who carefully reviewed each prompt during week one begins approving them blindly by week three.
This is not employee negligence; the approval design simply collapsed under the volume of requests. If you present dozens of prompts daily with virtually identical context, people will rubber-stamp them. And once rubber-stamping starts, confirmation ceases to function as a safeguard.
The discussion around reducing endless confirmations took a step forward with an approach released in August 2026. The core idea shifts policy evaluation granularity from "individual actions" to "sequences of actions."
Risk patterns invisible to isolated evaluations
Most current authorization models evaluate requests individually, returning either an allow or deny. While clear and fast, this approach is structurally incapable of assessing risks that arise when individually benign operations are chained together.
Consider the following three operations, each routine in daily business operations:
- Query a list of customers
- Compile query results into a spreadsheet
- Email the file to an external address
An evaluation engine looking at individual requests can only ask on step three: "Does the agent have permission to send files?" The fact that the file contains the customer list just retrieved lies outside the evaluation scope. What a human operator would immediately spot—"Wait, are you sending that list outside the company?"—is completely overlooked.
The same vulnerability applies to monetary limits. Even with a per-transfer cap of 100,000 yen, executing twelve 80,000-yen transfers will succeed if frequency and cumulative totals go unmonitored. As discussed in Auditability in AI Agent Development, being able to review logs after the fact is entirely different from halting an action in real time.
Conditioning policies on past actions is now possible
Dogwood, open-sourced by AWS in August 2026, directly addresses this gap.
Positioned as a temporal extension to the Cedar authorization language, Dogwood enhances decision-making. While Cedar evaluates "should this specific request be allowed right now?", Dogwood can reference prior tool calls and responses within an agent session to decide whether to authorize the current action. It is licensed under Apache 2.0 and maintains backward compatibility with Cedar.
The types of conditions that can now be expressed include:
- Execution order — Requiring specific operations to be completed before advancing to the next
- Human approval gates — Authorizing actions only when a record of human approval exists
- Argument matching — Verifying that approved parameters match the parameters being executed
- Data freshness — Blocking operations that rely on information fetched beyond a specified time limit
- Cumulative thresholds — Enforcing aggregate caps on amounts or frequencies across concurrent requests
The third condition, argument matching, sounds minor but is vital in practice. Discrepancies between what was presented on an approval screen and what actually executed represent an immediate risk whenever human-in-the-loop controls are introduced.
Approvals start working when approval frequency drops
The fundamental benefit of writing such conditions is drastically reducing the volume of approval prompts.
If the policy engine verifies that operations follow the correct order, match approved arguments, and stay within cumulative limits, humans no longer need to review those steps. Human attention is reserved exclusively for the few situations machines cannot evaluate. When thirty daily prompts drop to three, those three will actually be read.
Conversely, piling on human approvals without cutting confirmation volume appears to increase safety while actually degrading it. When consulting on internal AI agent adoption, this is the first issue to address. While we summarized the broader roadmap in Adopting AI Agents for Business Operations, approval architecture is often the most neglected component.
How to evaluate adoption
Maintaining an accurate sense of maturity is essential.
While Dogwood is available within Amazon Bedrock AgentCore Policy, its public reference implementation is explicitly designated for testing and experimentation, not production deployment. It is not ready to be dropped into production infrastructure tomorrow.
What is actionable today boils down to two key steps.
First, for agents currently in development or planned, identify whether your business faces risks that per-request evaluations cannot catch. If an agent touches customer data, monetary transfers, external transmissions, or contractual agreements, this applies to you.
Second, explicitly specify approval architectures in procurement requirements. Commissioning custom development with only a vague requirement like "critical actions require human approval" leads to per-action confirmation dialogs. That directly recreates the original problem. Your requirements must define both the conditions that trigger approval prompts and the conditions that bypass them.
What clients should decide upfront
Clarifying these three points internally before requesting vendor estimates accelerates the project significantly.
First, list operations the agent must never perform. Authorization design holds up far better when you decide what is strictly forbidden before defining what is allowed.
Second, determine operations requiring human approval and assign designated approvers. If approvers are not specified, whoever happens to be around will end up clicking approve.
Third, define metrics requiring cumulative limits. Monetary amounts, transaction volumes, and external data transfer sizes. Specifying which metrics need cumulative monitoring prevents surprises during implementation.
These three items represent business policy decisions, not technical dilemmas. Because only the commissioning client can decide them, leaving them blank forces developers to default to conservative assumptions. This inflates confirmation frequency and turns approvals into mere formalities.
What to do next
For AI agents running or piloting in your company, count how many confirmation prompts appear across a standard workflow. If the daily count reaches double digits, those prompts will soon be ignored.
Next, verify whether the agent touches any of the four critical areas: customer data, monetary transfers, external transmissions, or contractual agreements. If it touches them and triggers double-digit prompts, it is time to redesign your approval architecture.
GleamHub provides AI, development, and automation consulting to assist with agent permission design, approval workflow reviews, and system integration implementations. Because architectural scope and effort vary by the number of connected services and data sensitivity, we provide custom estimates. Inquire through our Contact Us page.
Sources
- AWS Open-Sources Dogwood, Extending Cedar to Govern Sequences of Agent Tool Calls — InfoQ
- Introducing Dogwood: runtime verification for AI agents — AWS Open Source Blog
- Securing AI agents with temporal policies in Amazon Bedrock AgentCore — AWS Machine Learning Blog
- A Prescription for AI Agent "Authorization Fatigue": From Theory to Implementation — Zenn (AWS Japan)
