Why do organisations need AI usage controls even when employees are using approved collaboration and productivity platforms?

Why This Matters for Security Teams

Approved collaboration and productivity platforms are not a safe zone by default. Once employees can paste prompts, upload files, or connect apps, sensitive content can still leave the organisation, be retained in account histories, or be processed in ways the business never intended. That is why ai usage control are about governing data movement, not banning tools.

NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because it treats data protection as a control problem across transmission, storage, access, and monitoring. NHIMG’s Ultimate Guide to NHIs — Standards reinforces the same point for machine-mediated environments: the identity and policy layer must follow the data wherever it goes.

This matters even more when secrets and sensitive code are involved. In The State of Secrets in AppSec, GitGuardian & CyberArk report that 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases. In practice, many security teams discover exposure only after a user has already shared the wrong material with a trusted platform, rather than through intentional data-loss design.

How It Works in Practice

AI usage controls work best when they are treated as layered guardrails around content, identity, and approved actions. The platform may be approved, but the specific interaction still needs to be evaluated against classification, user role, and sensitivity of the payload. That means policy should follow the content into the tool, not stop at the login screen.

A practical control stack usually includes:

• Data classification rules that flag source code, credentials, customer data, and regulated information before prompts are submitted.
• Content inspection or DLP policies that block uploads, redaction failures, and copy-paste of prohibited material.
• Conditional access and RBAC so only the right users can use higher-risk AI features or connectors.
• Logging and alerting for prompt history, file sharing, exports, and third-party app connections.
• Retention and deletion settings that limit how long sensitive interactions remain searchable in user accounts.

This is where NHIMG’s The State of Secrets in AppSec is especially instructive: remediation is often slow, and confidence in controls is frequently higher than actual containment. Current guidance suggests organisations should align AI usage policies with existing data handling rules rather than creating a separate, looser standard for “trusted” collaboration tools.

Operationally, teams should define which content types can be summarized, transformed, or shared externally, then enforce those rules through policy-as-code, endpoint controls, and SaaS configuration. These controls tend to break down when users can forward content into unmanaged personal accounts or connect sanctioned platforms to unsupervised third-party extensions, because policy enforcement no longer stays within the approved workspace.

Common Variations and Edge Cases

Tighter AI usage controls often increase user friction, requiring organisations to balance productivity gains against the risk of accidental disclosure. That tradeoff becomes sharper in engineering, legal, finance, and customer support, where the same platforms may be used for both routine work and highly sensitive material.

Best practice is evolving for shared spaces, external guests, and AI assistants that can access files, chat histories, or connected storage. There is no universal standard for this yet, but a conservative approach is to treat any workspace with external sharing, plugin access, or retention beyond business need as higher risk. That means stronger inspection, narrower connector approval, and more aggressive defaults for exports and history retention.

NHIMG’s Ultimate Guide to NHIs is useful here because it frames modern AI tools as environments that can create and move machine identities, not just user convenience features. Organisations often miss that nuance when a “productivity” platform becomes a de facto data broker through integrations. In those cases, policy exceptions, unmanaged plugins, and permissive sharing settings are usually the real failure point, not the core AI model itself.

Related resources from NHI Mgmt Group

• Why do employees keep using shadow IT even when organisations prefer approved tools?
• Why do organisations need different controls for AI-generated code and for employees using GenAI systems with sensitive data?
• How should organisations connect AI usage to IAM and privacy controls?
• How should organisations govern AI usage when employees use unapproved tools?