How should security teams handle AI app usage that appears only in browser sessions?

Security teams should treat browser-discovered AI usage as a discovery and governance problem, not just an acceptable-use issue. First identify which AI tools are being accessed, then classify whether they are sanctioned, personal, or unmanaged. Finally, connect that inventory to data controls, session monitoring, and access review so the browser does not become an ungoverned entry point.

Why This Matters for Security Teams

When AI usage is only visible in browser sessions, it usually means the organisation is seeing the symptom before the identity model. The browser may expose sanctioned SaaS AI, personal accounts, shadow copilots, or embedded agentic features, but those signals are useless unless they are tied to data classification, session policy, and access governance. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because browser-discovered AI usage still needs controls around monitoring, least privilege, and auditability, even when the application is not a traditional enterprise workload.

This matters because browser-only AI often bypasses the normal control plane. A user can paste regulated data into a public model, connect a personal account to a work session, or use an AI feature embedded in a browser extension without any direct API registration. That leaves security teams with partial telemetry and weak ownership unless discovery feeds a governed response. NHI Management Group’s The State of Non-Human Identity Security shows how common visibility gaps are across connected apps, and the same pattern appears when AI use is hidden inside browser workflows. In practice, many security teams discover the problem only after a data exposure, rather than through intentional browser governance.

How It Works in Practice

The practical response is to treat browser AI as an identity and session problem, not just a content or acceptable-use problem. Start by identifying where the browser is reaching AI endpoints, then map each session to a risk category: approved enterprise AI, personal account use, unmanaged public AI, or embedded AI inside another SaaS product. That inventory should be joined to policy decisions, because the same browser can carry very different risk depending on the data being entered and the user’s role.

Security teams should then apply controls at the session layer. That usually means browser telemetry, CASB or secure web gateway inspection, DLP rules for prompt and upload content, and identity-aware access review for the accounts behind the session. Where possible, block or step up control on unmanaged tools, and require stronger governance for sanctioned tools that can process sensitive data. Current guidance suggests using policy as code and request-time evaluation for higher-risk AI workflows, because static allowlists age quickly when users can switch tools in minutes. The browser becomes the enforcement point only if it is tied to identity, classification, and logging.

For teams building a broader governance model, the lesson from DeepSeek breach is that exposure is not limited to a single app or secret store; browser-mediated access can surface sensitive data into systems that were never formally approved. NIST guidance and NHIMG research both point to the same operational need: discover the session, classify the tool, and enforce controls before data leaves the workstation. These controls tend to break down when the browser is unmanaged on endpoints that can install extensions or sign into personal AI accounts because the organisation loses both visibility and policy enforcement.

Common Variations and Edge Cases

Tighter browser controls often increase user friction and privacy scrutiny, requiring organisations to balance data protection against legitimate productivity use. That tradeoff is especially visible with personal devices, contractor access, and bring-your-own-browser environments, where full inspection may not be practical or desirable. In those cases, current guidance suggests focusing on least-invasive controls first: inventory, risk-based blocking, and clear segregation between work and personal accounts.

There is no universal standard for this yet, especially for browser extensions and embedded AI features inside collaboration suites. Some tools behave like a standalone app, while others are effectively a feature of the browser or identity session itself. That means teams may need different controls for different layers: endpoint policy for extensions, identity governance for account use, and DLP for content transfer. For more autonomous browser-based assistants, the risk rises further because they can take actions across tabs and services without a human reviewing each step.

Security leaders should avoid assuming that “browser only” means “low risk.” It often means the opposite: the AI is being used in the least governed place in the stack, and the security team only sees it when the session data is already in motion.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should security teams handle cached tokens and browser sessions that AI agents can reuse?
• What should IAM teams do when browser telemetry reveals shadow AI usage?
• How should security teams govern API keys used for generative AI access?