Story
Building-a-house world — same site and crew as every Phase 0 lesson.
Picture the construction site gate. Two things live there: a sign-in book and a CCTV camera.
Every time anyone walks through — a human worker, the foreman, the inspector, even the robot worker — they sign the book. Name. Time. Which part of the site they headed to. What they did when they got there. The camera records it all silently.
Nobody reads it during a normal day. But the moment something goes wrong — a wall moved without approval, a room locked that shouldn't be — you pull out the book and the footage. The answer is always there: who did this, and when, and which room?
That sign-in book + CCTV is GitHub's audit log.
Lesson 0.2's build diary records what changed in the plans — commits, code edits, design decisions. This gate log records who walked through the site and what they touched — every action across the whole organization, not just plan changes. Different objects, different jobs.
The idea
The audit log "allows organization admins to quickly review the actions performed by members of your organization."
Every entry tells you four things. You can search and filter using a qualifier for each:
The four qualifiers
| Field | What it captures | Search qualifier |
|---|---|---|
| Who | "The user (actor) who performed the action" — a person or an agent | actor: |
| What | "The action that was performed" — e.g. repo.create, team.add_member |
action: |
| Where | Which repository the action happened in | repo: |
| When | "The date and time the action occurred" — ISO format, supports ranges like >=, .. |
created: |
The actor qualifier "can scope events based on the person or agent
that performed the action." That one sentence is the whole point: agent actions land in
the same ledger as human ones. You can tell them apart — and you can prove it.
source: docs.github.com — Reviewing the audit log · fetched 2026-05-28
Concrete query — what it looks like in practice
Say you want to see everything the Copilot agent did in your org since the start of 2026. You'd type this into the audit log search box:
actor:Copilot created:>=2026-01-01
Add an action: to narrow it further — for example action:repo.create
to see only repositories the agent created:
actor:Copilot action:repo.create created:>=2026-01-01One important limit: "you cannot search for entries using text" — qualifiers only, no free-text search.
source: docs.github.com — Reviewing the audit log · fetched 2026-05-28
Retention + export
- Retention: "The audit log contains data for the last 180 days." After that, entries roll off — export before they're gone if you need them longer.
- Export: "You can export the log as JSON data or a comma-separated value (CSV) file" — useful for compliance reviews, incident investigations, or piping into another security tool.
source: docs.github.com — Reviewing the audit log · fetched 2026-05-28
Why this matters for GH-600
Audit log → Exam: MED · Day-to-day: MED.
The audit log is traceability — the second half of accountability. Here's the split between it and lesson 0.9:
| Tool | Job | When it acts |
|---|---|---|
| Branch protection + rulesets (0.9) | Prevents bad changes from merging | Before anything lands |
| Audit log (this lesson) | Records every action so you can trace it | After the fact |
Prevention and traceability together = the two halves of accountability. Neither replaces the other.
When an AI agent acts in your org, the audit log is how you answer:
- Did a human or the agent make this change? → filter
actor:to the agent's identity - What did the agent touch this month? →
actor:Copilot created:>=2026-01-01 - Can I prove to my security team nothing else changed? → export JSON or CSV
The GH-600 exam cares about this pattern: agents don't act invisibly. Their actions are attributed in the audit log exactly like a human's — and you have the tools to find them.
Check-in — three quick questions
Open-ended. Think first, then peek at the suggested answer.
-
You're an org admin. A repo was deleted overnight and you don't know who did it. Walk me through how you'd use the audit log to find out — including how you'd tell whether it was the AI agent or a human.
Suggested answer
Open the audit log and filter by
action:repo.deleteplus acreated:range covering last night. Look at theactorfield on the matching entry — it'll show the GitHub username of whoever (or whatever) deleted it. If it shows the Copilot agent's name, it was the agent; if it's a team member's handle, it was a human. You could also runactor:Copilot action:repo.deleteto see all agent-driven deletions at once. -
What's the difference between the audit log (0.10) and the build diary / commits (0.2)? Give me one example of something that shows up in the audit log but NOT in commits.
Suggested answer
Commits record changes to code and files — what was built. The audit log records organizational actions — who added a user to a team, who changed a repo setting, who created or deleted a repository. Example of something in the audit log but not in commits: an admin removing a team member (
team.remove_member). That's a settings change, not a file change — it never touches the codebase, so it doesn't appear in git history. -
Branch protection (0.9) and the audit log (0.10) both exist in the same org. How are they different tools? Could you have real accountability with only one of them?
Suggested answer
Branch protection acts before a change lands — it blocks a merge until rules are met. The audit log acts after — it records what happened so you can trace it. You need both: protection alone doesn't help if something slips through or happens outside a PR (like a repo setting change). The audit log alone doesn't prevent anything — it just tells you what went wrong after the fact. Prevention + traceability = full accountability.
Mentor marks this lesson verified after you compare answers and say "got it" in chat.
Ticks this lesson done on the home roadmap. Saved in this browser.
Sources: docs.github.com — Reviewing the audit log for your organization · fetched 2026-05-28.