Over the past several months, we have had direct conversations with security engineers and security leads at growing companies ranging from around 80 to 450 employees. The question driving most of those conversations was the same: what are other teams doing about AI tool governance? Not "what is the correct answer" but "what are real people actually doing, given real constraints."
The clearest finding: nobody is blocking all AI tools. A few organizations tried in 2023 and 2024, and most reversed course within three to six months. Beyond that, three distinct governance postures have emerged, driven by different combinations of regulatory exposure, technical capacity, and leadership appetite.
Posture One: Approved List with Passive Monitoring
The most common posture at companies in the 80 to 200 employee range is an approved tools list combined with some form of passive traffic monitoring. The approved list is maintained by IT or security and typically includes two to five tools: one or more general-purpose AI chat interfaces (almost always including ChatGPT in some tier), a code assistant (usually Copilot), and occasionally a vertical-specific tool if the company is in a regulated industry.
Passive monitoring in this posture usually means DNS and proxy logs that capture AI service destination traffic, aggregate it by department, and report on new AI tool destinations as they appear. Some teams run this through a SIEM. Others pull CSV exports weekly and scan manually. The purpose is inventory: knowing which AI tools are active and which teams are using them, without classifying prompt content.
The limitation security leads in this posture acknowledge directly: they know traffic is flowing, but they cannot tell you what is in it. When pressed on what would change that, the consistent answer is either "a data classification incident that gets visibility" or "leadership signing off on a more active inspection layer."
This posture is not naive. For companies without significant regulatory exposure, where the primary AI tools are well-known vendors with enterprise data handling agreements, destination-level monitoring is a proportionate starting point. The risk is that it provides inventory visibility but not content visibility, and those are different problems.
Posture Two: Active Inspection on High-Risk Cohorts
The second posture, less common but growing, focuses active detection on the employee populations that carry the highest prompt-data risk rather than trying to achieve full coverage immediately.
The selection criterion is usually a combination of role and data type: customer support teams handling PII, engineering teams with access to proprietary codebases and live credentials, and finance or HR teams handling regulated data types. These cohorts get a layer of inline prompt inspection. Other departments operate under the approved list model from posture one.
The rationale is pragmatic. Full deployment requires organizational buy-in, change management, and sometimes legal review to ensure the inspection methodology is compliant with employment law in the relevant jurisdictions. Scoping to high-risk cohorts first lets the security team build operational muscle, refine detection rules against real traffic, and demonstrate value through concrete findings before expanding.
Security leads we have spoken with who use this approach tend to be at companies with active regulatory obligations: healthcare-adjacent businesses, financial services companies, or companies that have recently been through a security audit where AI tool egress was flagged as a gap. The urgency to address the highest-risk population is concrete rather than hypothetical.
Posture Three: Policy-Led with Technical Backstop
The third posture leads with policy documentation and employee education, with technical controls as a secondary enforcement layer rather than the primary one.
This posture is most common at companies where the security team has limited headcount relative to the scale of AI tool adoption. Writing, communicating, and maintaining an AI acceptable use policy is within the capacity of a security team of one or two people. Deploying and maintaining an active inspection infrastructure is a larger operational commitment that may require additional resource justification.
In this posture, the policy specifies which AI tools are approved, what data categories are prohibited in prompts, and which roles have which restrictions. Technical enforcement is applied at the network perimeter level (blocking unapproved AI service destinations) rather than at the content level. The combination of policy documentation plus destination blocking provides a defensible compliance posture at lower operational cost than full content inspection.
The honest limitation here is that destination blocking addresses the tool selection decision but not the content decision. An employee using an approved tool who pastes customer data into a prompt is operating on an approved tool, past the destination block. The policy says they should not. The technical layer does not enforce the specific prohibition. That gap is understood by security teams in this posture as a calculated tradeoff given current capacity.
What Is Not Working: The Approaches Teams Have Abandoned
Across the conversations we have had, several governance approaches have been tried and discontinued.
Blanket blocking of AI tool destinations. Several companies imposed comprehensive blocks on AI provider traffic in 2023 or early 2024. All of them that have spoken with us about it encountered the same outcome: employees shifted to personal devices, personal accounts, and mobile data connections. The net effect was to move AI tool usage from corporate-managed infrastructure to personal infrastructure where governance is impossible rather than merely difficult. Most teams that tried this reverted the block within a quarter.
Manual prompt review. A few organizations attempted to implement manual review workflows for AI prompts flagged by automated detection. This approach generated more triage volume than the security team could process at sustainable pace. The practical outcome was that review backlogs grew, turnaround times became unacceptable to employees, and threshold thresholds were raised to reduce flagging volume to a manageable level. The sequence of events is a version of the recall-precision problem applied to operational capacity.
Relying on AI vendor logging. Vendor usage logs tell you that prompts were sent. They do not tell you what was in them. Security teams that built governance programs primarily on vendor log data found they had audit trail coverage without content visibility. Useful for forensics after an incident, not useful for preventing one.
Where the Industry Is Moving
The direction of travel is toward posture two: active inspection on high-risk cohorts, with gradual expansion. This is being driven by two forces.
Regulatory pressure is increasing. GDPR enforcement actions related to AI tool data handling have materialized in several EU member states. HIPAA guidance on AI tool usage as a business associate agreement trigger has become more concrete. CCPA's processor obligations are being interpreted to include AI inference endpoints. Companies with regulatory exposure are finding that destination monitoring plus policy documentation does not satisfy audit requirements when a regulator asks "how do you know what customer data is leaving your environment through AI tools."
Tooling has matured. In 2023, building prompt content inspection required significant custom infrastructure investment. The viable options were either API scanning after the fact (which creates the same latency exposure as destination blocking for false positives) or complex network proxies that required significant engineering effort to deploy without breaking SSL and causing usability issues. The tooling available in 2025 and 2026 is more deployable for security teams that are not primarily infrastructure engineering teams, which expands the set of organizations that can operate posture two without adding headcount.
The Convergence Point
The security teams we speak with are not starting from the same place, and the pace of movement toward more active governance is driven by factors that vary by organization. But the direction is consistent: organizations are moving from "we know which tools are in use" toward "we know what kinds of content are moving through those tools," and the triggering events are usually regulatory audit cycles, incident investigations, or a concrete finding during a security review that makes the gap visible in a way that justifies the investment.
The companies that get ahead of those triggering events are the ones that do the content visibility work before the incident, not after. That is a harder organizational case to make without a concrete incident driving it. But the security leads who have made it tend to frame it the same way: you are better off knowing what is flowing than not knowing, regardless of whether you have seen a violation yet.