A finance analyst pasting a customer contract into a public chatbot is not a policy problem first. It is a visibility problem. The same is true when a developer connects an unapproved coding assistant to a source repository or a business unit deploys an embedded model without security review. The best practices for AI security teams start by establishing what is actually happening across the enterprise, not by assuming approved tools are the only tools in use.
AI adoption is moving faster than most security review processes. Employees can access new models in a browser, through an extension, inside a SaaS platform, or through an API call that never appears in the usual asset inventory. A security program that relies only on procurement records, acceptable-use policies, and annual questionnaires will see a small portion of the exposure.
1. Build an AI usage inventory from observed behavior
Start with continuous discovery. Security teams need to identify the AI services, models, browser-based tools, APIs, embedded copilots, and agent frameworks being used across users, endpoints, cloud environments, and business units.
This inventory should not be a static catalog maintained by hand. AI usage changes too quickly. A useful inventory connects each observed service to practical context: who used it, from which team, through which environment, what type of interaction occurred, whether the tool was approved, and what data classification may have been involved.
Procurement and IT can contribute a list of sanctioned tools, but that list is a baseline, not evidence of complete adoption. The difference matters. An approved AI tool can be used in an unsafe way, while an unapproved tool may be handling sensitive material with no controls at all.
2. Separate discovery from enforcement
Many organizations begin with a broad restriction: block public AI tools, require approval, and assume the problem is contained. That approach can be necessary for specific regulated workflows or high-risk data. But enforcement without visibility often drives use into personal accounts, unmanaged devices, or less visible channels.
Discovery gives security teams the facts needed to make proportionate decisions. Some usage may call for immediate containment, such as credentials submitted to an external model. Other activity may warrant a safer approved alternative, targeted education, or a review of a business process that has outgrown existing tools.
The right control depends on the risk. A marketing team using an approved model for public copy is not the same case as an engineering team sending proprietary code to an unvetted service. Treating both as identical creates friction without improving security outcomes.
3. Classify risk at the interaction level
A domain-level view is useful, but it is incomplete. Risk is frequently found in the interaction itself: the prompt, uploaded file, connected data source, model output, or downstream action taken by an agent.
Security teams should prioritize visibility into interactions involving sensitive data, intellectual property, regulated records, authentication material, source code, financial information, legal documents, and internal strategy. They should also identify prompts that attempt to bypass model safeguards, extract restricted information, or automate actions beyond a user’s normal role.
Context is what turns a signal into an investigation. An alert that says a user accessed an AI service is rarely enough. An alert that identifies the user, business unit, model, data category, interaction pattern, device, and policy posture gives an analyst a defensible starting point.
Focus on exposure paths, not just model names
A model can be accessed through a standalone website, a collaboration platform, a developer IDE, an enterprise SaaS application, or a custom application. The exposure path affects the controls available and the evidence needed for review.
For example, an approved enterprise model may retain fewer prompts and offer contractual protections, while the same user interacting with a public version of that model may create a materially different data-handling risk. AI security teams should evaluate the service configuration and account context, not merely recognize a familiar brand name.
4. Make suspicious AI use detectable and explainable
AI-related alerts should map to behavior that security teams can explain. High-value detections include repeated submission of sensitive content, large-volume prompt activity, access from unusual locations or devices, use of newly observed tools, attempts to evade controls, and unexpected agent actions against enterprise systems.
Detection logic should be tuned against real usage patterns. An engineering organization may legitimately generate high volumes of code-related prompts. A sudden increase in uploads of customer data to a public service, by contrast, deserves immediate scrutiny. Baselines should account for department, role, approved tooling, and normal workflows.
Explainability is operationally necessary. Analysts need to understand why an event was flagged, what evidence supports the risk assessment, and which facts remain unknown. This reduces alert fatigue and helps legal, privacy, HR, and leadership teams assess the incident without relying on vague claims that AI use was “risky.”
5. Connect AI visibility to incident response
AI security cannot operate as a separate reporting exercise. Findings need to enter established security workflows with clear ownership, severity criteria, evidence retention expectations, and escalation paths.
A practical response playbook should answer a few questions quickly: What information was exposed or acted upon? Was the model or service approved? Is the activity ongoing? Which accounts, devices, repositories, or business processes are affected? What immediate containment is appropriate?
Containment may involve revoking an API key, disabling an extension, restricting access to a service, removing a connected data source, or requiring a user to move to an approved environment. Longer-term remediation may include improving data-loss controls, revising application architecture, or providing a sanctioned alternative that meets the user’s operational need.
Security teams should preserve investigation context before taking action whenever feasible. AI interactions can be short-lived, and an external service may not retain the evidence needed to establish scope later. Evidence should support internal review, compliance obligations, and potential legal inquiry without indiscriminately collecting more employee content than necessary.
6. Set governance policies that match observed reality
Policy should follow evidence. Once a team understands which tools and workflows are in use, it can define clear rules for approved services, permitted data types, prohibited use cases, third-party model access, agent permissions, and review requirements.
Policies work best when they are specific enough to guide decisions. “Use AI responsibly” is not actionable. A policy that states which data classifications may be used with which approved services, when human review is mandatory, and who may connect models to internal systems is far more useful.
There is also a trade-off between precision and maintainability. A policy that names every individual model will become obsolete quickly. A policy based on data sensitivity, service assurance, account controls, retention terms, and system permissions is more durable as the model landscape changes.
7. Give business teams a secure path forward
Security teams should expect employees to use AI where it saves time or improves output. The objective is not to eliminate experimentation. It is to prevent sensitive data exposure, unmanaged access, and unaccountable automation while enabling legitimate work.
That requires approved options that are usable. If the sanctioned tool is unavailable, slow, or incapable of supporting a real workflow, shadow AI will persist. Security leaders should bring observed usage data into conversations with IT, legal, procurement, and business owners to decide where enterprise-grade access is justified.
Training should be tied to actual behavior. A generic awareness module will not address a developer’s questions about code assistants, an HR team’s questions about applicant data, or a sales organization’s use of customer information. Targeted guidance is more credible when it reflects the tools and scenarios people encounter.
8. Measure the AI security program by response quality
Counting discovered AI tools is useful, but it does not prove risk reduction. Better measures include time to identify unapproved use, time to investigate a high-risk interaction, percentage of AI activity with known ownership, rate of sensitive-data policy violations, and the number of risky workflows moved into approved environments.
Leaders also need trend reporting that distinguishes growing adoption from growing exposure. An increase in AI use may be expected. The meaningful question is whether that use is becoming more visible, better governed, and easier to investigate.
ModelSight approaches this problem from the security operations perspective: discover usage, observe interactions, understand context, identify risk, and act. That sequence keeps policy and enforcement grounded in evidence rather than assumptions.
The practical test is simple: when an AI-related concern reaches the security team, can they determine what happened, who and what was affected, and what action is justified? If the answer is no, the next investment should improve visibility. Control becomes more effective when it is built on a clear view of real behavior.