Public GenAI tools are externally hosted generative AI services that employees can access directly from a browser or app. They can improve productivity, but they also create governance challenges because organisations may have limited visibility into what is entered, retained, or reused. That makes policy and technical controls essential.
Expanded Definition
Public GenAI tools are consumer or business-facing generative AI services delivered by a third party and used outside an organisation’s own controlled environment. The key boundary is not whether the tool is “AI”, but whether the organisation can govern the data path, retention model, and access conditions that come with direct browser or app use.
They differ from internal or privately hosted GenAI systems because the provider typically controls the model, prompts processing, logging, and product changes. That means the practical question is often one of visibility and control rather than raw capability. A common misunderstanding is to treat these tools as simple productivity software; in reality, they can create a new class of unmanaged information flow if employees paste sensitive material into them without policy, review, or technical guardrails.
For a standards-based perspective on the AI governance side, NIST AI 600-1 GenAI Profile is useful because it frames generative AI through risk management rather than novelty.
Examples and Use Cases
Public GenAI tools show up in day-to-day work in ways that can be useful but difficult to supervise. Typical examples include:
- Drafting emails, summaries, or meeting notes in a browser-based chat tool before the text is copied into official systems.
- Rewriting code snippets or troubleshooting scripts in an external assistant that may retain prompts or conversation history.
- Generating marketing copy, product descriptions, or policy drafts from material that was never intended for external model training or review.
- Analysing uploaded documents, screenshots, or pasted logs when the user is trying to save time but may expose more context than intended.
- Using public tools for rapid ideation while an organisation separately decides which use cases are acceptable and which require approved internal tooling.
The tradeoff is straightforward: public tools often reduce friction and increase speed, but they also reduce the organisation’s ability to bound data handling, retention, and downstream reuse. That is why teams usually need a clear distinction between low-risk experimentation and work that involves client data, source code, regulated content, or internal plans.
Security Implications
The main security issue is uncontrolled disclosure. If employees enter confidential, regulated, or strategically sensitive content into a public GenAI tool, the organisation may lose visibility over where that content goes, how long it is retained, and whether it is reused for training, review, or analytics. That creates a governance gap even when no obvious “breach” occurs.
Misuse can also create integrity risk. A model may produce plausible but incorrect output, and if staff treat that output as authoritative, the error can flow into customer communication, code, decisions, or incident response. Another practical failure condition is shadow adoption: once a tool is convenient, it tends to spread faster than policy reviews, so exceptions become normalised before ownership is clarified.
In NHI terms, the concern is not that the tool is an identity system, but that public GenAI use can become a channel through which secrets, tokens, or other machine-access material are exposed if employees paste them into prompts. That makes the boundary between acceptable assistance and credential leakage especially important.
Domain and Governance Relevance
Public GenAI tools sit at the intersection of AI governance, data handling, and acceptable-use policy. In practice, they matter because the organisation usually does not control the provider’s model behaviour, retention settings, or update cadence, yet it remains accountable for the business data employees send to the service.
That changes governance in a concrete way: approval cannot rely only on functionality. It also has to account for data classification, user permissions, logging expectations, and whether the intended use case can be safely supported in a public service at all. Where the organisation allows some use, it usually needs clear boundaries around what may never be entered, what must use approved tools instead, and who owns exceptions.
For NHIMG, the relevant identity-security question is whether the use of public GenAI creates an uncontrolled path for secrets or other machine-access material. If it does, the term stops being a simple productivity choice and becomes a control and lifecycle issue.
Risk and Threat Considerations
Public GenAI tools introduce material exposure through data leakage, retention ambiguity, and uncontrolled third-party processing. The risk is highest when users treat them as harmless drafting helpers and paste sensitive business, customer, source code, or credential material into prompts or uploads.
Failure mechanism: The weakness is usually not a technical exploit against the organisation’s own systems. It is a trust-boundary failure in which employees disclose information to an external service whose storage, logging, review, or reuse terms are outside the organisation’s direct control.
Impact: Sensitive information can become unrecoverable from the organisation’s perspective, legal or contractual obligations may be violated, and downstream security controls can fail if secrets, code, or internal context are exposed into a service the organisation cannot fully govern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS address the attack surface, NIST AI 600-1, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI 600-1 | GenAI Profile — Generative AI Profile | Directly addresses GenAI risk management, including external service use and governance. |
| Recommendation — Apply the GenAI profile to govern approved use cases, data handling, and risk controls. | ||
| ISO/IEC 42001:2023 | AI management system — AI management system | Fits organisational governance of AI use, accountability, and policy controls. |
| Recommendation — Establish AI governance rules that define approved use, oversight, and accountability. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Public GenAI tools create external data exposure and handling risks. |
| Recommendation — Classify and protect data before it is allowed into externally hosted GenAI services. | ||
| CIS Controls v8 | 14 — Security Awareness and Skills Training | Users need guidance on safe input handling and shadow AI misuse. |
| Recommendation — Train users on approved GenAI use and the risks of entering sensitive information. | ||
| MITRE ATLAS | ATLAS — Adversarial Threat Landscape for AI Systems | Relevant where public GenAI tools are abused to extract or manipulate sensitive outputs. |
| Recommendation — Map AI abuse scenarios to ATLAS techniques and monitor for prompt-based misuse. | ||
Practitioner Guidance
Why practitioners should care: Public GenAI tools are not just a user preference issue; they are a control boundary issue. The practical decision is whether the organisation can tolerate direct employee use for a given data class or whether that work must be redirected to an approved environment.
Governance implication: Treat approval as a data-handling decision, not a feature decision. The most important judgment is usually not which tool is “best,” but which inputs are acceptable, which uses require review, and who is accountable when the boundary is crossed.
Practitioner takeaway: If staff can use public GenAI tools without a clear data-entry rule, the organisation has already delegated part of its information governance to the user.
Related resources from NHI Mgmt Group
- How should security teams govern employee use of public AI tools in the browser?
- How should security teams prepare data access governance before enabling GenAI tools?
- Why do GenAI chat tools create data leakage risk for IAM and security teams?
- Why do GenAI tools create gaps that standard IAM does not close?
