Feature request for product/service
Cursor IDE
Describe the request
We run a dev agency working with 15+ clients simultaneously, and here’s a problem we keep running into: some clients contractually prohibit AI code generation (NDAs, regulatory compliance, IP concerns), while others actively encourage it.
Right now, there’s no way to signal these restrictions at the repository level before Cursor starts working. This means developers can accidentally violate client agreements just by opening Cursor in the wrong repo.
The Problem:
- Client A (fintech): NDA says “no AI code generation whatsoever”
- Client B (startup): “Use AI tools, go fast!”
- Client C (healthcare): “Case-by-case approval required”
A single dev switches between these repos regularly, and without repository-level signaling, it’s way too easy to slip up and accidentally use the coding agent for a repository where it’s not allowed.
Proposed Solution:
Add support for an AI-POLICY.txt file (like robots.txt for web crawlers) that Cursor checks before starting:
# AI-POLICY.txt
Coding-agent: *
Disallow: /
Reason: NDA with client prohibits AI code generation
Contact: [email protected]
How it would work:
- Developer opens Cursor in a repo
- Before any AI kicks in, Cursor checks for
AI-POLICY.txt - If
Disallow: /is present, show a warning:⚠️ AI Policy Restriction Detected This repository prohibits AI coding assistance. Reason: NDA with client prohibits AI code generation Contact: [email protected] Proceed anyway? (y/N) - Log the decision for audit trail
Downsides of existing features?
.cursorrules: Already running AI by the time rules are read- Project settings: Too technical, buried in config, no clear “stop” moment
- System-wide settings: Too broad - would affect ALL repos on my machine
What makes this different:
This is a pre-execution check - happens before any API call, before any AI context building. It’s a compliance/legal signal, not a technical restriction.
Think of it like this: .cursorrules tells Cursor how to behave, AI-POLICY.txt tells Cursor whether it should be there at all.
Benefits:
- Repository-scoped (different repos = different rules)
- Human-readable (legal teams can verify it)
- Version-controlled (visible to whole team)
- Audit trail (shows policy was checked and potentially overridden)
- Soft enforcement (warning + choice, not hard block)
Use cases:
- Dev agencies managing multi-client projects
- Enterprise teams with regulatory compliance needs (healthcare, finance, gov)
- Gradual AI adoption (some projects yes, others no)
This would be a huge win for anyone working in compliance-sensitive environments or with multiple clients. Right now we have to rely on developers “just remembering” which repos are off-limits, which… doesn’t scale well 
Would love to hear thoughts from others dealing with similar situations!