An agent edits the two files you allowed and reports "all requirements satisfied, all tests pass." The diff also adds a dependency and disables an authorization setting so a test can pass. The summary sounds complete. The work crossed two boundaries you never approved.
Output is a proposal, not proof
Treat a generated response as a candidate. Its confidence doesn't prove the code's behavior, and a generated test may repeat the implementation's own mistake. A passing test covers only the cases it ran. An agent's completion report also can't prove that every action stayed in scope. Before you rely on an important claim, place it in one of four groups:
- Established: directly supported by the requirement, the code, or the docs. Cite the source and continue.
- Testable: checkable with an executable test or probe. Run it and record the result.
- Unestablished: depends on information that isn't present. Find the missing source or log the open decision.
- Suspicious: conflicts with the evidence or creates a plausible correctness or safety risk. Stop and investigate.
Apply the labels claim by claim. One response can contain all four. Increase the depth of review with the amount of autonomy involved. Read an inline suggestion beside its function. For a chat edit, inspect the full diff and run focused tests. Give an agent explicit allowed files, prohibited actions, commands, and stop conditions. Automation doesn't grant approval. The ability to edit a repository is separate from permission to approve, merge, or deploy a change.
The six responsible AI principles, applied
Microsoft's responsible AI principles give you a review checklist that's more than a slogan: fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. They overlap, but each asks a different question. A test that satisfies one does not satisfy the others.
Take an authorization function that decides whether a user may download a document, where the rule is same-tenant ownership (with administrators limited to their own tenant). A same-tenant owner test supports reliability. It says nothing about privacy across tenants (whether a user in another tenant could reach the document), nor about transparency of your review, nor about accountability for who approved the change. Each principle demands its own evidence: reliability wants the cross-tenant and boundary tests executed. Privacy wants a data-flow and endpoint check. Transparency wants the diff, commands, and known limitations recorded. Accountability wants a named human who decides accept, revise, or reject.
Content exclusion and public-code filtering
These safeguards are often grouped under privacy, but they address different concerns. A content exclusion identifies a file or repository to exclude from a supported Copilot configuration. Public-code filtering deals with suggestions that match public code. If the concern names one of your files or repositories, investigate content exclusion. If the suggestion resembles public code, inspect the public-code filtering setting. Troubleshoot any saved control that behaves differently from what you expected.
Be careful about what a setting proves. Seeing a saved exclusion entry after you reopen the configuration tells you that you observed a saved configuration. Whether content is unavailable across every Copilot surface, or anything about retention or telemetry, stays a separate and unconfirmed question. Likewise, an ordinary prompt that produces no sensitive text proves only that the response followed your source constraint. It does not prove that exclusion or public-code filtering operated. Keep those as separate conclusions. The exact menus and labels for these controls change between editor releases, so don't memorize a click path. Follow GitHub's current content-exclusion guide, and for the ownership and data-handling terms of Copilot output, check GitHub's official documentation rather than any course summary.
Plans, credits, and models
Keep three concepts separate. A plan is the entitlement that controls which features and models you can use. An allowance is the included AI-credit usage. Consumption is the usage recorded by a particular model-based session. The subscription price doesn't estimate the cost of one session, and a larger allowance doesn't change that. The July-2026 plan map, as of mid-2026:
One rule saves a lot of confusion: code completions and next-edit suggestions are not billed in AI Credits. They stay unlimited on paid plans, and Free has its own separate completion limit. Don't subtract accepted autocompletions from your credit allowance. Keep completion activity separate from model-based work like chat prompts and agent sessions.
On models, as of mid-2026 three are named: Luna (lightweight and fast), Terra (balanced, everyday coding), and Sol (highest reasoning ceiling for complex work). Luna and Terra appear on the paid individual and organization plans. Sol is available from Pro+ upward. Copilot Free uses automatic selection rather than a direct picker. Keep automatic selection when your plan or surface doesn't expose a picker. Start with the smallest available model that can do the job, then escalate if the task fails your acceptance criteria. Never claim you selected a model your plan doesn't expose.
The GH-300 path
If you want the credential, GH-300 tests whether you can operate Copilot responsibly, not just name its features. You have to explain why a control fits a scenario and how you'd validate the result. The exam spans six weighted domains: using Copilot responsibly, using its features (the largest slice), understanding its data and architecture, prompt engineering and context crafting, improving developer productivity, and configuring privacy and safeguards. Every lesson in this module has fed one or more of those domains.
The logistics, as of mid-2026: the exam runs 100 minutes, costs $99 USD, is delivered through Pearson VUE, and the certificate is valid for 24 months. The passing score is 700 out of 1,000.
Build a readiness packet with an artifact for each objective. That might be a prompt beside its reviewed diff, a data-flow trace, an exclusion-versus-filtering decision, or a passing test paired with the original failing reproduction. Take the official practice assessment cold and mark each answer as certain, uncertain, or a guess. Revisit every missed or shaky concept with a fresh scenario before trying again. Exam objectives can change, so read the current study guide once more before you register. For more practice with the prompt-engineering domain, return to Prompting 101.
