A senior engineer opens an unfamiliar repo to review a PR.
The coding agent wakes up and does what it was built to do. It reads the repo, pulls project settings, spins up tool connectors, summarizes the diff, suggests fixes, runs tests, and opens a PR. Everything looks clean. CI is green.
Then you notice the part nobody reviewed.
A repo-level config file enabled a new hook. A repo-defined tool connector appeared. An environment variable changed where tokens get sent. Nothing in the application code changed, but the agent runtime did.
The code shipped. The runtime changed.
In a previous post I wrote about governed runtimes and why agents in CI force governance to become architecture. This is the narrower companion.
When an agent can be configured by repo files, the repository becomes a supply chain for agent behavior.
The blind spot specific to repo config
Teams have learned to fear two surfaces.
Application code, because it changes product behavior.
CI configuration, because it changes what runs with privileges.
Agent configuration often slips through both filters.
It gets treated like documentation. It is merged without a second glance. It is rarely protected by CODEOWNERS or branch rules. It is not part of threat models.
That is a legacy posture. It worked when dev tools were mostly stateless and passive.
It breaks once repos can define how an agent executes work.
Governance as runtime, applied to repos
Governance is not a policy document. It is the shape of your execution boundaries.
A repo-safe agent runtime has four properties.
1) Project settings are executable policy
The simplest form is a tool-specific config file that lives inside the repository.
Claude Code, for example, supports project-level configuration through a .claude/settings.json file that lives directly in the repository.
Check Point Research used that project configuration surface to demonstrate a broader class of risk. Their executive summary states they discovered vulnerabilities that:
"allow attackers to achieve remote code execution and steal API credentials through malicious project configurations"
They also state:
"All reported issues have been successfully patched prior to this publication."
Even when a specific vulnerability is patched, the architecture lesson persists.
If project files can change agent behavior, project files are part of your security boundary.
2) Tool connectors create new data paths
MCP is a protocol on paper. In production, it is a connector surface.
A repo-defined file like .mcp.json is not an innocuous settings file. It can define which tools exist, and in turn which data paths exist.
A CODEOWNERS file for agent policy surfaces often looks like this:
# Agent policy surfaces
/.mcp.json @platform-security @devex
/.claude/** @platform-security @devexThe specific paths vary by tool. The principle does not.
If a repo can expand tool access without explicit review, you have created a supply chain surface that lives outside your dependency scanners.
3) Hooks turn assistance into execution
Hooks are where the safety boundary usually fails.
A hook that runs at a lifecycle boundary can turn a helpful agent into an execution engine. It can also trigger behavior that is invisible in application code review.
This is why the Check Point report calling out hooks, MCP servers, and environment variables matters. It is not about one tool. It is about how agent tooling is assembled.
Configuration that can execute must be governed like infrastructure.
4) Environment variables are a policy plane
Environment variables are the quietest control plane in most systems.
They can redirect endpoints, change auth flows, and alter tool behavior without touching application code. In agentic tooling, env vars also show up in risk models because they are one of the simplest ways to steer execution.
The takeaway is simple.
If an environment variable can change where tokens go, who tools talk to, or what an agent can access, it deserves review.
State is entering the repo
The repo becomes a supply chain not only for config, but also for state.
GitHub's Copilot Memory changelog states:
"Copilot Memory is now enabled by default for all GitHub Copilot Pro and Copilot Pro+ users."
and:
"To keep things fresh, memories automatically expire after 28 days."
The point is not that memory is unsafe. The point is that repo-shaped state is becoming normal.
Once state persists across sessions, config is no longer the only thing that can change agent behavior.
What changes in how you should review repos
If agent tooling is configured by repo files, you should review those files the way you review CI and IaC.
Not because they are special.
Because they change what runs.
In practice, that means:
- treat agent policy files as protected paths
- require CODEOWNERS review
- constrain tool connectors behind an org allowlist, so repo config becomes a request rather than an authority
- maintain an evidence plane, so actions are attributable and reconstructable
A CI lint job for agent policy diffs can be as simple as detecting that agent policy files changed and turning on a review gate. The exact mechanism varies by org, but the architectural intent is consistent.
name: agent-policy-gate
on: [pull_request]
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Detect agent policy changes
run: |
changed=$(git diff --name-only origin/${{ github.base_ref }}...HEAD)
echo "$changed" | grep -E '^(\.mcp\.json|\.claude/)' || exit 0
echo "Agent policy files changed. Require CODEOWNERS review and tool allowlist check."Also, treat trust as explicit. Opening an untrusted repo should default the agent to read-only with tools denied until a repo is marked trusted.
repo_url=$(git remote get-url origin 2>/dev/null || echo "")
trust_file="$HOME/.agent/trusted-repos.txt"
if ! grep -Fqx "$repo_url" "$trust_file" 2>/dev/null; then
export AGENT_READ_ONLY=1
export AGENT_TOOLS=deny
echo "Untrusted repo. Running agent read-only with tools denied."
echo "To trust: add the repo URL to $trust_file after review."
fiThese are not recipes. They are examples of a design decision.
The agent should not be able to expand its own privileges through repo configuration.
What this does not solve
This posture does not make agents correct.
It does not prevent every prompt injection. It does not remove the need for human accountability. It does not eliminate the risk of social engineering.
What it does is reduce the number of silent failures.
It makes the policy surface reviewable, and it makes privilege expansion hard to do accidentally.
The most dangerous file in your repo is not the code. It is the config your agent executes without review.