Most shadow-AI programs still start—and stop—at an app list. Apono's September 2 guide argues that discovering an unsanctioned model, integration, or agent is only the first question. The governing questions are which identity it authenticates as, which credentials and permissions it holds, what data it can reach, and which downstream systems it can change.
The scale problem is already measurable in the research Apono cites. IBM's 2025 Cost of a Data Breach Report found that one in five surveyed organizations experienced a breach due to shadow AI, while only 37% had policies for managing AI or detecting shadow AI. Knowing a tool exists without knowing its privilege graph is not detection; it is a partial inventory.
Apono's practical sequence is correlation, not a single scanner: browser, SaaS, endpoint, cloud, code, identity, API, and audit signals, then map each finding to owner, credentials, permissions, data flows, and downstream actions. Prioritize by privilege level, data sensitivity, production reach, autonomy, and potential blast radius—not by how many unauthorized logos you counted.
That framing matters for desk and security partners. Two coding assistants can look identical in a procurement spreadsheet while one holds read-only docs access and the other can modify production infrastructure through a standing OAuth grant or service account. Risk lives in the permissions, not the product name.
Useful shadow deployments should not automatically mean a ban. Move them into monitored, least-privilege workflows: task-scoped access, contextual guardrails, human approval for high-risk actions, and automatic revocation when the task ends. Retire what cannot be governed; replace what has a safer sanctioned path.
If your current “AI discovery” program cannot answer who the agent is acting as and what it could break if compromised, you are still doing tool inventory. Start the identity and blast-radius map before the next board asks how much shadow AI you actually have.