Execution Context and Repo Scope
An agent's behaviour depends on *where* it runs as much as on *what* it can call. Learn to distinguish workspace, branch, session and tenant scopes — and how to keep secrets, files and side-effects in their correct layer.
Execution Context and Repo Scope
When an agent calls a tool, four envelopes are active at once: the workspace it can see on disk, the repo its credentials can affect, the session that holds scratch state, and the tenant that ultimately pays for and governs everything. Most agent incidents are an item that escaped its envelope.
The four scopes in one picture
| Scope | What lives here | Lifecycle | Typical control |
| --- | --- | --- | --- |
| Workspace | Local files inside the configured roots | Project-long | MCP roots, filesystem allow list |
| Repo | Branches, PRs, issues, actions on GitHub | Permanent until deleted | PAT scopes, branch protections, CODEOWNERS |
| Session | Scratch outputs, partial plans, in-memory tool state | One run | Ephemeral tmp dirs, in-memory caches with TTLs |
| Tenant | Org-level config, audit logs, policy decisions | Long-lived | Enterprise admin policies, SSO |
Sort items into their scope
If you can sort artefacts into the right scope by reflex, you can spot scope leaks in the wild.
Sort by memory layer
Drag each artefact into the scope where it should live (and where it should be destroyed).
If you can't articulate which scope an artefact lives in, you can't articulate when it should be destroyed — and undeletable scratch state is how secrets escape.
Where this shows up on the exam
GH-600 likes scope-leak scenarios: "the agent accessed file X from another project" or "credentials from yesterday's session appeared in today's PR." Trace the artefact back to the scope it should have lived in, then name the control that would have kept it there.
Key terms
- Execution context
- The runtime envelope in which a tool call executes: which working directory, which branch, which credentials and which network policy apply.
- Workspace scope
- Files the agent is allowed to read or write on the local machine — typically a single repository checkout under a `roots` constraint.
- Repo scope
- The GitHub repository (or subset of repositories) the agent's tokens and toolsets can affect.
- Session scope
- State that lives only for the current conversation/run: scratch files, in-memory variables, ephemeral branches.
Common pitfalls
- Letting the agent run with a `roots` permission of `/` (the whole disk) when it only needs `~/workspace/projectX` — one bad path traversal and you have just exfiltrated the user's home directory.
- Storing per-session scratch files in a permanent location so future runs and other users can read them.
- Using a token that spans multiple repositories when the task is single-repo; a prompt-injection in repo A now writes to repo B.