Are AI coding agents safe for private repos? 8 questions

Are AI coding agents safe to connect to a private repository? It depends almost entirely on architecture, and the vendor made those architectural choices long before you showed up. The model matters less than where your code runs, what the sandbox can reach, and what happens to the credentials. That's good news for a buyer, because architecture is checkable. You don't have to trust a marketing page; you can ask specific questions and judge the answers by how concrete they are. Here are the eight we'd ask before connecting any background coding agent to a private repo, and what a good answer sounds like. We answer them for Sinatra along the way, since publishing a checklist and ducking it ourselves would be a bad look.

1. Where does my code run, and for how long?

Your repo has to be checked out somewhere for the agent to work on it. If that somewhere is a long-lived shared machine, every run adds to a pile of source, build artifacts, and credentials that a later bug or breach can find. Lifetime is the whole question: code that no longer exists can't leak.

A good answer: each run gets its own isolated sandbox, created for the task, shut down when the run finishes, never reused. That's Sinatra's answer, word for word.

2. What can the sandbox reach?

A sandbox with open internet access can send your code anywhere, and prompt-injected instructions hidden in a ticket or a dependency can tell it to. Egress policy decides whether "the agent tried to phone home" is an incident report or a blocked connection.

The answer you want is an allowlist: the endpoints a coding task legitimately needs, and nothing else. Ask separately whether the sandbox has standing access into the vendor's own infrastructure; it shouldn't. Sinatra restricts network egress from its sandboxes.

3. Can the agent touch production?

There's exactly one acceptable answer, and it's no. An agent with a path to production databases or deploy targets turns a wrong guess into an outage.

The good version of "no" is structural rather than policy: the sandbox has no route to production, so misbehavior can't reach it. Sinatra has no access to your production systems. A task changes code on a branch, and that's the entire surface.

4. What are the repo permissions?

Broad, long-lived credentials are how a contained problem becomes an org-wide one. A token that can read every repo in the org, or that stays valid for months, has a blast radius far beyond the task it was minted for.

Look for tokens scoped to the repos you enabled and short-lived enough that a leaked one goes stale fast. Ask, too, whether you can enable repos one at a time; you should be able to pilot on one quiet repo before the agent sees anything else. With Sinatra, you enable repos individually.

5. Is my code used for training?

This one has the least room for nuance. If your code trains someone's model, fragments of it can surface in other people's completions, and no retention policy walks that back.

The answer must be no, and it must be in writing, in terms you sign rather than a blog post. Sinatra does not use your code to train models. Bringing your own model key adds a second layer worth having: your code goes to the model under your own provider agreement, with the data terms your team already reviewed.

6. What's the merge gate?

Autonomy on the way in is fine; autonomy on the way out is not. The property to verify is that nothing reaches your default branch without a human merging it.

A good answer names the pull request as the boundary: the agent's output is a branch and a PR, reviewed like any teammate's. For Sinatra, the PR is the gate. Nothing lands on main until a person merges it.

7. Where do my model keys live, if it's BYOK?

A bring-your-own-key setup means the vendor holds a credential that spends your money and carries your data terms. Handled carelessly, the key is a bigger liability than the code.

The baseline is encryption at rest and a commitment that the key is used only to run your tasks. The key being yours is itself a control: you can watch its usage on your provider's dashboard and revoke it there at any time. Sinatra stores keys encrypted and uses them only for your tasks.

8. What's logged, and who can see it?

Runs produce logs, and logs collect source snippets, file paths, and error messages with real values in them. Retention and access control on logs is where otherwise tight architectures quietly leak.

Ask what's captured from a run, how long it's kept, and which vendor employees can read it under what process. A specific answer ("this data, kept this long, access-controlled") is the pattern to trust. "Industry-standard practices" is the answer to walk away from.

So, are AI coding agents safe?

They can be, and the vendors that got this right will answer all eight questions in concrete nouns: sandbox lifetimes, allowlists, token scopes, named gates. What you're listening for is safety that's structural, where the dangerous thing is impossible rather than forbidden. Distrust any answer that leans on policy, or on the model behaving well.

Sinatra's shape, for the record: tasks run in isolated short-lived sandboxes with restricted egress and no access to your production systems, your code is never used for training, keys are stored encrypted and used only for your tasks, and a human merge is the only path to your main branch.

Common questions

Can an AI coding agent push to my main branch?

Not if the merge gate is designed properly. The agent pushes to its own branch and opens a pull request; merging is a human action. Verify this per vendor rather than assuming it, since permission models differ. With Sinatra, nothing reaches main until a person merges the PR.

Does my code get sent to the model provider?

Yes. That's how the agent works: a model reads code to write code. The questions that matter are which provider, under whose agreement, and with what training and retention terms. With BYOK, your code goes to your own provider under the agreement you already have.

Do I have to connect every repository?

You shouldn't have to, and starting with one is a sensible pilot. Enable a single low-stakes repo, run a handful of tickets through it, and read the PRs closely before widening access. Sinatra works on the repos you enable, so a narrow pilot is the default rather than a workaround.

The checklist is only half the evaluation; the other half is watching the agent work on a repo you chose. You can start for free, or read the docs for how the pieces fit together.