Recommendation:
Adopt a layered guardrail approach: teach Copilot via in-file prompts and test templates, block risky patterns with pre-commit/CI checks, and enforce via code review + automated scanners. Don’t rely on Copilot settings alone — use repository-level artifacts that shape completions and pipeline checks that reject dangerous commits.

Why this works (short):
Copilot uses file and repo context to suggest code, so a clear test-header plus secure templates steers completions. Automated checks catch accidental or malicious snippets Copilot might propose. This is low-friction and scales from small teams to enterprise CI policies.

Practical steps (how-to):
1) Add a one-line policy comment at the top of every test file (Copilot reads comments):
# TEST-GUIDELINES: No direct filesystem writes/reads outside pytest tmp_path/tempfile; use mocks for subprocess/network; forbidden: open(...,'w'), os.remove, shutil.rmtree, subprocess.*
- This visibly biases completions toward safe patterns.

2) Provide secure test templates/snippets in repo (tests/_template.py):
- Examples using pytest tmp_path, tempfile, unittest.mock, pytest-mock, fake filesystem libraries (pyfakefs) or in-memory fixtures.
- Encourage `with tempfile.TemporaryDirectory()` or `tmp_path` usage.

3) Pre-commit hook (fast feedback):
- Simple grep-based reject script that fails on banned tokens in staged test files, e.g. opens*(|subprocess.|os.remove|shutil.rmtree
- Better: a semgrep rule set or custom linter to detect filesystem writes, raw path concatenation, or direct network calls from tests.

4) CI enforcement (strong gate):
- Run the same semgrep/CodeQL/static-analysis rules and fail the build on hits.
- Optionally run a test-only sandbox step: execute unit tests in a restricted container/namespace to catch stray filesystem/network effects.

5) Code review checklist + PR template:
- PR template asks: “Does this test access the filesystem or network? If so, justify and show sandbox use.”
- Reviewers verify mocks and tmp_path usage.

Example prompt snippet to put into resources or a project-wide note (Copilot uses surrounding context):
"When writing tests, prefer in-memory mocks and pytest tmp_path. Do NOT perform filesystem writes or execute subprocesses. If an external resource is needed, mock it or use a disposable tempdir."

Decision criteria (pick based on your org):
- Budget: small teams → file headers + pre-commit greps; medium/large → semgrep + CI + sandbox; enterprise → add policy controls via GitHub Enterprise & automated scanning.
- Skill level: junior-heavy teams → ship templates + strict CI; senior teams → rely more on code-review culture plus automated checks.
- Workflow stage: early prototyping → warnings and dev-docs; production tests → strict CI rejection + sandboxed test runs.

Best-for / Avoid-if:
- Best for: teams that want low-friction protection and quick developer feedback.
- Avoid if: you need heavy-handed blocking at generation time (Copilot cannot reliably enforce per-repo security policies on its own).

Practical checklist (copy into repo README/CONTRIBUTING):
- [ ] Add TEST-GUIDELINES header to test files
- [ ] Commit secure test templates/snippets
- [ ] Install pre-commit hook blocking banned tokens
- [ ] Add semgrep/CI scan to fail on risky patterns
- [ ] Add PR template check and reviewer guidance
- [ ] Optionally sandbox tests in CI for extra assurance

If you use GitHub Copilot, add the comment + templates in every PR and enforce the CI checks so suggestions become safe by context and policy.

Compare GitHub Copilot and Cursor