You’re reading an issue of “The AI Economy,” my newsletter exploring the forces shaping the AI era—tracking how AI is rewriting business, work, technology, and culture. Subscribe to get expert insights and curated updates delivered straight to your inbox.
You’ve tasked your AI agent to process vendor payments on your behalf. An invoice arrives one day, and the agent autonomously handles the transaction. It runs like clockwork—until the morning you find your bank account overdrawn. Digging in, you discover payments to vendors who never submitted an invoice and, in a few cases, never delivered anything at all. In truth, the agent never broke a single rule: Every payment, examined on its own, was authorized. The problem wasn’t with any one transaction. It was the pattern, one that the system couldn’t see.
A New Authorization Policy Language
On Thursday, Amazon Web Services released Dogwood, an open-source policy language for writing rules that can catch this kind of failure. The gap it closes is a mismatch: agents remember everything they’ve done, but the checkpoint approving each action considers nothing that came before. Dogwood aims to end the amnesia at the checkpoint. Its rules can hinge on sequence, timing, and running totals—anything where the right answer depends on what already happened. Require an invoice before a payment goes out. Cap what an agent spends in a day. Block the big step until a human signs off.
Those rules sound simple to put in place. They’re not. “These are things that are really not possible to cleanly express in the authorization languages that we have today,” said Marc Brooker, an AWS vice president and distinguished engineer, in an interview with The AI Economy. Before Dogwood, he explained, “the traditional way to think about it…is you look at each action, each tool call, each step in isolation, and [ask], ‘is this good or not?’” That model is powerful, Brooker acknowledged—decades of authorization are built on it—but he called it “incomplete” because “often the answer to ‘can I do this now?’ depends on what has come before.”
If “authorization” makes you think of OAuth—the technology powering Google’s and Slack’s sign-in protocol—this is different. Those flows grant access: you click a button once, and an app gets permission to act for you. That works because a human is present for the decision. An agent burns through hundreds of decisions an hour, and nobody is going to sit there clicking “approve” on every one—the entire point of an agent is that you don’t have to. So the approval has to be written down in advance, as rules a machine can check in milliseconds, every time, without asking you. That’s what an authorization policy language is for, and it’s why the rules need mathematical precision.
Writing permission rules isn’t new—developers could always write them using general-purpose languages like Python, Java, or Rust. However, according to Brooker, doing it that way carries too many ways to fail. “In the world of authorization, being easy to reason about is super valuable,” he said.
Extending Cedar
AWS already has an authorization policy language called Cedar, which it open-sourced in 2023. Brooker described it as “smartly designed” to be “analyzable,” meaning you’re able to prove exactly what a set of rules will and won’t allow before they ever run. Still, he said that Cedar is one-shot authorization that’s not designed to express temporal questions like order, time windows, and counts over time cleanly.
Dogwood’s answer is to use something called temporal logic—a branch of mathematics for reasoning about time and order—which lets the rules check what already happened before saying yes. For example, teams can now write rules for when a file can be deleted (“has a second copy been made?”), whether an agent has permission to withdraw money (“has finance approved it?”), or whether it can spend another $10 (“has it hit its limit for the day?”). Dogwood embeds Cedar rather than replacing it. Brooker described it as two threads converging. Customers needed a way to spell out what agents are allowed to do, in what order, and how often. At the same time, new mathematical tools emerged that let AWS build that added power without giving up the thing Cedar was prized for: the ability to prove exactly what a policy will and won’t allow.
The Pitch to Developers AI Agents
AWS has released Dogwood under an Apache 2.0 license. By doing so, it hopes developers not only adopt it but help improve it. “We want to invite the world to use Dogwood and build it into products, other open source projects, into their agents,” Brooker said. “By open sourcing it, we say to the world, ‘here is something that you can use, integrate, bring into your projects’ and the more widely a language like Dogwood is used, the more valuable it is to people, the more AI models are going to learn how to write great Dogwood policies, [and] the more developers are going to be familiar with it.”
If your reaction is “great, another language to learn,” Brooker’s answer is that you probably won’t have to. If you’re building agent harnesses, services, and frameworks, you’d likely be the ones who go deep. “But that’s not the majority of developers today,” he said. “The majority…are working at a level up. They maybe are building agents, using a framework like Strands, building on something like AgentCore. Those sets of developers are either going to be writing policies in the Dogwood language, or even more commonly, are going to be asking their AI agents to turn common sense natural language statements into Dogwood policies.”
AWS said that temporal policies are enforced at the gateway layer—the single doorway agent traffic passes through—and outside the AI agent’s own code. In fact, the agent won’t see the policy logic, so no amount of clever prompting talks its way past. The company added that all decisions are deterministic, denied by default, and logged with the full context.
For teams that don’t want to assemble the pieces themselves, AWS has also incorporated temporal rules into AgentCore Policy, AWS’s hosted authorization product, with the compiler and state-tracking built in. Also, now generally available, the company has enabled rate limiting in AgentCore’s gateway, letting teams cap what any user or agent consumes in requests, tokens, and connection time. AWS said that rate limits take effect immediately after being configured, with no changes to agent code needed.
Curbing the ‘Persistent Problem-Solvers’
Dogwood arrives at an opportune moment. Agents are being handed longer tasks with less supervision, and businesses are increasingly uneasy about what they do unwatched. Brooker described agents as “persistent problem solvers.” “You block off one way of doing something, and they will find another way to do it,” he said. “This is what we love about agents, but it is also what makes them challenging to govern in some ways.”
Brooker said organizations can contain agents by running them inside a micro virtual machine like AWS’s AgentCore Runtime, which walls the agent off from everything around it. But an agent sealed off completely is useless. “For an agent to be useful, it has to get out,” he said. “It has to be able to do some things in the world. That’s why I’m paying for an agent, is so it can do some work on my behalf.” That gap—between containment and usefulness—is what policy exists to close.
