Version: 2026-06-05
Summary
- AI must not receive blanket full access.
- AI needs a defined project workspace.
- Commands are blocked by default.
- Allowed commands are approved per project and purpose.
- Production systems, secrets, home directories, and other customer projects remain off limits.
Topic
Rights and access for AI assistants, agents, and AI-enabled IDEs in everyday development work.
Starting Point
AI assistants often need access to source files, package managers, tests, linters, shell commands, Git, browser tools, issue trackers, or local services. This is practical, but it turns an assistant into a local actor with real effects.
The unsafe default is full trust: the tool can read everything, execute arbitrary commands, and reach external systems. That is too broad for customer projects.
Risk
A wrong command can delete files, alter dependencies, start external communication, leak local information, or touch production-like systems. Even if the AI did not intend harm, the effect is still real.
Recommendation
Use a defined working area and a command gate. Commands are denied by default. A command becomes allowed only when the project has approved it for a specific purpose.
A practical model is:
- reading project source: allowed when the context rules permit it
- editing project files: allowed inside the repository
- running tests and linters: allowed if listed for the project
- installing dependencies: review required
- Git commit and push: human approval required
- production commands: forbidden unless an explicit operational process exists
The same logic applies to IDE actions and MCP/tool integrations. If an action has an effect, it needs a boundary.
Command Classes
Safe commands are usually read-only or limited to local verification. Risky commands change dependencies, services, infrastructure, credentials, Git history, or external systems.
The project should document which commands belong to which class.
Review Checklist
- Can the assistant access only the relevant project workspace?
- Are commands blocked unless approved?
- Are dependency, Git, deployment, and production commands separated?
- Is there a visible allowlist or equivalent project rule?
- Does every new command have a clear purpose?
Wall rules
AI does not execute commands directly. Commands go through a project gate.
New commands are blocked. Approval is project-specific and purpose-bound.
Open questions for a project
- Which commands are useful enough to allow by default?
- Which commands always require confirmation?
- Which systems must never be reachable from AI tools?
- How are allowlist changes reviewed?