When AI agents are created outside standard engineering pipelines, security teams lose some of the review, testing, and change control that normally reduce deployment risk. That makes it easier for access issues, data-handling mistakes, and unsafe prompt behavior to reach production. Organisations then need compensating controls such as tighter approval steps, audits, and runtime monitoring.
Why AI Agents Outside the SDLC Create Governance Gaps
When AI agents are assembled outside the SDLC and CI/CD pipeline, they often bypass the normal gates that catch unsafe design choices before release. That matters because agents are not just static applications; they can hold credentials, call tools, move data, and make decisions that change over time. Without engineering controls, a team may not know what the agent can access, how often it changes, or who approved the current behaviour.
This is one reason current guidance increasingly treats agent governance as an operational control problem, not just a model-quality issue. The risk is not limited to code defects. It includes unmanaged prompts, undocumented tool use, missing rollback paths, and no reliable trace of what changed between one agent version and the next. NHIMG research on AI Agents: The New Attack Surface report found that 80% of organisations reported AI agents performing actions beyond intended scope, which shows how quickly control gaps become business exposure.
In practice, many security teams discover the problem only after an agent has already touched production data or taken an action nobody can fully reconstruct.
How It Works in Practice
SDLC and CI/CD are valuable here because they create reviewable artefacts: source control, change approval, test evidence, dependency review, and deployment traceability. When AI agents are built around those controls, teams can inspect prompt logic, tool permissions, data access assumptions, and release history before the agent is allowed to act.
Outside that pipeline, the agent often arrives as a fast-moving assembly of prompts, API keys, third-party connectors, and ad hoc scripts. That creates a different operating model from ordinary software. A team may deploy a chatbot, an automation helper, or a code assistant without inventorying its tools, assigning an owner, or defining a rollback path. The result is a live system with unclear scope and weak accountability.
For agentic systems, the core failure is usually not the model alone but the combination of delegated authority and insufficient control boundaries. Best practice is evolving toward treating the agent as a governed workload with explicit approval, short-lived access, audit logging, and runtime policy checks. The OWASP Top 10 for Agentic Applications 2026 is useful here because it frames the risk around unsafe tool use, exposed data, and weak oversight rather than around generic application flaws. NHI discipline also matters: the Ultimate Guide to NHIs is relevant when the agent depends on machine credentials that need ownership, rotation, and revocation.
- Use registration and approval steps before an agent gets production access.
- Bind tool permissions to the smallest workable scope and make them time-limited.
- Log prompts, tool calls, data access, and state changes so the agent can be investigated later.
- Require a release path for prompt, policy, and connector changes, not just code changes.
These controls tend to break down when teams treat the agent as a no-code business automation rather than as a governed production workload with real authority.
Common Variations and Edge Cases
Tighter control often slows experimentation, so organisations have to balance innovation speed against the cost of unmanaged autonomy. That tradeoff is real, especially in teams that prototype quickly or rely on shadow tooling. There is no universal standard for this yet, but the practical question is whether the agent can affect systems, data, or decisions that matter.
One common edge case is the internal pilot that quietly becomes a production dependency. Another is the “low-risk” assistant that later gains access to tickets, repositories, or customer data. A third is the agent created by a business team using SaaS features rather than by engineering. In each case, the issue is not whether the interface looked harmless at launch, but whether the control plane stayed intact as scope expanded.
Practitioners should also distinguish between model testing and operational assurance. A model can pass a benchmark and still be unsafe if its tool permissions, secrets, or escalation paths were never governed. The most important judgment is whether the organisation can prove what the agent was allowed to do at the moment it acted. Where that evidence is missing, the deployment is effectively operating on trust rather than control.
NIST AI Risk Management Framework helps structure the broader governance conversation, while CSA MAESTRO agentic AI threat modeling framework is useful when the main concern is autonomous behaviour and tool abuse rather than generic AI policy.
Risk and Threat Considerations
The material risk is uncontrolled authority. An agent built outside normal release and review paths can reach production with excessive access, hidden dependencies, or untested behaviour, which creates exposure even if no attacker is present. If the agent is externally facing or connected to sensitive systems, the same weakness becomes attractive for prompt injection, tool abuse, and credential misuse.
Failure mechanism: The risk materialises when delegated actions, credentials, and tool access are granted without change control, scoped approval, or auditability. Attackers can then exploit overbroad permissions, manipulate prompts or inputs, and use the agent’s trusted pathways to access data or issue actions that defenders did not intend.
Impact: Organisations can lose visibility into what the agent touched, expose sensitive data, trigger unauthorised changes, and make incident response slower because the approval trail and runtime evidence are incomplete.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Excessive Agency | Uncontrolled agent rollout can grant more action authority than intended. |
| A5 — Tool Misuse | Agents outside CI/CD often gain unreviewed tool access and unsafe integrations. | |
| Recommendation — Constrain agent actions to the minimum authority needed and review tool scope before production use. Validate every tool connection and block unapproved actions through policy checks. | ||
| CSA MAESTRO | GOV-2 — Governance and Accountability | Shadow-built agents lack ownership, approval, and accountability controls. |
| Recommendation — Assign ownership, approval, and audit responsibility before any agent reaches production. | ||
| NIST AI RMF | GOVERN — Govern | The question is fundamentally about AI governance and unmanaged operational risk. |
| Recommendation — Establish AI governance gates that define acceptable use, review, and escalation for agent deployment. | ||
| CIS Controls v8 | 5.3 — Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers | Ad hoc agent builds often bypass secure configuration and change control. |
| Recommendation — Harden agent runtimes and enforce approved configuration baselines before deployment. | ||
Practitioner Guidance
What to prioritise: Treat any agent that can read data, invoke tools, or act on behalf of users as a governed workload first and an application second. The first control question is not “Does it work?” but “Who owns its authority, and can that authority be withdrawn quickly?”
What to verify: Confirm that the agent has a named owner, a documented purpose, a bounded tool set, and an auditable deployment path. If any of those are missing, the deployment should be treated as a higher-risk exception rather than a normal release.
Practitioner takeaway: The critical failure is not that AI agents are experimental; it is that experimentation becomes production without the controls needed to limit, observe, and revoke delegated action.
Related resources from NHI Mgmt Group
- What happens when a malicious package reaches CI/CD without dependency malware controls?
- What happens when AI agents are allowed to act on behalf of users without tight consent controls?
- What breaks when AI agents are allowed to act inside privileged CI/CD workflows?
- What breaks when AI agents can chain tools through MCP without tight policy controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
