Ownership should sit with security and platform governance together, because unmanaged agents create both technical and policy risk. Security teams need authority to detect and block shadow AI, while platform owners need a path to bring approved agents under management. If responsibility is split loosely, unmanaged tools persist, controls stay inconsistent, and agent activity remains outside review.
Why ownership has to be shared, not scattered
Unmanaged agents and shadow ai are not just a tooling problem, they are an operating model problem. The ownership question matters because these systems can already act, connect, store, and expose data without a clear control point. If governance sits with only one team, either the technical risk is missed or the policy and approval path never catches up.
Security should own the authority to detect, classify, restrict, and block unsanctioned agents, because shadow use creates exposure that looks like both access abuse and control bypass. Platform governance should own the route to onboard useful agents into approved services, so the organisation can replace informal use with managed capability instead of forcing users into workarounds.
That division is not a comfort compromise, it reflects the fact that unmanaged agents span enforcement and enablement at the same time. Security can stop unsafe behaviour, but platform governance is what turns a tolerated workaround into a supportable service with traceable ownership, change control, and review.
What goes wrong when responsibility is split loosely
Loose ownership usually produces a gap between discovery and remediation. Security may see the agentic activity as a control issue, while platform teams see it as an intake problem, and neither side feels fully accountable for the live exposure. In practice, that leaves hidden integrations, inconsistent credential handling, and unreviewed action paths in place longer than they should remain.
The deeper failure is that shadow AI often moves faster than formal governance. Once a business team discovers a tool that helps them ship faster, the organisation can end up with multiple unregistered agents, duplicated approvals, and no reliable view of which tools have access to which systems. That makes risk review episodic instead of continuous.
Where unmanaged agents are already operating, ownership must also include a cleanup path. The question is not only who approves future tools, but who is empowered to inventory current use, decide what gets retired, and decide what gets converted into a managed service.
How to draw the boundary between security and platform governance
Security should own the policy line: what is permitted, what must be blocked, what requires review, and what evidence is needed before an agent is allowed to interact with production systems. Platform governance should own the service line: approved agent onboarding, lifecycle management, standard integration patterns, and the operational path for exceptions and retirement.
That split works best when there is a single decision record for each agent. If a tool is discovered in the wild, security can triage it, but platform governance should determine whether it becomes an approved managed capability, a restricted pilot, or a removal candidate. The key is that neither team can silently defer to the other when the agent already has business impact.
For readers managing real deployments, the most useful control is not a committee structure, it is a clear routing rule. Discovery, containment, and enforcement should go to security; adoption, standardisation, and lifecycle ownership should go to platform governance. The organisation then has one place to stop unsafe use and one place to convert legitimate use into something auditable.
Risk and Threat Considerations
Unmanaged agents create a governance risk because they can operate outside normal review while still holding meaningful access or taking material actions. Shadow AI also creates a detection problem, since the most damaging use is often the use nobody has formally registered.
Failure mechanism: When ownership is unclear, controls fragment across teams, unmanaged tools persist, and approvals never converge on a single lifecycle path. That leaves agent activity outside normal inventory, review, and enforcement.
Impact: The organisation can lose visibility into data movement, access pathways, and automated actions, which increases the chance of inconsistent controls, unauthorized use, and delayed containment when a tool behaves unexpectedly.
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 and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent ownership is driven by who can authorize and govern agent actions. |
| ASI10 — Rogue Agents | Shadow AI and unmanaged agents are rogue by definition when outside governance. | |
| ASI02 — Tool Misuse | Unmanaged agents become risky when they use tools without governed oversight. | |
| Recommendation — Enforce privilege boundaries so agent actions stay within approved authority. Inventory and constrain unsanctioned agents before they spread. Restrict tool access to approved agent workflows and monitored approvals. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Governance must limit what unmanaged or approved agents can do. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Ownership needs reviewable evidence of agent activity and control decisions. | |
| Recommendation — Apply least privilege to agent access and actions. Review agent activity logs for unsanctioned access and actions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shadow AI often persists through unmanaged accounts, keys, and access paths. |
| CIS-16 — Application Software Security | Approved agents need a governed path into production use and change control. | |
| Recommendation — Maintain ownership and review of every active agent access path. Bring approved agents under secure software governance before broad use. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Ownership must align with who is accountable for agent use in the organisation. |
| ID.AM-01 — Physical Devices and Systems Inventory | Shadow AI control starts with discovering and inventorying active agents. | |
| PR.AA-05 — Manage Credentials and Secrets | Unmanaged agents often persist through uncontrolled secrets and tokens. | |
| Recommendation — Assign clear accountability for agent governance across teams. Inventory all deployed agents and related service accounts. Control and rotate agent secrets under formal ownership. | ||
Practitioner Guidance
What to prioritise: Establish a single intake and enforcement path for all discovered agents, then separate the decision to block from the decision to onboard. That prevents security from becoming only a detection function and prevents platform teams from inheriting approval without control authority.
What to verify: For every active agent, verify who can change it, what it can reach, and whether there is a named operational owner. If those three answers are not clear, the tool is not governed enough to trust.
Decision rule: If the agent is already in production use, treat it as an exposure-management problem first and a rationalisation problem second. Containment and ownership assignment should happen before process redesign or tool standardisation.
Practitioner takeaway: The right owner is not one team in isolation, it is a dual control model where security can stop unsafe behaviour and platform governance can make approved use sustainable.
