How do you give AI agents access to your code safely?

The safe model is not giving access to your code. It is giving access to a place that answers questions about your code. Four properties have to hold together for that sentence to mean anything: a read-only connection, one server per project, answers backed by commits rather than raw files, and access that is revocable at any time.

Put that way, it is a list, and lists cannot be verified. What can be verified is what an access grant becomes between the day it is issued and the day it is withdrawn. That is where the four properties get tested, one at a time, by entirely ordinary situations. So let us follow one grant across its life.

The life of one access grant, in five moments

The days below are illustrative: they mark the order of events, not a real calendar. Each moment tests one property, and only one.

Day 0 — the grant

An agent needs to answer questions about your product. Someone opens the conversation with "we should just give it the repository."

The decision is about scope, not trust. An agent that answers questions never needs to write anywhere, so the connection is made read-only, and that property lives in the permissions granted rather than in anyone's intention. A write permission nobody uses is still a write permission.

Then comes the perimeter. One server per project, with no bridge between them, means a question about product A cannot return a fragment of product B. That is wiring, it is checkable, and it does not depend on a rule someone has to remember to write.

Day 1 — the first useful question

A support question arrives: "does the CSV export accept ISO-formatted dates?"

There are two ways to answer. The first opens the relevant files and hands them to the requester to read. The second returns a sentence, sourced to the commit that settles it.

This is not about convenience. In one case the requester obtained source code; in the other, information. A support agent that shows a customer a snippet of your parser has moved something out of the codebase that had no reason to leave it, and nobody decided that.

Day 9 — the question that must go unanswered

Someone asks the agent for the payment provider's API key, or for the contents of a configuration file.

A server that returns answers sourced to commits has no path to that request: it does not hand back raw source, so it has nothing to hand back. Repository access would have returned the file.

The difference is not a filtering rule that happened to work that day, it is what the server is able to do at all. That distinction is the one that matters when you evaluate an access grant: what is impossible by construction does not get revised under the pressure of a special case.

Day 30 — the review

Someone asks where a given answer came from. If every answer carries the commit it was drawn from, that takes a moment to settle, and anyone can ask. An unverifiable answer forces you to trust the agent, and an invented answer looks just like a correct one, as we detailed in why AI agents hallucinate product features.

Traceability is not extra security. It is what makes the grant reviewable by someone who was not in the room on day 0.

Day 45 — revocation

The contractor's engagement ends. Access is withdrawn, answers stop being served.

This is when you find out what day 0 actually distributed. If a repository token circulated, you have to locate it, revoke it, and hope it was not copied elsewhere. If the requester never held a token, there is nothing to locate: the repository connection belongs to the server, it was made once, and it is cut in the same place.

Why third parties change the problem

As long as the requesters are your own developers, these five moments are handled by the tools you already have. The model strains the moment you step outside that circle, which is the common case.

Agent platforms are the clearest illustration. A support agent inside Intercom or HubSpot answers customers about your product; handing it a GitHub token so it can read your files is out of proportion to the actual need, which is to get a correct answer. An answers endpoint serves it better, without distributing a read permission.

Then come contractors and agency clients. Plenty of contracts now govern the use of AI tooling on client code, and a repository token handed to a third party usually falls under them. We covered that setup in running AI on client code without breaching the NDA. What these requesters share is legitimate questions and no reason to hold repository credentials.

"What changed in the product this week?"

Asked word for word, this question decides how much access is required, and the answer is counter-intuitive.

Answering it takes more than the current state of the code: it needs two states and the history that connects them, so commits and their diffs. You would think that argues for opening things up further. It argues for the opposite. The more a question is about a difference, the less the requester needs to see files. What they want is the sentence that says what changed, with the commit as a reference.

That is what an MCP server connected to your repository does: it reads the real code, resynchronised on every push, plus git history, and turns that into answers. The material read is wide; what leaves is narrow. The ratio between the two is the real measure of an access grant, far more than the length of a permission list.

"We can just use the official GitHub MCP server"

That is a real option, technically sound, and it serves one case well: the equipped developer wiring their own assistant to repositories they already have rights to. We published the walkthrough and the limits in the GitHub MCP server and what it actually answers.

The constraint is categorical rather than qualitative: that route needs one credential per requester. Fine for five developers. Unworkable for a support agent, for customer success, for a client under contract. Those are the people asking most of the questions about your product, and day 45 comes around for every one of them.

The second gap is the material. Raw repository access returns files, and someone still has to read them and derive an answer. Claude's GitHub connector and what it cannot see shows where that difference is paid on history questions.

"But DeployIt reads your repository too"

It does. It would be poor form to ask others for a clarity we withheld ourselves, so here is the frame, in the terms used above.

The GitHub connection is read-only and revocable at any time. One project, one server, no bridge between projects. What leaves the server is answers backed by commits and diffs, never raw source. The requester gets the information, not the access, and there is no GitHub token to hand over. The implementation details live on our security page.

What we do not claim: DeployIt prevents nobody from doing anything. It is a read-only service that answers questions. Your organisation's access discipline stays yours.

What this model does not solve

It says nothing about what happens next. A correct, sourced, legitimate answer can be pasted into a message by the person who received it. No access model follows information once it has been read.

It also does not cover anything that does not live in the repository being read: your billing, your contracts, your customers' data. A server grounds what it reads and nothing else.

Finally, none of these properties is a certification. They are design properties, checkable one by one. That is their value and their limit.

Mini-FAQ

Do we need a dedicated service account for the agent? If you go through direct repository access, yes, and plan its revocation at the moment you grant it. If you go through an answers server, the question disappears on the requester side: the server holds the connection.

Is read-only enough on its own? It rules out writes, which is the easiest of the four problems. The other three — perimeter, the nature of what leaves, revocation — are settled elsewhere, and they are the ones that show up on day 9 and day 45.

Our developers already have access to everything, so what is the gain? The gain is not theirs. It belongs to the requesters who do not have that access and still have questions: support, customer success, integrators, clients.

How do we check what the agent could really see? Ask it something whose answer requires a file nobody should obtain. What comes back tells you more than a documentation page.

What to remember

An access grant is judged on what leaves, not on what goes in. A server can read an entire repository and let nothing out but sourced sentences; a narrow token can still put files into circulation.

The four properties hold together: read-only, one server per project, answers instead of code, and a revocation that genuinely cuts. Remove one and the life cycle above jams at a specific moment, always the same one.

DeployIt is free during early access; paid plans arrive in January 2027. The MCP server stays in early access: the design partner program is the way in for teams who want to put this access model to work on their own repository.