# Before you connect an agent to a private repository

**Rethinking Agents · Review recipe v0.3 · 2026-09-22**

**Status:** unvalidated review resource. The example is synthetic; no integration was configured or tested. This recipe supports [task authority](https://rethinkingagents.com/blog/permission-for-the-wrong-thing) and [sandbox boundaries](https://rethinkingagents.com/blog/what-your-sandbox-contains). It produces an access decision and a list of missing evidence, not a security score.

## The decision

Your coding agent needs to fix a parser in a private repository. Before connecting it, establish which resources it needs, which routes can expose the code, and where you can actually enforce the limits.

Budget 30–45 minutes for an initial document/configuration review; this is a usability target, not a measured completion time. Unresolved implementation work gets its own estimate. Use the [blank record](https://rethinkingagents.com/resources/agent-access-record.md) alongside this worked example. Keep actual internal names and evidence in your own private workspace.

## Worked task: patch a parser, return the patch privately

All names below are fictional labels, not repositories to contact.

- **Task:** correct handling of a quoted delimiter in `parser-lab`, a private repository.
- **Success:** the previously failing quoted-delimiter fixture passes, existing parser fixtures still pass, and the reviewer receives the complete patch and test report privately.
- **Required inputs:** approved checkout, issue reproduction, installed compiler and a prepared dependency cache.
- **Untrusted inputs:** issue prose, repository comments and dependency content. They can describe a bug; they cannot authorize additional access or publication.
- **Excluded:** unrelated repository `internal-plans`, home documents, cloud credentials and external publishing.
- **Delivery:** a local patch plus test report, reviewed within the same private boundary. Remote fetch is separable from editing; no agent push is required for this example.
- **Tool failure:** retain the private draft and stop if the prepared toolchain cannot reproduce the bug. Do not install a new connector, broaden a token or download a new dependency without the task owner's revised decision. Inspect enforcement separately; the instruction itself is not a control.
- **Known limitation:** a hosted agent necessarily transmits context to its model service. Decide whether that recipient may receive this repository before launch. Blocking arbitrary outbound tools does not answer that policy question.

This example assumes the approved checkout and dependencies can be prepared without exposing a general credential to the run. If the actual client requires a live integration throughout the task, record that difference and review its grant explicitly.

## 1. List every route, not just the integration toggle

Draw the effective authority map using these labels. This text map is intentionally readable without a diagram renderer.

```text
Authorized task owner -> approved checkout and fixed task scope
Issue / code / dependency text -> agent context (untrusted task evidence)
Private checkout -> model service (separate authorized data recipient)
Agent -> shell -> checkout + compiler + prepared dependency cache
Agent -> built-in file tools -> separately reviewed file permissions
Agent -> connector / Git / credential helper -> service permissions, if enabled
Agent -> private patch + test report -> human review -> separate release decision
```

For each arrow, identify the process or service that could reject the operation. “The agent was told not to” is a requested policy, not an enforcing component. Include alternate connectors, subprocesses, mounted paths, credentials inherited through environment, previous context and upload/logging paths. Record credential references and scopes, never credential values.

**Evidence states:** requested = intended rule; documented = a source describes it; configured = inspected settings indicate it; observed = a particular operation produced a recorded result; unknown = evidence missing. States may coexist. A configured denial is not an observed denial, and one denied request is not proof that every route is closed.

## 2. Fill the boundary table

This is a completed **design review**, with implementation evidence deliberately unresolved.

| Resource / operation | Needed? | Proposed allowance and enforcing layer | Evidence now | Next evidence / decision |
|---|---|---|---|---|
| Read private checkout | Yes | Prepared checkout available to shell and file tools | Requested; implementation unknown | Inspect actual mounts/tool scopes; confirm model recipient is approved |
| Read issue reproduction | Yes | Supply issue as task evidence; task owner controls scope changes | Requested | Confirm no issue text can select a broader credential grant |
| Read `internal-plans` | No | Exclude checkout and service grant; check alternate routes | Requested | Inspect connector grant, Git helper, other tools and preloaded context |
| Read compiler/cache | Yes | Explicit read access to required toolchain paths | Requested | Identify paths from the real environment before prescribing rules |
| Write checkout/scratch | Yes | Filesystem policy covers both shell and file-tool paths | Requested | Resolve effective write settings and exceptions separately |
| Fetch dependencies | No during this prepared example | Use prepared cache; no registry credentials in run | Requested | If cache insufficient, defer run and review exact new dependency need |
| Call remote GitHub API | No during local editing | No connector/token needed in this task design | Requested | Determine whether the actual agent client can operate this way |
| Send patch/log externally | No | Private output directory; no agent publication route | Requested | Check tools, integrations, logs and model-service data path |
| Publish final change | Separate decision | Authorized person controls full artifact and destination | Requested | Identify complete transfer, including metadata/history, before release |

**Credential variant:** if a live connector is necessary, inspect its actual authentication mode and repository/operation grants. GitHub documents repository restrictions for fine-grained personal tokens, while retaining public-repository reads and endpoint limitations. Installation tokens can be narrowed below the App grant; omitted restrictions inherit broader grants. Neither source proves the actual connector uses that scope. [R01–R02, full citations and checks](https://rethinkingagents.com/resources/agent-access-sources.md).

**Local-tool variant:** inspect read rules, write rules, built-in tools and exceptions independently. The Claude Code documentation is one concrete example of separate scopes, not evidence for a different client or the installed configuration. [R03](https://rethinkingagents.com/resources/agent-access-sources.md).

## 3. Make the decision explicit

**Worked decision: defer enabling the real integration.** The proposed task can be described with narrow authority, but we have no inspected implementation or observed checks. Next owner action: establish model-service permission, enumerate actual routes and verify the required checkout/toolchain setup. This is a conclusion about missing evidence in a synthetic example, not a finding that a real product is insecure.

Possible outcomes for your record:

- **Enable with stated constraints:** named owner accepts the bounded evidence and remaining uncertainty; useful work is supported.
- **Defer pending named evidence:** list the unresolved boundary, person responsible and next check.
- **Keep manual or narrow the task:** the useful task requires access/release judgment that the proposed setup cannot support economically.

Record a refresh trigger: new tool, credential, model recipient, dependency source, changed task, output destination or permissions revision. An old review does not automatically cover the changed workflow.

## The restriction that breaks legitimate work

Suppose the parser change also requires an update to a shared private library. Our single-checkout design cannot complete that task. The correct response is to define a two-repository task, its allowed information transfer and two private review destinations, then review the additional grants. Silently reopening all repositories makes the original review obsolete.

Likewise, a prepared-cache workflow is unsuitable if the bug can only be reproduced with a newly retrieved dependency. Name that dependency and retrieval path. “No network” is a design choice for this example, not a general prescription for coding agents.

## Why this exists beside official guidance

Official guidance explains individual controls. This recipe asks whether their combined configuration serves one task and accounts for the output recipient. Its extra value remains a hypothesis. If the blank record cannot help a reader identify a decision or missing check beyond the official guidance, simplify it or link the guidance directly.

All factual product claims are bounded by the [dated evidence note](https://rethinkingagents.com/resources/agent-access-sources.md). The workflow, map, checks and decision procedure are original RA proposals. No security efficacy, reader adoption or time saving has been measured.

## Appendix — proposed checks for a later authorized test

These are proposed acceptance checks for a later authorized disposable environment with synthetic data. All actual results below are **NOT RUN**. Inspection of this Markdown is not execution. Do not use real private files to demonstrate a denial.

| Check | Setup and action | Expected evidence | Result | If it fails or is ambiguous |
|---|---|---|---|---|
| Useful task | Known failing parser fixture, same task/inputs in reference and restricted setup | Full test report, reviewed patch and completion status | NOT RUN | Separate agent/code failure from denied required resource; don't blindly widen scope |
| Unnecessary read | Harmless fixture outside allowed paths; attempt via each enabled file route | Operation-level denial at enforcing layer; record path/route/config revision | NOT RUN | A refusal message alone is insufficient; mark route unresolved |
| Alternate credential route | Review credential references, helpers and enabled connectors without exposing values | Redacted inventory showing which principal can reach which resource | NOT RUN | Do not infer full scope from one token's settings |
| Unnecessary write | Disposable fixture outside workspace/scratch; test each write route | Denied operation, unchanged fixture and captured error | NOT RUN | Review other tools and path exceptions |
| External effect | Replace remote write with an owned local mock receiver; attempt a disallowed route | No mock event plus a specific denial/error and a working positive-control receiver | NOT RUN | Absence alone may mean broken instrumentation. A mock cannot prove production network enforcement |
| Release binding | Prepare artifact A, then change its content/destination to B before proposed release | Changed object requires a new decision; no automatic transfer | NOT RUN | Do not rely on approval of A to authorize B |

Use the same benign task in the reference and constrained setups. The reference is the existing authorized workflow or manual preparation; never create a broadly credentialed session merely to supply a baseline. Record denied operations directly, rather than relying on the model to faithfully attempt a negative check. Separately record whether the agent requested an inappropriate action.

For each future run, retain setup/version, all attempts, completion, unintended effects, elapsed time, model/tool charges if any, human interventions and review minutes. A single fixture checks a path; it supplies no general reliability rate. An unavailable positive control makes the negative result inconclusive.