Notifications
Clear all
Topic starter
02/08/2026 11:58 am
TL;DR: Browser-local policy enforcement, AI tool governance, and anti-phishing controls can reduce browser-based data leakage without proxy backhaul or session breakage, according to Island. The key shift is that control must move to the interaction layer where credentials, prompts, and uploads actually happen, while AWS Security Hub adds consolidated visibility and operational simplicity.
NHIMG editorial — based on content published by Island: Safely Enable AI and Secure Browsing with Island and AWS Security Hub Extended Enterprise security
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious.
Questions worth separating out
Q: How should security teams control AI use in browsers without blocking productivity?
A: Security teams should focus on identity context, account separation, and data-sensitive enforcement rather than blanket blocking.
Q: Why do browser controls matter in identity governance?
A: Browser controls matter because many modern access paths are session-based and mediated through the web, not just through login events.
Q: What breaks when web security depends only on proxies and network inspection?
A: Proxy-led controls often miss the application context that determines whether an interaction is safe.
Practitioner guidance
- Define browser-session policy for AI use Block or redirect sensitive prompts, uploads, and copy-paste actions in browser sessions where company data could reach unapproved AI tools.
- Map browser controls to identity context Tie browser enforcement to identity provider signals such as user role, device posture, and application approval status.
- Test credential-entry safeguards in the browser Validate that risky websites cannot accept corporate credentials and that lookalike domains are blocked before users submit secrets.
What's in the full article
Island's full post covers the operational detail this analysis intentionally leaves for the source:
- How the browser extension enforces local policy inside Chrome, Edge, Safari, Firefox, and Chromium-based browsers
- How AWS Security Hub Extended plan changes procurement, deployment, and unified operations for the integration
- How Island applies last-mile controls to copy, paste, uploads, downloads, printing, and file movement inside the endpoint browser
- How the AI protection workflow distinguishes approved AI platforms from unapproved tools while keeping audit trails
👉 Read Island's analysis of browser-based AI protection and secure browsing →
Browser-based AI protection: what it means for IAM and data control?
Explore further
02/08/2026 1:05 pm
Browser-local governance is becoming a control-plane issue, not a convenience feature. Once AI prompts, SaaS use, downloads, and credential entry all happen in the same browser session, the browser is no longer just a presentation layer. It becomes the place where policy must decide what data can move, what tools are approved, and when an interaction is too risky to continue. Practitioners should treat browser governance as part of identity and data control, not as a separate web security add-on.
A question worth separating out:
Q: Who is accountable when employees use private AI for work tasks?
A: Accountability usually sits with the organisation that sets policy, the manager who approves the workflow, and the teams that control endpoint and identity settings. If no one defines approved use, the result is shadow AI with weak traceability. The right answer is explicit ownership, not assumed privacy.
👉 Read our full editorial: Browser-based AI protection and secure browsing cut data leakage risk
