The failure is not only unapproved automation. It is the collapse of review, ownership, and boundary control around workflows that can touch production data and operational systems. When business users can publish agents directly, security teams lose consistent visibility into permissions, approval paths, and downstream side effects before the workflow is embedded.
Why Unreviewed Agent Building Breaks More Than Automation Control
The core break is governance, not just speed. When business users can create and publish agents without security review, the organisation loses a reliable way to validate who the agent acts for, what it can reach, and whether its permissions are proportionate to the task. That turns ordinary automation into an unbounded execution path that may inherit access, data visibility, and side effects the business never intended.
Agent creation also changes the control problem from a one-time approval to a living runtime decision. The moment an agent can call tools, touch APIs, or move data between systems, it becomes part of the security boundary around those systems, which means review has to cover identity, authorisation, logging, and retirement, not just whether the workflow is useful.
In practice, the break shows up as a mismatch between business ownership and security accountability. The business can deploy the workflow, but security still has to answer for the consequences if the agent overreaches, leaks data, or performs an action that no reviewer ever approved.
Where Review, Ownership, and Boundary Control Collapse
Three controls usually fail together. First, review fails because no one checks the agent before it is connected to production systems. Second, ownership fails because there is no clear responsible party for changes, exceptions, or rollback. Third, boundary control fails because the agent may cross from a low-risk task into privileged data, high-impact systems, or shared credentials without a second gate.
This is why “citizen automation” becomes risky when it is treated as a tooling problem instead of a control problem. The agent may start as a simple helper, but once it can read records, trigger tickets, update configurations, or draft actions that humans then trust, its blast radius is determined by the permissions and trust paths behind it, not by the business intent behind the original request.
Good practice is to treat agent publishing like a governed change to an access path. A workflow that can reach production data, operational systems, or shared knowledge stores needs the same scrutiny you would apply to a new integration, privileged account, or external service dependency.
What Security Teams Lose Without a Pre-Deployment Gate
Security teams lose visibility before the workflow is embedded, which is often the only point at which the control is cheap to apply. Once the agent is relied on by a business process, it becomes harder to inspect permissions, map downstream effects, or separate legitimate automation from unsafe overreach.
They also lose the chance to enforce least privilege at design time. That matters because agentic workflows often combine user intent, delegated access, and tool execution in a way that makes permission creep easy to miss. A small convenience request can quietly become broad operational reach if no one reviews the full action path.
For reader context, the distinction between identity, delegation, and business usage is well explained in NHIMG’s Agentic AI Identity Guide and AI Agent Authorisation Guide, which together show why an agent needs both a clear identity model and per-action access decisions. Where teams need a broader control baseline, IAM and IGA Basics helps connect the agent question back to review, entitlement, and governance discipline.
What a Controlled Agent Publishing Model Has to Enforce
A controlled model does not prohibit business-led innovation, but it does force a boundary between creation and production authority. The practical requirements are simple: the agent must be owned, its permissions must be explicit, its approvals must be auditable, and its retirement path must be known before it is allowed to act.
That model also requires a way to discover unmanaged agents after they appear. If the organisation cannot inventory them, it cannot review them, and if it cannot review them, it cannot answer basic questions about who deployed them, what credentials they use, or whether they still need access.
NHIMG’s Shadow AI and AI Agent Discovery Guide is useful here because discovery is the only way to close the gap between what the business thinks it has deployed and what is actually running. For operational control, the Access Reviews and Certification Guide reinforces the need to review and remove access rather than merely document it.
Risk and Threat Considerations
Unreviewed agents are attractive because they combine convenience with trust. If a business user can attach them to data sources or operational tools, an attacker only needs one compromised user, one malicious workflow, or one overbroad permission set to turn a routine automation into a path for data exposure, unauthorised actions, or persistence inside an important business process.
Failure mechanism: The environment allows agent publication without verifying ownership, permissions, or downstream effects, so the workflow can inherit excessive access or hidden dependencies and then execute beyond the intended control boundary.
Impact: Security loses pre-deployment visibility, production systems can be reached through an unsafely trusted path, and remediation becomes harder because the workflow is already embedded in day-to-day operations.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Directly addresses unreviewed agent authority and excessive access. |
| ASI10 — Rogue Agents | Applies when users can deploy agents outside security review and oversight. | |
| Recommendation — Enforce per-action authorisation and least privilege before agents reach production systems. Block unsanctioned agent publication and require registration before activation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is overbroad workflow access to production data and systems. |
| AU-2 — Event Logging | Agent actions need auditable records when business users can deploy workflows. | |
| Recommendation — Restrict agent permissions to the minimum access needed for the approved task. Log agent actions, approvals, and privilege changes for later review. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Agent publishing without review is fundamentally an access-control failure. |
| A.5.18 — Access rights | Lifecycle control is needed for who may create, approve, and retire agents. | |
| Recommendation — Define and enforce access rules for agent creation, deployment, and use. Review and revoke agent access rights on a defined schedule. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Agent ownership, permissions, and approval paths are central to this problem. |
| Recommendation — Tie each agent to an accountable owner and managed access profile. | ||
Practitioner Guidance
What to prioritise: Require a review gate for any agent that can read, write, call, or trigger production-connected systems, even if the business sees it as a low-code convenience. The review should focus on access scope, owner accountability, and rollback, not only on the workflow logic.
What to verify: Confirm that every published agent has an identified owner, a documented purpose, explicit permissions, and a retirement path. If any one of those is missing, treat the workflow as an exception, not a standard deployment.
Common mistake: Approving the use case while ignoring the execution path. The business outcome may be harmless, but the agent may still be able to reach systems or data that were never intended to be part of the process.
Practitioner takeaway: The control objective is not to stop business users from building agents, it is to ensure no agent reaches production authority without a provable owner, bounded access, and an auditable approval trail.
Related resources from NHI Mgmt Group
- What breaks when business users can build and deploy AI agents without strong guardrails?
- What breaks when security guardrails are missing for AI agents built by business users?
- What breaks when security teams let AI agents run data discovery without human review?
- How should security teams make NHI best practices usable across the business?