What breaks when an AI agent can act inside a pipeline without human approval?

Why This Matters for Security Teams

When an AI agent can act inside a pipeline without human approval, the control problem shifts from “who approved the workflow” to “what did the agent decide to do at runtime.” That is a different risk class. Static RBAC and pre-approved change gates assume the actor will follow a narrow, predictable path. Autonomous agents do not. They can inspect surrounding text, chain tools, and adapt their next step based on new context.

That is why current guidance increasingly treats agentic systems as a live control-plane problem rather than a documentation problem. The OWASP OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework both emphasize runtime risk evaluation, while NHIMG’s AI Agents: The New Attack Surface report shows that 80% of organisations already report AI agents performing actions beyond intended scope.

In practice, many security teams encounter the policy gap only after an agent has already moved data, triggered a build, or exposed credentials rather than through intentional testing.

How It Works in Practice

The practical failure mode is simple: the pipeline approves a class of work, but the agent chooses the specific action after it has read the live environment. That breaks approval models built on fixed intent. A human reviewer can sign off on “run the deployment assistant,” but cannot know whether the assistant will inspect source comments, fetch secrets, alter a config, or call another tool once execution begins.

Security teams need to treat the agent as a workload identity with tightly scoped, short-lived authority, not as a user session with durable privileges. Current best practice is evolving toward just-in-time credentials, runtime policy decisions, and explicit task boundaries. That means using workload identity primitives such as SPIFFE-style identities or OIDC-based service tokens, then evaluating each request against context: what task is being attempted, what resource is being touched, what data sensitivity is involved, and whether the action matches the declared objective.

• Issue ephemeral credentials per task, not shared keys that survive across pipeline runs.
• Bind access to workload identity and environment context, not to a broad human role.
• Evaluate policy at request time with policy-as-code rather than only at deployment approval.
• Log every tool call and resource access so post-incident review can reconstruct agent behaviour.

NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs is a useful reminder that once credentials are exposed, abuse can follow within minutes, not days. In a pipeline, that urgency matters because agent decisions and secret exposure can happen in the same execution window. These controls tend to break down when the agent is allowed to chain multiple tools across loosely governed CI/CD stages because the trust boundary disappears between steps.

Common Variations and Edge Cases

Tighter agent control often increases delivery friction, requiring organisations to balance automation speed against blast-radius reduction. That tradeoff is unavoidable, especially in build and deployment pipelines where teams value fast feedback and minimal manual review. Best practice is evolving, not settled, on how much autonomy is acceptable for low-risk versus production-impacting actions.

Some environments can tolerate broader agent latitude, such as read-only analysis or internal summarisation tasks. Others cannot. A code-review agent that can only annotate findings is very different from an agent that can merge branches, rotate secrets, or update infrastructure. The governance answer should scale with the consequence of the action, not with the convenience of the workflow.

There are also edge cases where static policy still helps, but only as a floor. For example, repository path restrictions, egress controls, and approval thresholds can limit obvious misuse, yet they do not stop an agent from making a novel sequence of allowed calls that produces an unsafe outcome. That is why OWASP NHI Top 10 and CSA MAESTRO agentic AI threat modeling framework both point toward contextual, task-scoped controls instead of one-time trust decisions. The model breaks down most sharply in multi-stage CI/CD systems that reuse credentials across jobs, because one successful agent action can become the launch point for lateral movement.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• What is the difference between governing human access and governing AI agent access?
• How should security teams monitor AI agent activity without disrupting developers?
• How should security teams govern AI systems that can act without human approval?