How should security teams apply controls to LLM prompts in browser and endpoint workflows?

Security teams should treat prompts as a data exposure path, not just a model interaction. The practical control point is where text is entered and returned, including browser-based tools and endpoint apps. That means discovering sanctioned and unsanctioned AI use, classifying content before submission, and applying policy at the point of input and output rather than relying only on perimeter DLP.

Why This Matters for Security Teams

Browser prompts and endpoint inputs are not harmless user text. They often carry source code, customer data, internal plans, secrets, and operational instructions into AI tools that can store, transform, or echo that content outside normal application controls. Security teams need to treat the prompt as a sensitive data path, with the same seriousness as email, uploads, and clipboard transfer. Guidance from the OWASP Agentic AI Top 10 and NIST AI 600-1 Generative AI Profile both point toward runtime governance, not just model selection.

NHIMG research shows why this is urgent: in AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already performed actions beyond intended scope, including inappropriately sharing sensitive data and revealing credentials. That is the same problem pattern security teams see in browser copilots, desktop assistants, and endpoint plugins when users paste material without real-time controls. In practice, many security teams discover prompt leakage only after sensitive content has already entered a third-party workflow, rather than through intentional policy enforcement.

How It Works in Practice

The practical control point is where the prompt is created, modified, transmitted, and rendered back to the user. That means security teams should classify content before submission, inspect prompts in the browser or endpoint, and apply policy at output as well as input. The model backend may be external, but the control plane should stay local to the enterprise session. Current best practice is to integrate browser extension controls, endpoint DLP, and sanctioned AI gateway enforcement so that risky text is blocked, redacted, or downgraded before it leaves managed surfaces.

For teams building this capability, the workflow usually includes four steps: discovery of sanctioned and shadow AI use; prompt classification for regulated data, credentials, and confidential context; policy enforcement based on user role, device trust, and destination; and logging for audit and incident response. In parallel, access decisions should map to NIST AI Risk Management Framework principles for govern, map, and manage activities. When agent-like tools are involved, the CSA MAESTRO agentic AI threat modeling framework is useful for understanding how prompts become task instructions that can trigger tool use, data movement, or escalation.

NHIMG coverage of prompt-adjacent compromise in LLMjacking: How Attackers Hijack AI Using Compromised NHIs reinforces the operational lesson: once secrets are exposed, attackers can move fast. Endpoint and browser controls should therefore prioritize secret detection, copy-paste inspection, allowlisting of approved AI destinations, and automatic blocking of prompts that contain tokens, keys, customer identifiers, or regulated records. These controls tend to break down in unmanaged browsers, personal devices, and local desktop AI tools because policy cannot be reliably enforced where the enterprise cannot inspect the session.

Common Variations and Edge Cases

Tighter prompt controls often increase user friction and false positives, requiring organisations to balance data protection against productivity and exception handling. That tradeoff is especially sharp in software development, support, and research workflows where users legitimately need to paste code, logs, or incident details into AI tools. Best practice is evolving here: there is no universal standard for whether the control should sit in the browser, the endpoint agent, the secure web gateway, or the AI proxy, and many enterprises end up using a layered approach.

Some workflows need context-aware exceptions rather than blanket blocking. For example, an internal approved model may be allowed to receive more detailed prompts than a public model, but the same policy should still redact secrets and highly sensitive records. A browser extension may be enough for managed desktops, while high-risk users may require endpoint enforcement and session logging. In environments with bring-your-own-device access, offline desktop assistants, or shared terminals, prompt controls become harder because local inspection is incomplete. In those cases, current guidance suggests combining identity-aware access with destination allowlisting, minimal prompt retention, and strong user education. This aligns with the OWASP NHI Top 10 view that data exposure is often a control failure, not just a user mistake.

Related resources from NHI Mgmt Group

• How should security teams implement runtime controls for agentic workflows at the endpoint?
• How should security teams evaluate browser-level controls for identity attacks that bypass EDR and endpoint telemetry?
• How should security teams govern browser-based AI prompts that may contain sensitive data?
• How should security teams design agent workflows to avoid unnecessary user prompts?