They often assume account security equals data security. ChatGPT Enterprise can improve access governance with SSO and admin controls, but it does not prevent an employee from submitting sensitive content into a prompt. That is why enterprise AI use needs separate content-aware DLP and identity-aware policy enforcement.
Why This Matters for Security Teams
ChatGPT Enterprise changes the administrative surface, not the underlying human behaviour that creates data exposure. Security teams often focus on tenant controls such as SSO, role management, and auditability, then assume that approved access means safe use. That is the wrong mental model. The real risk sits at the prompt boundary, where regulated data, source code, customer records, and internal strategy can be pasted into a system that may be governed but is still only as safe as the inputs it receives.
The issue maps well to NIST Cybersecurity Framework 2.0 because governance, protection, and monitoring all need to extend beyond identity controls into data handling and acceptable-use enforcement. In practice, a secure enterprise deployment needs clear policy on what may be entered, what must be blocked, and how exceptions are approved. Without that, the organisation ends up measuring login security while missing content leakage entirely. In practice, many security teams encounter this only after sensitive material has already been entered into a chat session, rather than through intentional policy enforcement.
How It Works in Practice
A sensible deployment starts by separating access control from content control. ChatGPT Enterprise can reduce risk through SSO, group-based administration, workspace governance, and centralised retention settings, but those controls do not inspect the business context of a prompt. That is why organisations need policy layers that evaluate the content itself, the user’s role, the destination application, and the sensitivity of the data being handled.
Operationally, this usually means combining identity signals with data protection controls. The IAM stack tells the platform who is allowed to use the service. The DLP stack decides whether the user is allowed to submit a specific class of data. The monitoring stack then records whether the request was compliant, blocked, or escalated. Where the organisation uses AI for code, support, finance, or legal work, the policy engine should be tuned to those workflows rather than relying on a single global rule.
- Classify high-risk content such as source code, customer data, credentials, contracts, and incident details.
- Apply conditional access and session policies so use is tied to managed devices and approved identities.
- Use content-aware DLP to block or redact sensitive prompts before they reach the model.
- Log AI interactions for audit, but treat logs as sensitive because they can themselves contain exposed data.
- Review whether admin controls, retention settings, and user guidance align with the organisation’s data classification scheme.
For governance and model-risk framing, the NIST AI Risk Management Framework is useful because it forces teams to think about mapping risks, measuring controls, and sustaining oversight rather than just enabling a tool. Organisations that also want a practical view of prompt abuse and agent misuse should consult OWASP Top 10 for Large Language Model Applications and MITRE ATLAS for adversarial techniques that go beyond ordinary access abuse. These controls tend to break down when users access the service from unmanaged endpoints or shared browser sessions because the identity signal no longer reliably reflects the person entering the prompt.
Common Variations and Edge Cases
Tighter prompt controls often increase friction, requiring organisations to balance data protection against user productivity. That tradeoff becomes more visible in teams that depend on rapid drafting, coding assistance, or external knowledge synthesis, where overly blunt restrictions can push employees toward shadow AI use. Current guidance suggests the better answer is not blanket prohibition but risk-based control design.
There is no universal standard for this yet, especially for organisations that want to allow AI use while preventing disclosure of secrets, personal data, or confidential intellectual property. Some environments will prioritise blocking all high-risk content, while others will allow narrowly defined exceptions with logging and approval. The right choice depends on the sensitivity of the data, the legal regime, and the tolerance for residual risk.
This is also where identity and AI governance meet. If a human user can trigger actions, retrieve internal context, or route confidential material through an AI assistant, then the enterprise needs identity-aware policy enforcement that treats the prompt as a security event. NIST guidance on digital identity and the NIST Digital Identity Guidelines help distinguish strong authentication from strong authorisation, which are not the same thing in AI use cases. The practical rule is simple: secure access does not equal secure disclosure, and organisations that miss that distinction tend to discover it during a data review, not during design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Enterprise AI use needs clear governance and risk ownership. |
| NIST AI RMF | GOVERN | This question is fundamentally about AI governance and accountability. |
| OWASP Agentic AI Top 10 | Prompt abuse and unsafe tool use are core agentic AI security concerns. | |
| OWASP Non-Human Identity Top 10 | Enterprise AI workflows often expose secrets and machine identities indirectly. | |
| MITRE ATLAS | AML.T0010 | Adversarial prompt and output abuse fit ATLAS threat modeling. |
Protect secrets and service identities that may be reachable through AI workflows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
