Start with discovery, not assumptions. Inventory the AI tools people actually use, including personal accounts, browser extensions, and assistant connections that may sit outside the approved stack. Then map which systems those tools can reach and what data they can access. A fixed-scope assessment helps teams turn unknown use into a documented baseline for policy, ownership, and control decisions.
Why assessment should begin with real usage, not the approved stack
When agentic AI appears outside sanctioned tooling, the first job is to establish what is actually in use. That means cataloguing personal accounts, browser extensions, desktop assistants, API-connected plugins, and any other interfaces that can act on behalf of a user. A discovery-led baseline gives security teams a defensible starting point for ownership, policy, and control decisions.
Discovery matters because the risk is rarely the tool name alone, it is the path from the tool to enterprise data and systems. A small browser extension can become a high-impact control point if it is connected to a mailbox, source repository, ticketing system, or cloud console. The question is not whether the organisation officially approved it, but whether it can reach something valuable.
That is why the first assessment pass should separate visibility from judgment. Teams need to know what people use, how they authenticate, which sessions or grants persist, and what business systems sit behind those connections. Once that map exists, the team can decide whether the issue is shadow usage, a bounded exception, or a broader governance gap.
What to map once shadow agentic use is found
After discovery, the next useful artifact is a simple access map: tool, user, connection method, downstream system, and data class. This is the point where assessment becomes operational. A tool that only drafts text is a different risk from one that can read inboxes, move files, trigger workflows, or call internal APIs.
Security teams should also record whether the access is user-delegated, token-based, or tied to long-lived credentials. That detail changes the assessment because it affects revocation, blast radius, and attribution. It also helps distinguish a one-off experiment from a reusable access path that may need a formal control owner.
For a broader view of how agent behavior and access can change as autonomy increases, AI Agents vs Agentic AI is a useful way to frame the boundary between a simple assistant and a system that can act with more agency. Where the assessment shows delegated action rather than passive suggestion, the control question becomes sharper.
How to turn unknown use into a controllable baseline
The practical goal is not to ban every unsanctioned experiment on sight. It is to document enough of the current state to decide which uses are acceptable, which need containment, and which should be removed. That usually means defining a fixed scope for the review, then classifying each tool by business purpose, access level, and data exposure.
A good baseline should answer three questions: what is connected, what can be reached, and who can disable it. If the team cannot answer all three, the assessment is not complete enough for policy action. If it can answer them, the result is usually enough to create an exception register, a containment plan, or a formal approval path.
For teams building a more structured view of agent access and delegation, the Agentic AI Identity Guide helps connect discovery to lifecycle questions such as ownership, registration, and retirement. That is especially useful when the outside-tooling use is not a one-off but an emerging pattern that may need governance.
Risk and Threat Considerations
Unapproved agentic AI use creates risk when it bypasses the organisation’s normal visibility, access review, and data-handling controls. The main exposure is not only data leakage, but also untracked delegated access that can persist after the user stops actively using the tool.
Failure mechanism: A personal account, extension, or assistant connection retains access to a high-value system or dataset, often through a token or session the security team cannot see, review, or promptly revoke.
Impact: Sensitive data can be exposed, actions can be taken without clear accountability, and the organisation may inherit a standing access path that is difficult to assess, govern, or shut down quickly.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Outside tooling assessment centers on delegated access and privilege exposure. |
| Recommendation — Map each unmanaged agent connection to ASI03 and contain any path with excess delegated access. | ||
| OWASP Non-Human Identity Top 10 | NHI-09 — NHI Reuse | Personal accounts and reused connections can propagate unmanaged access across tools. |
| Recommendation — Identify reused access paths and require unique, revocable credentials for each tool. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Discovery of personal accounts and assistant connections depends on tracking accounts and their access paths. |
| IA-5 — Authenticator Management | Tool connections often rely on tokens or sessions that must be discovered and governed. | |
| AU-2 — Event Logging | Unknown agentic use becomes assessable only when connected actions are logged. | |
| Recommendation — Inventory and review all accounts that can reach enterprise systems, then disable unapproved ones. Track and rotate authenticators and tokens tied to external AI tools. Log tool actions and access events so shadow use can be baselined and investigated. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is about bounded access and verifying each tool-system connection before trusting it. |
| Recommendation — Verify each agent connection explicitly before granting any system access. | ||
Practitioner Guidance
What to prioritise: Start with the highest-risk connections, not the most visible tools. Anything that can read mail, access files, or trigger actions in production should be assessed before low-impact assistants that only generate text.
What to verify: Confirm whether the connection uses a personal login, a third-party token, or a browser session that survives normal account offboarding. If revocation is unclear, treat the access path as operationally live until proven otherwise.
Decision rule: If the tool can reach sensitive systems or data, move it into a documented exception or containment workflow immediately. If it cannot, keep it in inventory but do not overreact with controls meant for privileged access.
Practitioner takeaway: The assessment starts with evidence of use and reachable access, because that is what separates harmless experimentation from an unmanaged control path.
Related resources from NHI Mgmt Group
- How should security teams use agentic AI in compliance audits?
- How should security teams govern AI use in developer tooling?
- How do security teams know if an AI agent is operating outside its approved role?
- How should security teams decide whether AI security tooling can process regulated data outside the enterprise?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org