AI agents change delivery governance because they can generate and move code at machine speed, while many CI/CD controls still assume a human-paced workflow. That breaks the old expectation that review, approval, and rollback decisions will always happen after a person has had time to intervene.
Why Traditional Delivery Governance Fails for AI Agents
Delivery governance was built around a person in the loop: a developer opens a change, a reviewer inspects it, a pipeline promotes it, and rollback happens after a human notices something is wrong. AI agents collapse that timing assumption. When an agent can write code, call tools, modify infrastructure, and retry automatically, governance has to shift from after-the-fact approval to runtime control, especially for secrets, workload identity, and tool permissions.
This is why guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework increasingly treats agent behaviour as a governance object, not just an application output. The issue is not only code quality. It is that an autonomous system can chain actions faster than a human can interpret intent, and it may do so using credentials that were never designed for machine-paced escalation. NHIMG research shows the scale of that shift: in SailPoint’s AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope.
In practice, many security teams discover this only after an agent has already merged, deployed, or exfiltrated something unintended, rather than through deliberate governance design.
How Delivery Controls Need to Change in Practice
For autonomous workloads, static RBAC is usually too blunt. An agent does not follow a fixed human job description; it executes goals, adapts plans, and may need different access at different stages of the same task. Current best practice is moving toward intent-based authorisation, where policy is evaluated at request time against the task, the data, the environment, and the action the agent is trying to perform. That is a better fit than pre-approved standing access.
Operationally, that means three things. First, issue JIT credentials that are ephemeral and scoped to a single task or short session. Second, bind those credentials to workload identity, not to a shared service account. Third, enforce policy-as-code so the pipeline can decide whether the agent may call a tool, access a repository, or promote a build in the moment. Frameworks such as CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix are useful because they force teams to model tool chaining, lateral movement, and abuse of privileges as first-class risks.
NHIMG’s OWASP NHI Top 10 and Analysis of Claude Code Security both point to the same operational lesson: the control point has to move closer to execution, where the agent’s intent and context are visible.
- Use short-lived credentials with automatic revocation at task completion.
- Separate read, write, deploy, and secret-access permissions.
- Require runtime policy checks for tool use, not just pipeline admission.
- Log agent identity, prompt context, action intent, and target system together.
These controls tend to break down in legacy CI/CD stacks and multi-agent workflows because the pipeline often cannot evaluate intent fast enough, or because one agent can hand off work to another without a clean identity boundary.
Where the Governance Model Gets Messy
Tighter control often increases friction, so organisations have to balance delivery speed against containment. That tradeoff is real, especially when teams want agents to operate across code, cloud, and ticketing systems without constant human approval. There is no universal standard for this yet, but current guidance suggests that the more autonomous the agent, the shorter the credential lifetime and the narrower the action scope should be.
Edge cases usually appear when agents inherit human access models, when secrets are reused across tasks, or when a “helpful” automation is allowed to self-retry until it succeeds. That is where static perimeter thinking fails. A well-governed agent should not carry long-lived API keys, broad deployment rights, or standing access to production data. Instead, it should prove workload identity, receive a JIT token for the exact operation, and lose it immediately after. NHIMG’s Moltbook AI agent keys breach and DeepSeek breach show how exposed secrets and weak containment can turn automation into rapid compromise.
For governance teams, the practical question is not whether AI agents should be trusted. It is how much power they get, for how long, and under what runtime checks. In agentic delivery, standing privilege is usually the wrong default.
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 | Agent tool abuse and runtime authorization are central to this question. | |
| CSA MAESTRO | MAESTRO focuses on threat modeling autonomous agent workflows and privilege chains. | |
| NIST AI RMF | AI RMF governance is relevant because agent behaviour needs accountability and monitoring. |
Assign owners, monitor agent actions, and document acceptable autonomy boundaries.
