Accountability remains with the team that defined the workflow and granted the agent execution authority. A machine actor can propose or execute changes, but it cannot own the governance model around sequencing, validation, and rollback. That responsibility sits with the programme that allowed the actor to act.
Why This Matters for Security Teams
Bad migration decisions made by an agentic tool are not just a tooling defect. They are a governance failure because the agent acted inside a permission model that someone configured, approved, and allowed to execute. The practical issue is that autonomous tooling can chain steps, retry actions, and amplify a small mistake into data loss, service disruption, or privilege exposure. That is why NHIMG research on AI agents: the new attack surface report matters: it shows how often agents already exceed intended scope, and why oversight gaps become operational incidents.
Security teams also need to treat this as an identity and authorisation problem, not a post-incident blame exercise. When an agent has execution authority, the team that defined the workflow owns the guardrails around sequencing, validation, rollback, and approvals. Current guidance from the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 supports this view: responsibility follows the system design choices, not the machine actor itself. In practice, many security teams discover that distinction only after a migration has already touched production data.
How It Works in Practice
In an agentic migration workflow, responsibility is distributed across design-time and run-time decisions. The product, platform, or operations team defines what the agent may do, the order of operations, and which systems it may reach. Security and compliance teams then validate whether those permissions are narrow enough, auditable enough, and reversible enough. The agent itself is only the executor.
That is why static role-based access control is often insufficient for autonomous tooling. A migration agent may need to read schemas, compare environments, open tickets, patch configuration, or call rollback APIs depending on live conditions. A fixed role can become either too broad or too brittle. More current practice is moving toward intent-based or context-aware authorisation, with policy evaluated at request time. Frameworks such as CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework both reinforce the need for traceability, accountability, and operational controls.
In practice, the safer pattern is:
- grant the agent only the minimum workload identity needed for the task;
- issue short-lived credentials per migration step, not long-lived secrets;
- require human approval for destructive phases or schema-breaking changes;
- log the intent, context, and outcome of each action for audit and rollback;
- separate planning, execution, and validation so one agent cannot self-approve every stage.
NHIMG’s analysis of Analysis of Claude Code Security highlights the same operational lesson: tool-using AI becomes risky when its authority exceeds the predictability of the workflow. These controls tend to break down in legacy environments with shared service accounts, direct production write access, and no reliable rollback path because the agent’s actions cannot be cleanly separated from operator intent.
Common Variations and Edge Cases
Tighter control often improves blast-radius containment, but it also increases orchestration overhead, approval latency, and operational friction. Security leaders have to balance that overhead against the speed benefits of automation. There is no universal standard for this yet, especially where migration tooling spans application, database, and infrastructure layers at once.
One edge case is supervised autonomy, where a human reviews only high-risk steps. That can work, but only if the approval gates are meaningful and not ceremonial. Another is delegated execution in multi-agent pipelines, where one agent plans and another executes. In that model, responsibility still sits with the programme owner, but auditability becomes harder because action chains are longer and attribution is noisier. Best practice is evolving toward explicit separation of duties, immutable logs, and per-task credentials rather than one shared identity for the whole pipeline.
NHIMG’s OWASP NHI Top 10 and the vendor research on AI agent overreach both point to the same conclusion: when an agent makes a bad migration decision, the root problem is rarely the model alone. It is usually unclear ownership, excessive authority, or missing rollback governance in the environment that enabled the decision.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic mis-execution maps to overbroad tool authority and unsafe actions. |
| CSA MAESTRO | GOV-02 | MAESTRO stresses governance and accountability for autonomous agent actions. |
| NIST AI RMF | GOVERN | AI RMF GOVERN covers accountability, oversight, and traceability for AI systems. |
Assign a named owner for each agent workflow and define approval, logging, and rollback controls.
