Notifications
Clear all
Topic starter
03/06/2026 5:14 pm
TL;DR: Existing DLP and AI governance controls were built for files and managed platforms, not unsanctioned browser prompts and account-context drift, so Browser Shield focuses on prompt-level controls for public browser-based AI tools, using identity, account context, and content inspection to monitor, alert on, or block sensitive submissions before data leaves the organisation, according to Cyera.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams govern prompts submitted to browser-based AI tools?
A: Security teams should govern browser AI prompts at the point of submission, using data classification, identity, and account context together.
Q: Why do public AI tools create a new identity governance problem?
A: Public AI tools create a new governance problem because the same user may operate through corporate accounts, personal accounts, or unmanaged sessions, each carrying different risk and policy expectations.
Q: What do security teams get wrong about browser AI risk?
A: Many teams focus on whether AI tools are allowed, but ignore the prompt itself as the exposure event.
Practitioner guidance
- Define prompt-level policy boundaries Classify which data types can never be submitted to public browser AI tools, which can be monitored, and which require inline blocking before submission.
- Separate corporate and personal account governance Attribute browser AI activity to the user identity and the account context together, so a personal session on a managed device is not treated like an approved enterprise tenant.
- Integrate browser AI events with DLP investigations Route browser AI alerts into the same investigation workflow used for other data movement events so analysts can correlate prompts with exfiltration, insider-risk, and policy violations.
The organisations that wait for a perfect policy model will keep learning about leakage after the fact, which is already too late for sensitive prompts?
👉 Read Cyera's analysis of browser AI prompt protection and identity context →
Explore further
03/06/2026 5:18 pm
Prompt-level leakage is now a governance problem, not just a DLP gap. Public AI usage moves sensitive content into a control surface that legacy endpoint and network inspection cannot reliably see. The practical consequence is that identity, account context, and prompt content must be governed together, because any one of those signals alone is incomplete. Security programmes that still treat browser AI as a usage issue rather than an identity and data-risk issue will continue to miss the exposure point.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why prompt-level visibility should be treated as part of broader identity governance rather than a point tool.
A question worth separating out:
Q: How do enterprise DLP and browser AI governance fit together?
A: Enterprise DLP and browser AI governance should be connected, not isolated. DLP provides the broader policy and investigation layer, while browser controls address the browser prompt before submission. Together they let teams enforce consistent rules across files, emails, and AI interactions without relying on separate risk processes for each channel.
👉 Read our full editorial: Browser AI prompt leakage exposes a prompt-level governance gap
