To use GitHub Copilot without accepting unsafe code, give it a small, bounded task and treat every inline suggestion as untrusted draft text. Read the intended behavior, accept only the lines you understand, reject or dismiss the rest, check repository rules and public-code references, run the required tests and scans, inspect the final diff, and obtain human code review.

This is a coding-specific application of the broader How to Use AI method. It covers the moment a Copilot suggestion appears and the gates before it becomes part of your change. It does not replace the broader review of AI-generated code before first execution, which also examines dependencies, permissions, external side effects, migrations, production configuration, and rollback.

Key Takeaways

Use Copilot for one small task with explicit boundaries.

Never accept code that you cannot explain line by line.

Accept a useful part and reject the rest when the editor supports it.

Treat public-code references as investigation leads, not clearance.

Run the repository's tests, lint, security, and IP gates.

Review the complete diff because unsafe changes may sit outside the visible suggestion.

Which tasks let you use GitHub Copilot without accepting unsafe code?

Choose a task with a narrow contract and a fast, reliable way to verify it: completing a pure function, adding a test case, transforming a known data structure, writing repetitive serialization code, or adapting code to an established local pattern. Define the input, expected output, failure behavior, and files that may change.

Avoid starting with authentication, authorization, cryptography, dependency changes, migrations, CI/CD, production configuration, secret handling, destructive operations, or sensitive data. These are not forbidden merely because AI is involved, but they require the full review path before execution and approval by the appropriate owners.

Write a task boundary in a comment or private note:

Task: add parsing for one documented enum value.
Allowed files: parser and its unit test.
Required behavior: unknown values return the existing typed error.
Forbidden: new dependency, network access, logging payloads, fallback success.
Verification: targeted unit test, full parser tests, lint, final diff review.

Delete temporary prompt comments that should not remain in production code. Never put secrets, tokens, private customer data, or confidential vulnerability details in a prompt or source comment merely to improve a suggestion.

What context should you give GitHub Copilot?

Provide the minimum safe context needed to follow the local contract: nearby types, a relevant interface, the expected error pattern, a representative test, and the repository's naming or style rule. Too little context encourages invention; too much may expose data and distract from the task.

GitHub's best-practices guidance recommends giving useful context, keeping prompts clear, validating output, and using Copilot as an aid rather than a replacement for expertise.［2］ Context improves relevance, but it does not make a suggestion correct or safe.

Before evaluating a completion, answer:

What behavior is this code meant to add or preserve?
Which trust boundary does the input cross?
What should happen on invalid, missing, empty, or oversized input?
Does the repository fail closed or fall back?
Which side effects are allowed?
Which tests and static checks constitute the local gate?

If those answers are unknown, investigate the repository before accepting code. Do not ask Copilot to invent the contract from a function name.

How do you inspect a Copilot inline suggestion?

GitHub documents controls for accepting an entire inline suggestion, accepting part of it, or dismissing it.［1］ The exact shortcuts and interfaces may vary by editor, so use the current documentation and visible controls.

Read the suggestion before pressing accept. Trace every condition, branch, return value, mutation, allocation, error, and external call. Compare it with the task boundary. Ask what happens at zero, maximum size, malformed input, duplicate calls, partial failure, cancellation, concurrency, and retry—only where those cases apply to the component.

Check for patterns that look convenient but weaken safety:

swallowing an error and returning a default success;
broad exception handling that hides the original cause;
logging secrets, tokens, personal data, or full payloads;
string-built SQL, shell commands, paths, URLs, or templates without the required validation;
disabled certificate, hostname, signature, permission, or authorization checks;
insecure randomness, home-grown cryptography, or predictable identifiers;
an unbounded loop, allocation, recursion, query, or retry;
a new network, filesystem, process, or database side effect;
a dependency or API that is absent from the lockfile or repository conventions.

Understanding the prose explanation is not enough. Copilot's explanation comes from the same assistance channel and is not independent verification.

When should you accept only part of a suggestion?

Use partial acceptance when one contiguous piece clearly matches the contract and the remainder is unnecessary, speculative, or unsafe. For example, keep a correctly shaped match arm but reject an invented fallback; keep a test's arrange section but write the security assertion yourself.

After partial acceptance, reread the resulting code. A fragment that was valid inside the proposal may be incomplete after surrounding lines are rejected. Check imports, variables, branch coverage, resource cleanup, and error propagation.

Dismiss or reject the entire suggestion when:

you cannot explain it without asking the tool what it did;
it changes more files or responsibilities than the task allows;
it introduces a new dependency or side effect without review;
it contradicts a repository rule or approved pattern;
it weakens a validation or security boundary;
a smaller manual change is clearer and easier to verify.

Rejection is normal. It keeps unsupported code out of the diff and gives you a clean point to restate the task.

How should you check Copilot public-code references and licenses?

GitHub describes code referencing as a feature that may show matches between a suggestion and public code, with repository and license information where available.［3］ Treat a reference as a lead for provenance and license review. Open the referenced material, confirm the actual license and context, evaluate compatibility with the project, and follow your organization's attribution and legal process.

A missing reference does not prove that code has no source or license risk. Matching systems have thresholds and coverage limits, and short or common patterns may not be distinctive. Also inspect unusual comments, identifiers, algorithms, headers, or long blocks that resemble external material.

Record the disposition:

no reference shown; normal review still required;
reference shown and suggestion rejected;
reference investigated and use approved under the project's process;
reference unresolved and change blocked;
code rewritten independently and re-reviewed, if policy permits.

Do not remove attribution or obscure provenance to make a match disappear.

Which repository gates should run?

Start with the narrowest test that proves the intended behavior, then run the repository-prescribed broader checks. These may include formatting, lint, type checking, unit and integration tests, dependency review, secret scanning, code scanning, license or IP scanning, and policy-specific scripts.

NIST's Secure Software Development Framework organizes secure development practices around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities.［4］ Copilot does not change those responsibilities. Generated lines enter the same development lifecycle as handwritten lines.

Tests should cover the contract and meaningful failure modes, not merely execute the happy path. Review any tests Copilot proposes: a generated assertion may encode the implementation's mistake, mock away the risk, or omit the negative case. The AI-assisted test-generation workflow can help expand cases, but the reviewer chooses the oracle.

If a required gate cannot run, record the gap and do not describe the change as verified. A green local unit test is not equivalent to the full repository gate, CI, platform-specific testing, or production validation.

How do you review the final diff?

Inspect the complete effective diff, not only highlighted Copilot text. Acceptance can trigger imports, formatting, nearby edits, generated files, lockfile changes, or manual follow-up. Confirm that the diff contains only the intended files and behavior.

Review in this order:

restate the task and expected security properties;
inspect changed interfaces, data flow, and side effects;
check error and cleanup paths;
compare with repository rules and nearby approved patterns;
inspect tests and their ability to fail for the right reason;
verify scan and test results with commands and exit status;
remove temporary prompts, debug logs, placeholders, and unused code;
obtain code review from a person with the needed domain authority.

Use a suggestion record for material completions:

Suggestion ID	Task	Affected lines/files	Understood behavior	Public-code reference	License action	Tests	Security checks	Decision	Reviewer
C-01	Parse enum value	Parser + test	Known values map; unknown fails closed	None shown / reference	Investigated / N/A	Commands and result	Scan and result	Accept / reject / revise	Name

The record should point to evidence, not copy a model's self-assessment.

When must you escalate to a full review?

Escalate authentication, authorization, cryptography, dependencies, migrations, CI/CD, production configuration, secrets, personal or regulated data, destructive operations, and externally visible protocol changes. Also escalate when the suggestion crosses trust boundaries, changes persistence, weakens a default, or cannot be safely tested in the local environment.

The full pre-execution review for AI-generated code checks dependencies, permissions, network and filesystem effects, migrations, rollback, and operational consequences before running the patch. The inline acceptance process here is one input to that larger gate, not a substitute.

What common mistakes should you avoid?

Accepting a large suggestion because the first lines look correct.
Asking Copilot to explain code and treating that explanation as verification.
Keeping a useful fragment without checking whether partial acceptance broke context.
Assuming no public-code reference means no license risk.［3］
Trusting generated tests that repeat the same incorrect assumption.
Running only the happy-path test or ignoring a failed required gate.
Hiding scope growth inside formatting, imports, dependencies, or configuration.
Batch-accepting suggestions in sensitive code.

Summary

Give Copilot a small task and minimum safe context.
Read, partially accept, reject, or dismiss suggestions deliberately.
Investigate public-code references without treating absence as clearance.
Run the repository's required tests, scans, and policy gates.
Inspect the complete diff and require qualified human review.

FAQ

Is it safe to accept a Copilot suggestion if it compiles?

No. Compilation does not prove correct authorization, validation, error handling, concurrency, licensing, security, or operational behavior.

Can I accept only part of an inline suggestion?

GitHub documents partial acceptance in supported editor experiences. Reread the resulting code because rejecting surrounding lines can make the accepted fragment incomplete.

Should I reject a suggestion I do not understand?

Yes. Reject it, investigate the local contract, and either make a smaller request or write a simpler change you can verify.

Does no public-code reference mean the suggestion is original?

No. The absence of a displayed match is not proof of provenance. Continue normal license, attribution, and code review.

Can Copilot verify its own code?

No. Its explanations and generated tests may repeat the same error. Use independent specifications, repository tests, scanners, evidence, and human review.

Which suggestions need extra review?

Anything involving authentication, cryptography, dependencies, migrations, CI/CD, production configuration, secrets, sensitive data, destructive effects, or trust boundaries needs the full review path.

What if a required test or scanner is unavailable?

Record the unverified gate and do not claim the change is safe or complete. Route it to the environment or reviewer that can perform the missing validation.

Who makes the final acceptance decision?

The developer and authorized reviewer responsible for the repository and affected domain. Copilot provides a suggestion, not approval. AethoVPN may be part of a developer's network setup, but it cannot review Copilot suggestions for insecure code or approve a repository change.

Sources

Sources checked 31 August 2026.

GitHub Docs, “Responsible use of GitHub Copilot inline suggestions” — https://docs.github.com/en/copilot/responsible-use/inline-suggestions
GitHub Docs, “Best practices for using GitHub Copilot” — https://docs.github.com/en/enterprise-cloud@latest/copilot/get-started/best-practices
GitHub Docs, “Code referencing in GitHub Copilot” — https://docs.github.com/en/copilot/concepts/completions/code-referencing
NIST, “Secure Software Development Framework” — https://csrc.nist.gov/projects/ssdf

How to Use GitHub Copilot Without Accepting Unsafe Code