Before you connect an agent to a private repository

Already ran the agent and cannot tell whether a write happened? Use the uncertain-action timeline and record. This page covers the earlier decision to enable access.

The example: fix a parser, return the patch privately

In this fictional workflow, the agent fixes a quoted-delimiter bug in the private repository parser-lab. Success means the agreed parser tests pass and a reviewer receives the complete patch and test report privately. No real repository was accessed or tested.

Keep the useful inputs

The approved checkout, issue reproduction, compiler and prepared dependency cache. Issue text can describe the bug; it cannot authorize more access.

Exclude unnecessary authority

Unrelated repositories, home documents, cloud credentials and agent-controlled publication. Review alternate tools and credentials, not just the main connector.

Name every recipient

The model service receives private context if this is a hosted agent. Decide whether that recipient is permitted before launch. A network rule on shell commands does not answer that question.

Separate preparation from release

Produce a local patch and report first. A later release decision covers the complete outgoing content, destination and visibility—not just one displayed diff.

Choose a fallback and a stopping condition

If the prepared toolchain cannot reproduce the bug, retain the private patch and stop for the task owner. A broader token, new connector or dependency download needs a new decision. Instructions alone do not enforce that boundary.

This design assumes the checkout and dependencies can be prepared without leaving a general credential in the run. If your client needs a live connector, inspect its actual repository and operation grants instead of assuming this example fits.

Label what you know

Use these evidence states in the record. They can coexist; none is a safety score.

Requested

The rule you want.

Documented

A dated source describes the behavior.

Configured

Inspected settings indicate the rule is active.

Observed

A specific operation has a recorded outcome under a named configuration.

Unknown

The evidence is missing.

A token setting is configured evidence about that token. It does not establish that another tool lacks a broader credential. One denied read demonstrates one path under one configuration, not complete containment.

An access inventory describes available routes. A trace records events your instrumentation captured. A sufficiently current, authorized check at the receiving system can establish a specific external effect. This review records your decision from that evidence; it substitutes for none of those observations. See the worked timeout example for the difference between an attempted operation and a confirmed effect.

Use the record in three passes

1. Define the job. Write the completion criteria, required inputs, output audience and unnecessary operations.
2. Trace the routes. For shell, file tools, connectors and output paths, name the principal, enforcing component and evidence state. Include prior context and logging.
3. Make the decision. Enable with stated constraints, defer for specific evidence, or keep the task manual. Record who owns the next check and what change invalidates this review.

Aim for a 30–45 minute initial review, leaving implementation work as a separate task. That is a target to test, not a measured completion time.

The restriction that breaks useful work

If the parser fix also needs a shared private library, the single-checkout design cannot finish the job. Define a two-repository task and its permitted transfers. Silently restoring access to every repository invalidates the original review. Likewise, a prepared cache is unsuitable when reproducing the bug requires a new dependency.

Try it and tell us where it fails

For a short test without private systems, use the fictional integration packet below. Set aside 20 minutes, complete the blank record and decide what evidence you would need before enabling it. No agent run or account connection is required.

Download the reviewer brief and fictional packet (.md)

• Which access or release boundary did you identify?
• Which question could you not answer from the packet or record?
• Did the record change your decision? What would your usual process have done?
• How long did it take, and what could we remove?

Send only a non-sensitive summary to hello@rethinkingagents.com. Keep completed internal records, code, credentials and traces private. We have not yet established that this resource improves review outcomes.

Sources and limits

This resource turns the analyses of task authority and sandbox boundaries into a proposed review procedure. Official documentation supports individual control descriptions; it does not verify your integration.

Read the dated source record. Sources checked September 17, 2026. The worked example is synthetic; all proposed behavior checks remain NOT RUN.