Security: what goes into prompts
Every prompt you send may be logged, stored, or used for training (depending on provider and plan). Treat prompt content as data classification:
| Classification | Can send to AI? | Example |
|---|---|---|
| Public | Yes | Open-source code, public docs, Stack Overflow |
| Internal | Yes, on enterprise plan | Internal APIs, architecture docs, non-secret code |
| Confidential | Only with approved tools + DPA | Customer data, unreleased features, business metrics |
| Restricted | Never | Credentials, PII, encryption keys, security vulns |
Enterprise/API plans (OpenAI, Anthropic) typically offer: no training on your data, configurable retention, SOC 2 compliance. Consumer products (ChatGPT free, Claude free) may use data for training. Know which you're using.
Secret leakage prevention
The #1 security incident vector for AI-assisted development:
| Vector | Prevention |
|---|---|
Pasting .env files into prompts | .cursorignore + rules: "never paste secrets" |
| AI hardcodes API keys in generated code | Pre-commit hook scanning for secrets (gitleaks, trufflehog) |
| Agent reads credential files via MCP | Scope MCP servers; exclude secrets from indexing |
| Prompt logging in CI | Sanitize logs; don't log full prompts with secrets |
| Copy-paste from prod logs | Scrub PII/secrets before pasting; rules against raw log paste |
Add to your rules: "Never include credentials, API keys, tokens, or PII in prompts. If you need to reference a config value, use placeholder names."
IP ownership of AI output
Legal landscape (mid-2026, varies by jurisdiction — consult your legal team):
| Question | Typical enterprise position |
|---|---|
| Who owns AI-generated code? | The company (work for hire, same as human output) |
| Can AI output infringe patents/copyright? | Possible — review for copied code (GitHub Copilot litigation precedent) |
| Must AI usage be disclosed? | Depends on company policy and jurisdiction |
| Can you open-source AI-generated code? | Only if human review confirms no license conflicts |
Practical policy: AI output goes through the same IP review as human code. Run license scanners on AI-generated PRs. Don't assume "AI wrote it" means "we own it cleanly."
Enterprise AI governance framework
For teams scaling AI adoption:
Policy layer: What tools are approved? What data classifications are allowed?
↓
Configuration: Shared rules, skills, model routing standards
↓
Workflow: Review requirements, eval gates, automation guardrails
↓
Monitoring: Usage metrics, cost tracking, incident response
↓
Review cycle: Quarterly policy review, model upgrade evals
| Governance element | Owner | Frequency |
|---|---|---|
| Approved tools list | Eng leadership + Security | Quarterly |
| Data classification policy | Security/Legal | Annually |
| Shared rules/skills | Team leads | Ongoing (PR review) |
| Cost budget | Eng manager | Monthly review |
| Eval suites for production agents | Feature team | Per release |
| Incident response (AI-specific) | On-call + Security | As needed |
Team adoption patterns that work
Top-down mandates fail. What works: show real wins with metrics, weekly office hours, shared config in git, pairing sessions (experienced user + skeptic), and approved enterprise tools with clear data policies.
| Anti-pattern | Why it fails |
|---|---|
| Mandate usage quotas | Gaming metrics; resentment |
| Ban AI entirely | Shadow usage with consumer tools (worse security) |
| No policy | Inconsistent practices; security incidents |
| Only track cost | Can't justify investment |
Incident response for AI-specific issues
| Incident | Response |
|---|---|
| Secret pasted into prompt | Rotate credential; review provider data retention policy |
| AI generates vulnerable code merged to prod | Standard security incident + add eval case |
| AI automation runs uncontrolled | Kill switch for automation; review guardrails |
| Wrong data sent to AI provider | Data breach assessment per company policy |
Document these in your team's incident playbook alongside traditional categories.
Interview framing
"I establish data classification for prompts (public/internal/confidential/restricted), use enterprise plans with no-training guarantees, scan AI output for secrets and license issues, and treat AI config as governed code in git. Adoption works through demonstration and shared config, not mandates."
Senior signal: Reference your company's or a realistic data classification policy. Explain why banning AI is worse than governing it. Describe a specific governance element you'd implement first (usually: data classification + enterprise plan).
Further Reading
Hands-On Tasks (Optional)
Practical exercises — prompt drills, local MCP servers, or workflow design on paper. The goal is professional fluency, not model training.
- Draft an AI usage policy for your team30m
Write a one-page policy covering: approved tools, data classification (what can/can't go into prompts), IP ownership of AI output, secret handling, and review requirements. Base it on your company's existing policies if they exist.