CISO Governance for Generative AI: Data, Policy, Response, Vendors

ProxyLogon Was a Reminder That “Patch Later” Is a Strategy for Getting Owned

ProxyLogon, tracked as CVE-2021-26855 and chained with CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065, gave attackers a clean path from SSRF to remote code execution on Microsoft Exchange Server. Hafnium used it at scale before most admins finished their first coffee, and the result was ugly: tens of thousands of organizations hit, web shells dropped, and a lot of “we didn’t think our mail server was that exposed” postmortems. Generative AI is now creating the same kind of gap, except the entry point is a prompt box and the payload is your own data.

If employees are already pasting customer records, source code, incident notes, and legal drafts into ChatGPT, Claude, or Gemini, then your governance problem is not theoretical. It is active. You do not need a futurist to tell you that; you need a policy that survives contact with a browser tab and a deadline.

Classify Inputs Before You Argue About “AI Strategy”

The first control is boring, which is usually how real controls work. You need a data classification scheme that explicitly covers prompts, attachments, pasted text, and model outputs. “Confidential” is not enough if the policy stops at file shares and email. A sales rep can leak a pricing sheet into ChatGPT in 12 seconds, and the model will happily process it because it was never asked to care about your taxonomy.

Separate data into at least four buckets: public, internal, sensitive, and restricted. Restricted should include regulated data, credentials, source code, incident artifacts, unreleased financials, and anything covered by attorney-client privilege. Then map each bucket to allowed tools. If a tool retains prompts for training, logs prompts in a third-party environment, or routes data through a region you did not approve, it does not get access to restricted data. That is not radical. That is table stakes.

Do not rely on “user judgment” here. Users also think “temporary admin” means “safe,” and we all know how that story ends.

Acceptable Use Needs Teeth, Not a Slide Deck

Your AI acceptable use policy should answer three questions: what can be entered, what can be generated, and what can be retained. If you cannot answer those in one page, the policy is already too vague to enforce. Write it so a manager can apply it without calling legal every time someone wants to summarize meeting notes.

Be explicit about prohibited inputs: credentials, secrets, customer PII, payment data, health data, export-controlled material, and proprietary code unless the tool is approved for that class. Then define approved use cases: drafting non-sensitive text, summarizing public documents, brainstorming, and code explanation against sanitized snippets. If you want to ban consumer AI tools outright for sensitive work, say so. Half-measures are how shadow IT gets a budget line.

Here is the contrarian part: “AI literacy training” is not your primary control. It is useful, but only after you have hard technical guardrails. Training people not to leak data into unsanctioned tools is like training them not to click phishing links while leaving macro execution enabled. Noble. Not sufficient.

Put Guardrails in the Browser, Not in the Org Chart

If you want fewer surprises, control the endpoints and the network. Use CASB or secure web gateway policy to detect and restrict access to unsanctioned AI services. Add DLP rules that inspect prompt content and uploads for secrets, PII, and source code fingerprints. Microsoft Purview, Netskope, and Zscaler can all help here, assuming you configure them like a security control instead of a checkbox exercise.

For approved AI tools, require SSO, role-based access, and tenant-level logging. If the vendor cannot give you audit trails for prompts, outputs, file uploads, and admin actions, you are not running governance; you are outsourcing denial. Also verify whether the vendor uses your data for training by default. OpenAI, Anthropic, and Google have different enterprise data handling models, and “we thought enterprise meant private” is not a defense anyone wants to write down.

A practical control: block paste-and-upload into public AI tools from endpoints handling restricted data. It is crude, yes. It is also effective. Security people love elegant frameworks right up until a clipboard ruins the quarter.

Rehearse an AI-Specific Incident, Not a Generic One

Your incident response plan needs a branch for AI misuse and AI compromise. That includes employee prompt leakage, malicious prompt injection in third-party content, model output that exposes sensitive data, and vendor-side exposure of prompts or fine-tuning data. If you have a breach playbook that starts with “determine scope,” you are already behind. Scope in AI incidents often means identifying which prompts, documents, embeddings, and downstream systems were touched, and that is a different mess.

Run a tabletop where someone pastes a customer contract into a public chatbot, the vendor retains the data, and legal demands to know whether the text was used in training. Then run another where a retrieval-augmented generation system is poisoned through a malicious document in SharePoint or Confluence and starts surfacing bad guidance to internal users. Prompt injection is not science fiction; it is just untrusted text with ambition.

Include forensics in the plan. You need logs of prompt submissions, file uploads, model responses, user identity, and the exact model/version in use. Without that, you will spend days reconstructing events from browser history and Slack messages, which is a fine hobby but a poor incident response strategy.

Vet Vendors Like They Can Hurt You, Because They Can

Before you approve an AI vendor, ask for the same things you would demand from any system that handles sensitive data, then add a few more. You need data retention terms, training-use restrictions, encryption details, subprocessors, regional processing options, and incident notification timelines. Ask how they handle prompt logs, embeddings, and customer-tuned models. Those three are where the useful data hides.

Review SOC 2 reports, but do not confuse them with assurance. SOC 2 tells you a vendor had controls at audit time. It does not tell you they will survive the next supply-chain mess. SolarWinds taught that signed software can still be the delivery vehicle for a backdoor, and the badge on the box was not much comfort to the 18,000 affected customers.

Also evaluate model access paths. If the vendor exposes APIs, check for abuse controls, rate limits, and tenant isolation. If they offer retrieval over your documents, confirm whether the index is segregated and whether deleted content is actually deleted. “Eventually” is not a retention policy.

The Bottom Line

Treat generative AI like a data exfiltration channel with a friendly interface, because that is often what it is. Classify what can go into prompts, block unsanctioned tools on managed endpoints, and require logging for every approved model interaction.

Then rehearse two incidents now: employee data leakage into a public model, and prompt injection through a trusted content source. If your vendor cannot answer retention, training, and audit questions in writing, you already have your answer.

References

• CISA: Microsoft Exchange Server Vulnerabilities (ProxyLogon/CVE-2021-26855): https://www.cisa.gov/news-events/alerts/2021/03/03/patch-now-microsoft-exchange-server-vulnerabilities
• Microsoft: Guidance for preventing, detecting, and hunting for CVE-2021-26855 Exchange Server vulnerabilities: https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
• OpenAI API data usage policies: https://openai.com/policies/api-data-usage-policies
• Anthropic data usage and privacy: https://www.anthropic.com/legal/privacy
• NIST AI Risk Management Framework 1.0: https://www.nist.gov/itl/ai-risk-management-framework