Protecting models alone leaves the operational layer exposed. AI tools can still move through SaaS apps, persistent OAuth connections, and unmanaged browser sessions, which means data can be accessed or shared outside approved workflows. The result is weak enforcement, limited traceability, and a false sense of security around AI usage.
Why This Matters for Security Teams
Protecting the model layer is necessary, but it does not stop an AI-enabled workflow from reaching sensitive data through SaaS applications, browser-based sessions, or long-lived OAuth grants. That gap matters because most practical AI use now depends on connected services, not isolated inference. When those connections are unmanaged, the organisation can lose control over where prompts, outputs, files, and approvals flow.
The security problem is therefore broader than model integrity. It includes identity, token lifecycle, session trust, app-to-app permissions, and data exfiltration paths that sit outside the AI system itself. Guidance from the NIST Cybersecurity Framework 2.0 is useful here because it frames security as a set of governed outcomes across identity, access, and data protection rather than a single control point. If the SaaS layer is not in scope, the AI security programme will be incomplete by design.
In practice, many security teams discover this only after an OAuth grant, shared workspace, or unmanaged browser session has already exposed data outside approved workflows.
How It Works in Practice
Effective protection starts by treating AI as part of an identity and access ecosystem. The model may be the decision engine, but the SaaS apps, connectors, service accounts, and delegated tokens are what actually move data. That means access reviews must cover third-party integrations, not just user roles, and security teams need visibility into which apps can read mail, files, chats, tickets, and knowledge bases. The OWASP Non-Human Identity Top 10 is relevant because many of these integrations behave like non-human identities with standing permissions and weak lifecycle governance.
Operationally, mature programmes usually combine the following controls:
- Inventory all AI-connected SaaS apps, browser extensions, and OAuth clients.
- Classify each token or connector by data scope, expiry, and business owner.
- Require admin approval for high-risk OAuth scopes and sensitive data access.
- Use conditional access, device posture checks, and session time limits for privileged SaaS use.
- Log prompt, tool, and file activity so investigators can reconstruct the full path of access.
NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control baseline for access enforcement, auditability, and configuration management. The practical lesson is that model protections such as guardrails or content filters do not compensate for over-permissioned SaaS connectivity. These controls tend to break down in environments with unmanaged self-service app approvals and highly distributed collaboration tools because owners cannot see or revoke every active grant in time.
Common Variations and Edge Cases
Tighter access governance often increases friction for product teams and analysts, so organisations must balance agility against the need for visibility and revocation. That tradeoff is real, especially where AI assistants are embedded into everyday SaaS workspaces and users expect one-click connections to files, mail, and chat.
Best practice is evolving on how to govern AI-specific OAuth patterns, but current guidance suggests treating any connector with read, write, or forwarding capability as a high-risk pathway until proven otherwise. This is especially important when a single AI tool can act across multiple tenants, shadow IT apps, or personal accounts. Identity teams should also distinguish between user consent, administrator consent, and service-to-service delegation, because those flows create different review and incident-response obligations.
Where the AI stack includes autonomous agents, the issue expands further: a tool may continue to act after the user who approved it has logged out, left the company, or changed role. That is where OWASP Non-Human Identity Top 10 and standard SaaS governance need to meet. There is no universal standard for this yet, but the safe assumption is that long-lived delegated access should be continuously revalidated, not merely approved once. The control model becomes brittle when legacy SaaS permissions, unmanaged browser sessions, and AI automation overlap in the same workflow because revocation cannot keep pace with real-time use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | SaaS and OAuth controls are access outcomes, not model-only safeguards. |
| OWASP Non-Human Identity Top 10 | OAuth clients and connectors behave like non-human identities with standing access. | |
| NIST AI RMF | AI risk management must cover operational access paths, not just the model itself. | |
| NIST Zero Trust (SP 800-207) | SA-2 | Zero trust requires continuous verification across app and session boundaries. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege limits the damage from overbroad SaaS OAuth grants. |
Define, review, and revoke AI-connected access as part of the organisation's access control program.
Related resources from NHI Mgmt Group
- What breaks when organisations do not map the access path of AI and SaaS integrations?
- What breaks when AI models can access sensitive data without output controls?
- What breaks when organisations only monitor AI models and not access paths?
- What breaks when organisations rely on access controls alone to protect files in Google Drive and OneDrive?
