How should organisations govern AI prompts and secrets on managed devices?

Why This Matters for Security Teams

Managed devices are often the last control point before prompts, tokens, and copied records leave the endpoint and enter chat tools, copilots, or OWASP Non-Human Identity Top 10 style workflows. That makes endpoint governance a practical security issue, not just a usability concern. If the device allows sensitive text to move unchecked, then AI tools can become an exfiltration path, a policy bypass, or a source of unintended data retention.

The main mistake is treating prompts as harmless because they are not traditional files. In practice, prompts can contain credentials, customer data, incident details, or internal code fragments, and copied text may be re-used across systems with different trust boundaries. Organisations also need to account for prompt injection through web pages, local files, and browser extensions, especially where managed devices are allowed to interact with multiple AI services. The NIST Cybersecurity Framework 2.0 is useful here because it frames this as a governance and protective controls problem, not a single-tool issue. In practice, many security teams encounter this only after a secret has already been pasted into an assistant or a copied record has been synchronised into an AI-connected workflow.

How It Works in Practice

Effective governance starts with classifying what the endpoint is allowed to see, copy, paste, and transmit. On managed devices, that usually means combining data loss prevention, browser controls, and endpoint detection so that content can be inspected before it reaches approved or unapproved AI services. The policy should distinguish between ordinary operational text and high-risk material such as API keys, session tokens, certificates, private customer records, and regulated data.

A practical control stack usually includes:

• Clipboard and paste inspection for secrets and sensitive identifiers.
• Browser isolation or URL allowlisting for approved AI services and MCP-connected tools.
• Endpoint DLP rules that detect tokens, key formats, and sensitive document patterns.
• Local alerting or blocking when prompts include secrets, regulated records, or source code fragments.
• Central logging so security teams can review where high-risk content was attempted, not just whether it was blocked.

Governance should also cover the identity of the tool itself. An AI assistant or MCP server is not just another app; it may act with delegated authority, cached context, and access to downstream systems. That makes the question partly one of non-human identity control, which is why NHI guidance matters as much as endpoint hygiene. Where organisations have formal control mapping, the least-privilege and monitoring expectations described in OWASP NHI guidance help translate policy into operational checks.

Just as important is limiting persistence. If prompts are stored in browser history, synced notes, or unmanaged caches, the organisation loses control over later reuse. Best practice is evolving, but current guidance suggests minimising local retention, separating personal and corporate accounts, and requiring explicit approval before sensitive content can be pasted into generative AI tools. These controls tend to break down when managed devices are heavily customised by developers because local tooling, extensions, and approved exceptions create hidden paths around the policy.

Common Variations and Edge Cases

Tighter prompt and secret controls often increase friction for users, requiring organisations to balance developer productivity against data loss and misuse risk. That tradeoff becomes sharper when teams rely on code assistants, browser-based copilots, or mobile endpoints where inspection and blocking are harder to enforce consistently.

There is no universal standard for this yet, so organisations should separate settled controls from emerging practice. For example, blocking pasted secrets is widely defensible, but inspecting all prompt text for every AI interaction may be too intrusive without a clear legal or business basis. In regulated environments, especially where customer data, payment data, or confidential source material is involved, the threshold for control is lower and auditability matters more. Where AI tools are connected through MCP, governance should extend to the tool chain itself, because the real risk may sit in what the assistant can invoke, not just what the user types.

One common edge case is sanctioned internal use of AI with sensitive data. In that case, organisations may need explicit exceptions, stronger logging, and tighter NHI governance for service accounts, API tokens, and backend connectors. Another edge case is bring-your-own-device access to corporate AI services. Managed-device assumptions do not hold there, so the policy should default to reduced trust and narrower data access. This is where endpoint rules, identity controls, and data handling policy need to operate together rather than as separate programmes.

Related resources from NHI Mgmt Group

• How should organisations govern private AI apps used on mobile devices?
• How can organisations govern AI tools that may route prompts to different models?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• How can organisations govern AI agents that use service accounts and tokens?