Feb. 18 Log
Share free access to this member-only story with a friend: Read it free here.
GitHub tucked the warning into the agent session log instead of the pull request diff. A reviewer can be staring at the changed file, green checks, and a ready merge button while the important clue sits one tab away. Treat that log like wallpaper, and a public-code match can ride into the branch before anyone has dealt with the license.
That is the sharp edge in GitHub's Feb. 18, 2026 Copilot changelog. Copilot's cloud agent can flag matches to public code in its session logs, including a link to the source and license context, but the same notice says the public-code matching policy's block setting does not block those agent suggestions.
The agent generates the code first; the warning comes afterward.
For senior engineers deciding how far Copilot, Codex, Claude, or Gemini should reach into real repositories, the risk did not disappear when assistants became agents. It moved into provenance logs and permission gates, exactly where teams skim under pressure.
The code match is the new warning light
The old safety story was simple enough for a hallway conversation: autocomplete makes a suggestion, a developer accepts it, and a policy blocks risky matches. Clean. Contained.
Nice little myth with a tidy desk and a fresh coffee.
The cloud-agent version is messier. The object is no longer just a suggestion. It is a session log, a draft pull request, and a branch with code already written.
GitHub's own docs say Copilot code referencing checks suggestions against publicly available code and, for cloud agent output, shows matching code inside the agent session logs. The reviewer then decides what to do with that context.
Here's the practical sting. The match is not the verdict. It is evidence.
A highlighted public-source match can mean harmless boilerplate, a license issue, or a copy that needs replacement. The log will not stand in the review meeting and argue for you. Someone still has to read it.
GitHub adds one important number in its code-referencing docs: matches to public code "typically" occur in less than one percent of Copilot suggestions. That low rate helps explain why teams skip the log. Most days it's empty.
Then one day it isn't, and the empty habit becomes expensive.
The log isn't decoration. It's where liability waits.
March made the paper trail harder to ignore. In a March 20, 2026 changelog, GitHub said Copilot cloud-agent commits include an `Agent-Logs-Url` trailer. The commit is authored by Copilot, the human who assigned the task is marked as co-author, and the trailer links back to the session logs for review or later audit.
That tiny trailer changes the status of the log. It is no longer a nice debugging window for curious engineers. It becomes part of the change record.
If a bad dependency, copied helper, exposed token, or brittle patch shows up three months later, the question is not "Did the model mean well?" The question is "Can we reconstruct what happened?"
Permission moved into the settings file
Now swing the camera over to Google's side of the desk. Google's Gemini Code Assist agent-mode documentation, last updated May 8, 2026, points at the same control shift from another angle.
Gemini Code Assist agent mode can use file search, file reads, file writes, terminal commands, and configured MCP servers. Google documents `coreTools` and `excludeTools` settings for controlling what the agent can touch. It also says all built-in tools are available by default unless the team restricts them.
There's your permission gate, sitting quietly in JSON.
The scary setting has an almost comic name: yolo mode. In VS Code, Google says it automatically allows all agent actions in a trusted workspace. The same doc warns that the agent has access to the machine's file system, terminal actions, and configured tools.
In IntelliJ, auto-approve changes creates the same basic pressure: the agent stops asking before it acts.
That is not a moral panic. It is an architecture note with a siren taped to it.
A coding agent with broad tools has a larger attack surface than a chatbot with a text box. A bad prompt is still a problem, sure. But the nastier path is overbroad access: shell commands that run too freely, MCP servers with tokens, file writes across a repo, and a trusted workspace treated like a padded room when it is really a loading dock.
Google even gives the practical clue teams need. `coreTools` can restrict access to a named list. `excludeTools` can block tools or specific commands, including command-shaped examples such as allowing only a particular shell invocation or excluding a destructive one.
That is not glamour. That is the real control plane.
The reviewer inherits the risk
The incentive problem is brutal because it feels so productive. The person who delegates the task gets speed. The reviewer gets the audit exposure.
The company gets the bill when the wrong thing ships.
Stack Overflow's 2025 Developer Survey gives the mood music behind that pressure. It says 84% of respondents use or plan to use AI tools in their development process, while 46% distrust the accuracy of the output. It also says a majority of developers do not use agents yet, but among those who use agents at work, many report productivity gains.
That is exactly the fork in the road: high speed, low trust, uneven adoption.
Speed attracts teams because delay has a cost. Backlogs grow teeth. A stale security ticket becomes a calendar tax.
A migration that sits for two quarters turns into a system nobody wants to touch. Agents promise to chew through that pile while engineers sleep, review, or fight the next outage.
But the downside lands in a different account. If a human pastes questionable code, the reviewer can ask the human why. If an agent submits a neat patch with a suspicious helper, the reviewer needs the session log, the matched-code reference, the tool list, and the permission story.
Without that chain, review turns into vibes with a green checkmark.
GitHub's risk and mitigation docs show how serious this has become. Copilot cloud agent can push changes, but GitHub says it limits who can trigger it, limits the branch it can push to, applies branch protections, requires human review before merge, and keeps Copilot from approving or merging its own pull requests. The same page says session logs and audit events are available, and that the commit message links back to the agent logs.
Those are good controls. They are also easy to misuse as comfort blankets.
A control nobody checks is a prop. A log nobody reads is a souvenir. The second-order failure is not that agents write bad code forever.
The failure is that teams reward delegation speed while treating provenance review as clerical cleanup.
This is the same approval problem teams already know from CODEOWNERS, rulesets, and merge queues. The shape changed. The incentive did not.
Everyone wants the diff to move. Somebody still has to own the consequence.
Gate the reach before you measure the speed
The first useful move is boring enough to work: separate read access, write access, shell access, and external-tool access before you let agents loose across real repos. Don't ask whether the model is "good enough" in the abstract. Ask what it can do when it is wrong, rushed, or tricked.
A sane policy allows broad reading in low-risk repos, narrows writes to agent branches, gates shell commands by command family, and treats MCP servers like production integrations rather than novelty adapters. Secrets should stay scoped by repo or narrow org policy until a specific owner can explain why the agent needs them. GitHub's May 8, 2026 secrets changelog makes that point sharper: agent secrets and variables can now be managed at organization level and shared across selected repositories.
Useful, yes. Also a bigger blast radius when configured lazily.
Read broadly. Write narrowly. Audit before merge.
The practical review move is just as direct. When an agent-authored pull request arrives, don't start with the prettiest diff. Start with the provenance trail.
Open the session log. Check whether public-code matches appeared. Look at which tools ran.
Confirm whether tests and linters ran inside the agent's environment. If there is an `Agent-Logs-Url`, treat it like part of the commit, because GitHub now does.
Then read the diff with that context in your head. A strange import is less strange after you see the agent searched a stale file. A new helper is more suspicious after you see it resembled public code.
A passing test means less if the shell permissions allowed a narrow test slice and skipped the risky path.
The gate should match the possible harm. Documentation fixes can tolerate lighter review. Dependency changes need advisory checks and a human who understands package risk.
Database migrations, auth code, payment logic, CI changes, deployment scripts, and anything touching secrets should require explicit permission for writes and shell actions. The louder the consequence, the smaller the agent's reach.
This is where the future stops looking like a demo and starts looking like engineering management. Agents will get faster. The interfaces will get smoother.
The agent picker will make Copilot, Claude, Codex, and Gemini feel like a normal menu instead of a strategic choice. That smoothness is useful, and it is dangerous for the same reason: it hides the control surface.
GitHub's Feb. 18 changelog gave teams the clue in miniature. A public-code match can be highlighted instead of blocked.
Google's May 8 docs show the companion clue. An agent can stop asking for permission if the settings allow it. Put those together and the lesson is plain: autonomy scales through records and gates, not hope.
The next agent decision is not "Which model writes fastest?" It is "Which action leaves a record good enough to defend?" Read the log before widening the gate, because the diff moves faster than the liability, and thank you for taking that seriously.