It is tempting to call an agent workflow auditable merely because it happens in GitHub. The issue is there, the commits are there, the pull request is there, and several green checks appear beside the proposed change. That is certainly better than allowing the entire run to disappear inside a private chat session, but it doesn’t yet tell us whether the issue represented accepted intent, whether the checks tested the properties that matter, or whether the person who clicked Merge actually held the relevant authority.
GitHub gives us a useful place to construct a supervised delivery loop; it doesn’t construct the supervision model for us.
This distinction matters at the point I call Phase 1.5 in Phases Are a Roadmap; Maturity Levels Are Capability States: the move from personal AI assistance into a durable, human-supervised engineering workflow. GitHub is one implementation of that bridge, and a particularly practical one, but the architecture should survive a change of vendor.
The control loop before the product
The vendor-neutral loop I want is:
- accepted intent enters a bounded branch or workspace;
- an agent produces a proposed change within an explicit authority envelope;
- independent verification produces evidence against the acceptance conditions;
- an accountable role reviews the change, the evidence and the residual risk;
- a separately governed merge or promotion decision moves the accepted candidate forward; and
- the resulting record remains useful for operational learning.
Every GitHub product-behavior claim from this point onward, including the later security and retention behavior, was reviewed against GitHub’s first-party documentation on July 25, 2026. This is a dated implementation profile, not a permanent definition of supervised agentic engineering.
That sequence can be implemented with GitHub issues, branches, pull requests, checks, reviews, rulesets and deployment environments, although none of those objects creates the next control merely by existing. A pull request supports review; it doesn’t require an approval unless the target branch is configured to require one. A check can report that a test ran successfully; it doesn’t prove that the test covered the business behavior, security property or operational failure mode which justified running it.
And the accountable role need not be the person who typed the change. Separation may be required by the change class, risk or policy, while another bounded change may legitimately keep both responsibilities with one role. The relevant question is whether the named role has the competence and authority to accept the remaining risk, with enough evidence to understand what is being accepted.
A record is not automatically evidence
Issues, commits, reviews and logs are records. They become useful evidence when their provenance, meaning, retention and relationship to the decision are clear, and they become enforcement only when a control actually prevents an unauthorized transition.
| Record | Useful evidence | What it does not prove |
|---|---|---|
| Issue or work item | Accepted intent, scope, owner, constraints and acceptance conditions when those fields are reviewed | That the requested outcome is valuable, complete or still current |
| Commit and diff | Exact proposed code or configuration change, authorship metadata and reviewable history | That the change is correct, complete or safe to release |
| Status check | Which configured process reported a result for a particular commit | That the process tested the right predicate, or that its result came from an appropriately trusted source |
| Pull request review | Who commented, approved or requested changes against the recorded diff | That an approval is required, current after later changes, or sufficient for the affected risk |
| Merge or deployment record | Which transition occurred, when it occurred and which identities were recorded | That the actor held the business or production authority the organization intended |
| Session or workflow log | What the tool reports it attempted, observed and executed during the retained period | That the account is complete, independently verified or retained for the required audit window |
This is why I prefer to treat a pull request as an evidence packet, rather than evidence in the abstract. The packet can connect accepted intent, the exact candidate, validation output, review decisions, exceptions and rollback information, but each connection needs a predicate and an owner. Otherwise we have a very tidy folder containing several unrelated records.
What GitHub can enforce, when it is configured to
GitHub pull request reviews record comments, approvals and requests for changes, while administrators can require approving reviews for protected branches. The distinction is important: a recorded approval and a merge-blocking approval policy are different controls.
Similarly, GitHub status checks show whether configured processes report that a commit met their conditions. They block a merge only when the branch policy requires them, and GitHub’s own documentation notes that people or integrations with write permission may set check state. A serious control therefore needs a trusted source as well as a recognizable check name.
GitHub rulesets can require pull requests, approvals, status checks, code-owner review, resolved conversations, signed commits and successful deployments. They can also define bypass actors, and those exceptions are part of the authority model rather than an administrative footnote.
Production promotion is another boundary again. GitHub deployment environments can restrict branches, require reviewers and withhold environment secrets until the protection rules pass. This is useful machinery for an outer-loop decision, although whether a particular reviewer may accept a particular production risk still comes from the organization’s operating model.
The resulting GitHub-native profile is valuable precisely because the relationships can become inspectable and enforceable. It is not valuable because GitHub has somehow turned a repository into a governance system by default.
One agent product is not the general authority model
Product defaults also differ. As one product profile, GitHub documents that its Copilot cloud agent works on a bounded branch, opens draft pull requests, and cannot approve or merge those pull requests; a person must review and merge them. GitHub also documents that Actions workflows do not run automatically when Copilot pushes changes to its pull request: a user with write access must choose Approve and run workflows, unless the repository is configured to allow automatic execution. These are useful product-specific safety properties, described in GitHub’s cloud-agent risks and mitigations, but they are not universal properties of an LLM-powered coding agent.
For another harness, an agent may be allowed to merge a low-risk documentation change after deterministic checks, while a database migration may require a specialist reviewer and a production deployment may require a separate environment owner. Terraform isn’t inherently forbidden either; it belongs inside or outside the envelope according to identity, blast radius, policy, verification, reversibility and accountable approval.
So the permission question should not be answered with one permanent list of things “the agent may do.” I would rather define it per change class:
- what it may read, change and execute;
- which checks it may invoke but not redefine;
- which transitions are technically blocked;
- which exceptions exist and who owns them;
- where independent review is required; and
- which merge, deployment or production decision remains outside its authority.
The same model applies to a human actor. Agentic engineering makes the missing boundaries more obvious, but it didn’t invent the need for them.
Reviewability is a design property
Small commits often help because they let a reviewer follow the change as it was constructed, isolate unrelated cleanup and detect generated churn. They are not an objective in themselves, however. Twenty artificial commits can obscure a cohesive change more effectively than one carefully structured diff, and a repository which uses squash merges may intentionally preserve review history in the pull request rather than in the final commit graph.
What matters is semantic reviewability: the candidate is bounded, the relationship to intent is legible, generated and hand-written changes can be distinguished, and the reviewer can inspect the relevant evidence without reconstructing the agent’s private session. Production rollback also remains a separate concern; the ability to revert source commits doesn’t necessarily reverse a schema change, external side effect or partially completed rollout.
The record is also a disclosure surface
Once agent session logs, prompts, tool output and validation logs become part of the engineering record, they also become another place where secrets, customer information, internal URLs and security-relevant details may accumulate. GitHub’s secure-use guidance for Actions warns that secret redaction isn’t guaranteed and recommends least-privilege credentials, while GitHub’s cloud-agent risk guidance describes prompt injection through issues and comments. Those inputs must be treated as potentially untrusted rather than harmless documentation.
Retention has to be designed as well. GitHub states that Actions logs and artifacts are retained for 90 days by default, with configurable limits, so an organization which needs a longer-lived decision record cannot merely assume that every linked artifact will still exist during a later incident, audit or model evaluation. Conversely, retaining every prompt and log forever is not a sensible answer when those records contain sensitive material.
The evidence contract therefore needs to say what is retained, for how long, under which access policy, with which redaction or classification, and which durable summary remains after transient logs expire.
What a supervised trial can actually tell us
A Phase 1.5 trial is diagnostic. It can reveal that issues routinely omit acceptance conditions, that checks report activity rather than relevant properties, that reviewers depend on private clarification, or that nobody can name the role which owns a production exception. It can also show that one bounded change class is handled consistently and that the resulting records are useful after the original agent session has gone.
It still doesn’t prove Level 2 capability, because that claim requires repeatable repository readiness for a defined scope, change class, authority boundary and assessment period. One carefully supervised success may tell us where to look; it doesn’t establish the general delegation envelope.
The assessment I want at the end is therefore not “Did the agent produce a green pull request?” but rather:
After the session has disappeared, can we reconstruct the accepted intent, exact change, relevant evidence, accountable owner, exercised authority and any exception—and can the configured controls still prevent the transition we said the agent wasn’t allowed to make?
If the answer is yes, GitHub has become a useful implementation of the supervised loop. If the answer is no, adding another bot to the pull request will mostly give us one more record whose meaning we haven’t defined.