Approval of the user does not automatically govern the workflow. When AI tools can copy, transform, or forward sensitive content inside a session, the issue becomes what data the tool can touch and where it can send it. That is why adoption growth can coexist with a larger exposure surface.
Why approved users can still create a larger AI exposure surface
Approval answers who may use the tool, but not what the tool can see, transform, store, or forward once the session is active. Modern AI assistants often operate across documents, chats, tickets, code, and connected apps, so the security question shifts from user permission to session reach and data movement. That is why adoption can expand exposure even without any change in user trust.
Approval is also a coarse control for a much finer-grained execution environment. If an AI system can summarize a confidential file, paste it into another workspace, or trigger an action through a connector, the effective blast radius is defined by the session design, connector permissions, and policy enforcement inside the workflow.
In practice, this means the approved human is only one part of the trust chain. The material risk comes from what the AI can do on that person’s behalf, how much content it can ingest, and whether the workflow permits copying or redistribution beyond the original business purpose.
Where the risk comes from in the workflow itself
The main exposure is not unauthorized login, but authorized overreach. A user who is legitimately approved may still let the tool access sources that contain sensitive data, then let the tool recombine that data in ways the user did not intend. This is especially important when the tool can interact with calendars, mail, drives, code repositories, customer records, or internal search indexes.
Adoption increases risk when organisations treat the AI session like a simple interface rather than a semi-autonomous processing layer. Once the system can transform prompts into output and output into actions, security depends on the boundaries around retrieval, context, and outbound sharing, not just on the user’s account status.
That is why the same approved user can be safe in one deployment and risky in another. The difference is whether the workflow has tight data scoping, clear connector limits, and visible approval points before the model can touch or forward material it should not.
What changes as usage scales across teams and connectors
Risk rises with adoption because the number of sessions, integrations, and content types rises with it. Each new team tends to introduce its own data sources, exceptions, and convenience shortcuts, which makes the control problem more about governance at scale than individual misuse. The security challenge becomes larger even if every user has been vetted.
Expansion also increases the chance of accidental oversharing. If the AI can search broadly or retain context too long, it may surface more information than the user expected. If it can send messages or create records through connected systems, it can also move sensitive content into places with weaker controls or broader visibility.
For that reason, adoption should be measured by the amount of data and action authority each workflow receives, not only by the number of approved users. A small user base with wide connector rights can be riskier than a larger user base with tightly bounded access and output rules.
Risk and Threat Considerations
Approved access can still become a security problem when the AI session is allowed to ingest, reshape, or redistribute sensitive content faster than human review can catch it. The exposure grows when connector privileges, session memory, or automated forwarding let a legitimate user turn one authorised action into many downstream data movements.
Failure mechanism: The workflow is trusted at the user level but not constrained at the data and action level, so the model can amplify a normal request into broader disclosure, retention, or unauthorised propagation of information.
Impact: Confidential data can spread into chats, documents, tickets, or external systems, increasing the chance of internal leakage, compliance failure, and difficult-to-trace secondary exposure.
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 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 | Approved users can still enable agent overreach through session and connector authority. |
| ASI02 — Tool Misuse | Risk rises when AI tools can copy, transform, or forward data through connected actions. | |
| Recommendation — Constrain agent privileges so session actions cannot exceed the approved business purpose. Restrict tool access and outbound actions to approved, bounded workflows. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is excess workflow reach, not merely user approval. |
| SC-7 — Boundary Protection | Session boundaries and connector paths determine how far data can move. | |
| Recommendation — Limit each AI workflow to the minimum data and action privileges it needs. Segment AI access paths and restrict data flows at workflow boundaries. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | Approved access must still be controlled at the workflow and resource level. |
| Recommendation — Enforce access policies that bound what the AI can reach and where it can send data. | ||
Practitioner Guidance
What to verify: Check what the AI can access during a session, what it can write to, and whether those permissions are narrower than the human user’s ordinary account rights. The most important test is whether the tool can move data somewhere the user could not justify in normal workflow review.
Decision rule: If a capability can copy, transform, or forward sensitive content outside the originating system, treat it as a high-risk workflow even when the user is fully approved. Approval should be necessary, but it is not sufficient to declare the use case safe.
What good looks like: The AI session has bounded retrieval, explicit connector approval, visible outbound actions, and content controls that stop sensitive material from being redistributed by default. In that state, adoption can grow without proportionally expanding the blast radius.
Practitioner takeaway: The real control objective is not to approve the user, but to constrain the session so the AI cannot exceed the data movement and action limits the business actually intended.
Related resources from NHI Mgmt Group
- Why do AI agents increase non-human identity risk in existing IAM programmes?
- How should security teams limit the risk from AI agents that have access to production systems?
- Why do AI agents increase non-human identity risk?
- Why does shadow AI increase enterprise risk even when users are authenticated?