Lesson 2: Ethical AI Use, Potential Harms and Mitigations

Why ethics belongs on a developer exam

Level 1 covered what can go wrong with generative AI: it gets things wrong while sounding sure of itself, it repeats patterns from its training data, and it knows nothing about your business rules. This level covers what you do about those risks. GH-300 frames the answer with Microsoft and GitHub's six principles of responsible AI. You'll see the principles by name, so learn them word for word:

Think of Copilot as a fast, well-read junior developer who never says "I'm not sure." You wouldn't merge a junior's pull request without reviewing it, and the same goes for Copilot's suggestions. Each principle below comes with a harm you'll actually run into and a mitigation you can use straight away.

Harm 1: Bias → diverse test data and human review

You type a comment and accept the suggestion:

# validate a customer's full name
import re

def is_valid_name(name: str) -> bool:
    # Copilot suggestion: looks tidy, but only allows A-Z letters and spaces
    return bool(re.fullmatch(r"[A-Za-z ]+", name))

This rejects Zoë, O'Brien, José and Nguyễn. Nothing crashes, but you've quietly shut out real customers. That breaks fairness and inclusiveness. The model picked up a common pattern from its training data, and common is not the same as correct.

Mitigation: write tests that cover a wide range of inputs, and review with your actual users in mind.

import pytest

# Names from different languages and cultures. All of them must pass.
@pytest.mark.parametrize("name", ["Zoë Smith", "Seán O'Brien", "José Álvarez", "Nguyễn Văn An", "Anne-Marie Lee"])
def test_accepts_international_names(name):
    assert is_valid_name(name)

Run it. When it fails, you've caught the bias before your customers do.

Harm 2: Insecure code → security scanning and safe patterns

// Copilot suggestion: works in the demo...
app.get("/user", async (req, res) => {
  const rows = await db.query(`SELECT * FROM users WHERE id = '${req.query.id}'`); // SQL injection!
  res.json(rows);
});

// ...the reviewed version: a parameterised query, where the driver escapes the input
app.get("/user", async (req, res) => {
  const rows = await db.query("SELECT * FROM users WHERE id = $1", [req.query.id]);
  res.json(rows);
});

Plenty of public code builds SQL by string concatenation, so the model will suggest it too. This is a reliability and safety and privacy and security harm.

Mitigation: human review that includes a security checklist, plus automated security scanning (static analysis such as code scanning, and secret scanning) in CI, so a tired reviewer isn't your only defence.

Harm 3: Privacy exposure → least-privilege data access

Copilot builds its prompt from the code around your cursor, which can include other open files. If config/secrets.json or a folder of customer data is part of that context, it can end up in the prompt.

Mitigation: give the AI access only to what it needs. On GitHub.com, a repository admin sets content exclusion under Settings → Copilot → Content exclusion, listing paths in the "Paths to exclude in this repository" box:

# Ignore one specific file in this repository
- "/config/secrets.json"
# Ignore every file whose name starts with "secret", anywhere
- "secret*"
# Ignore everything in or below /customer-data
- "/customer-data/**"

Gotcha: GitHub's docs say Copilot CLI and Agent mode in Copilot Chat in IDEs do not support content exclusion, and changes can take up to 30 minutes to reach IDEs. Exclusion lowers the risk; it doesn't replace keeping secrets out of the repository altogether. A later level covers exclusions in depth.

Harm 4: Over-reliance → keep the human in the loop

The quietest harm is losing your own skills. You start tabbing through suggestions without reading them, and juniors stop learning why the code works. That undermines accountability: you can't own code you don't understand.

Mitigations:

• Read every suggestion before accepting it. If you can't explain a line, don't merge it.
• Write the test (or at least the assertions) yourself, so you set the requirement and Copilot doesn't get to define "correct".
• In pull request review, expect the author to explain AI-assisted code just like any other code.

Harm 5: Matching public code → the public code filter

Now and then a suggestion closely matches code in a public repository, which may carry a licence. Copilot's settings let you block suggestions matching public code. If you allow them instead, code referencing shows you the match, the repositories it appears in and any licence detected. This mitigation is for licensing and IP risk. It does nothing about bias or over-reliance, which is a classic exam distractor.

Transparency and accountability in practice

• Transparency: be open about where AI helped (for example, a line in the PR description), and be honest about what the tool can't do.
• Accountability: Copilot isn't a team member who can be held responsible. The developer who accepts the code and the team that merges it are accountable for it.

Quick reference: harm → mitigation

What the exam asks about this

Expect short scenarios: "A suggestion does X. Which principle is at stake?" or "Which mitigation best fits?" The trick is to pick the mitigation that targets that harm. Tests and review for correctness and bias, scanning for security, exclusion for privacy, the public code filter for licensing. Also learn the six principle names exactly as Microsoft writes them.

Key takeaways

• The six principles are fairness, reliability and safety, privacy and security, inclusiveness, transparency, accountability.
• Every harm has a matching mitigation. Match them precisely, not loosely.
• Content exclusion limits what Copilot can read, but it doesn't cover Copilot CLI or agent mode.
• The public code filter deals with licensing risk, not bias or security.
• People, not Copilot, are accountable for the code they accept.