An AI agent can make a perfectly valid API call and still create a production incident. The syntax may be correct, the credentials may be valid, and the permission may be allowed — but the action can still be wrong for the current workflow, environment, or business context.
That is the gap policy-as-code for AI agents is starting to address.
The New Risk: Valid, Authorized, and Still Wrong
As AI agents move from demos into real engineering workflows, they are gaining access to tools developers already use every day: CI/CD systems, cloud consoles, ticketing platforms, observability dashboards, incident management tools, and internal developer portals.
In traditional DevOps, we usually reason about access in terms of identity and permissions. Can this service account deploy to production? Can this user restart a Kubernetes workload? Can this automation open a pull request, merge code, or modify infrastructure?
Those checks are necessary, but they are no longer sufficient.
An agent might be authorized to call a deployment tool. The deployment API request might be well-formed. The target service name and environment might be valid. But the deployment could still be unsafe if it happens during an active incident, skips a required canary step, violates a change freeze, targets the wrong region, or rolls forward a version that failed integration tests.
This is the distinction The New Stack captured in its coverage of AWS Dogwood: an AI agent’s next tool call may be valid, but wrong. AWS has launched Dogwood as an open-source policy language and reference interpreter designed to govern sequences of AI agent tool calls, not just isolated API requests.
That shift matters for every team adding agents to production-adjacent workflows.
Why Tool-Level Permissions Are Not Enough
Most engineering organizations already have some combination of IAM, RBAC, service accounts, API tokens, approval workflows, and environment-level permissions. These controls answer important questions:
- Who is making the request?
- What system are they allowed to access?
- What operation can they perform?
- Which resource can they modify?
Agentic workflows introduce another question: should this action happen now, given what happened before and what should happen next?
That question is fundamentally about sequence and context.
For example, an AI agent operating in a CI/CD pipeline might perform this sequence:
- Read a pull request
- Summarize the change
- Trigger tests
- Detect a flaky failure
- Re-run the pipeline
- Approve the deployment
- Promote to production
Each individual tool call may be valid. But the sequence may be unacceptable if the agent treats a flaky test as a pass, approves its own change, bypasses required human review, or deploys during a restricted window.
The same problem appears in incident response. An agent may be allowed to restart services, scale workloads, or roll back releases. But should it restart three dependent services at once? Should it roll back a database migration after writes have occurred? Should it page another team before changing a shared infrastructure component?
Traditional API authorization does not usually model those workflow-level constraints. Policy-as-code can.
What Dogwood Adds to the Conversation
AWS Dogwood is significant because it focuses on governing sequences of AI agent tool calls. Instead of treating agent actions as independent API invocations, Dogwood is designed around the idea that safety often depends on the path an agent takes through a workflow.
That is a natural extension of policy-as-code practices many DevOps teams already use. Tools such as Open Policy Agent, HashiCorp Sentinel, Kubernetes admission controllers, and CI/CD release gates have trained teams to encode operational rules as testable, reviewable policy instead of relying only on tribal knowledge or manual approvals.
Dogwood brings that mindset closer to agent execution.
The key idea is not simply to ask whether an agent can call a tool. It is to ask whether the call is allowed in the current state of the workflow. Has the agent gathered enough evidence? Has it satisfied preconditions? Is it attempting an action out of order? Is the target environment protected? Has a required approval or verification step occurred?
That is especially important because AI agents are probabilistic planners. They may choose plausible next steps that look reasonable locally but violate broader operational rules. A human SRE may know that a production rollback requires checking database compatibility first. An agent may not, unless the workflow policy explicitly requires it.
Examples: Where Valid Calls Become Unsafe
CI/CD and Release Automation
Consider an agent that helps manage releases. It can inspect pull requests, update changelogs, trigger builds, and deploy services. All of those capabilities are useful.
But unsafe behavior can emerge quickly:
- Deploying a service when its dependency has not been upgraded
- Promoting a build that passed unit tests but skipped security scans
- Merging a dependency update without checking runtime compatibility
- Deploying outside an approved release window
- Releasing to all regions instead of starting with a canary
Policy-as-code can define the release path: tests must pass, vulnerabilities above a threshold must be resolved or approved, canary metrics must be healthy, and production promotion must happen only after an explicit gate.
Incident Response
Agents are attractive for incident response because they can summarize alerts, correlate logs, recommend mitigations, and automate repetitive actions. But this is also where mistakes are costly.
A restart command may be valid. Scaling a deployment may be valid. Disabling a feature flag may be valid. The danger is choosing the wrong action at the wrong time.
Policies can require agents to operate within bounded playbooks: gather diagnostics before remediation, avoid destructive actions without approval, limit the blast radius of automated changes, and trigger rollback if health metrics worsen.
Cloud Operations and Infrastructure Changes
In cloud operations, agents may help resize resources, clean up unused infrastructure, rotate credentials, or update network rules. Again, the problem is rarely syntax. The problem is context.
A valid infrastructure change might expose an internal service, delete a resource still used by a legacy workload, or modify a shared role used by multiple systems. Policy-as-code can enforce dependency checks, tagging requirements, ownership metadata, and staged rollout rules before allowing the agent to proceed.
Connecting Agent Governance to Modernization
For companies modernizing legacy systems, AI agents are often positioned as accelerators. They can analyze old codebases, generate migration plans, open pull requests, update dependencies, and automate repetitive maintenance tasks.
That is valuable, but modernization work is full of hidden coupling. Legacy services may depend on undocumented APIs, outdated runtime behavior, fragile deployment scripts, or manually maintained configuration. An agent can produce a technically valid change that breaks an operational assumption nobody encoded.
This is where platforms such as Vibgrate fit into the broader engineering picture. Software maintenance and modernization are not just about making changes faster; they are about making safe, observable, reversible changes at scale. If agents are going to participate in upgrades, refactoring, dependency remediation, or platform migration, they need guardrails that reflect how the system actually operates.
Policy-as-code provides a durable way to encode those guardrails. Instead of relying on every developer or agent prompt to remember release rules, teams can make the rules executable, version-controlled, and auditable.
Lessons from Adjacent DevOps Trends
The Dogwood discussion also lines up with broader trends in production AI and cloud-native operations.
InfoQ’s coverage of runtime-agnostic AI workflows points to a related need: durable workflow design that can evolve quickly without binding every decision to a single runtime. That principle applies to governance too. Agent policies should be portable enough to survive changes in orchestration frameworks, model providers, and internal platforms.
Similarly, discussions around running AI agents on Kubernetes often distinguish between agents as intelligent planners and pods as operational units. That separation matters. Kubernetes can schedule workloads, enforce resource limits, and isolate execution, but it does not automatically know whether an agent’s planned sequence is safe for a business-critical release.
Security incidents such as cloud control-plane exposures also remind teams that credentials and permissions are only part of the story. Stronger runtime governance, auditability, and blast-radius control are essential when automation can act quickly across many systems.
Practical Implications for Engineering Teams
1. Treat Agent Actions Like Production Changes
If an agent can deploy, modify infrastructure, change configuration, or affect incident response, its actions should be governed like any other production change. That means reviewable policies, logs, approvals, and rollback plans.
Do not treat agent tool calls as harmless because they are generated through a conversational interface. A tool call is an operational action.
2. Define Workflow-Level Policies, Not Just Permissions
Start by mapping the workflows where agents operate. For each workflow, define required preconditions, allowed sequences, approval points, and stop conditions.
For example:
- A production deployment must follow successful tests, security checks, and canary validation.
- An incident remediation action must be tied to an active incident record.
- A dependency upgrade must include compatibility checks and rollback instructions.
- A database-affecting change must require human approval.
These policies should be explicit and testable.
3. Apply Least Privilege to Tools and Sequences
Least privilege should apply at two levels. First, agents should have access only to the tools and resources they need. Second, they should be allowed to use those tools only in approved sequences.
An agent that can read logs does not necessarily need permission to restart services. An agent that can deploy to staging does not automatically need production promotion rights. An agent that can propose a rollback may still need a human to execute it.
4. Make Agent Decisions Auditable
Every meaningful tool call should produce an audit trail: what the agent observed, what it attempted, which policy allowed or denied the action, and what happened afterward.
This is essential for incident reviews, compliance, and continuous improvement. If an agent makes a poor recommendation or attempts an unsafe action, teams need to understand whether the issue was missing context, an insufficient policy, a flawed workflow, or excessive permissions.
5. Design for Automated Rollback
Agent governance should not stop at prevention. Production systems need recovery paths. If an approved agent action causes error rates to spike or latency to degrade, automated rollback should be available where possible.
That means pairing agent policies with observability signals, deployment health checks, and progressive delivery practices.
A Good Starting Checklist
Engineering leaders evaluating agents in DevOps workflows can start with a simple checklist:
- Which tools can the agent call?
- Which environments can it affect?
- What sequences are explicitly allowed?
- What actions require human approval?
- What telemetry determines success or failure?
- What is the rollback path?
- Where are policies versioned and reviewed?
- How are denied actions logged and analyzed?
If those questions are difficult to answer, the agent is probably operating with too much implicit trust.
Conclusion: Safer Agents Need Operational Memory
AI agents will become more common in CI/CD, incident response, cloud operations, and internal developer platforms. The productivity upside is real, especially for teams maintaining and modernizing complex software estates.
But production safety depends on more than valid syntax and authorized credentials. Agents need operational memory: an understanding of sequence, context, policy, and consequence. AWS Dogwood is an important signal that the industry is moving toward policy-as-code designed specifically for agent workflows.
The teams that succeed with agents will not be the ones that automate everything first. They will be the ones that encode their engineering judgment into durable controls, making automation faster, safer, and easier to trust.