Give an AI agent the access it needs and nothing more?

You want an AI agent working on your projects, and your security team wants to know what it can reach. That question should come first. The safe way to introduce an agent: limit what it has access TO, before you decide what it can DO.

It is tempting to do it the other way around. You list the tasks you want automated, then grant whatever access those tasks need. The access list grows with the task list, but nobody owns the total.

But what if we start from the access list instead? This is the better approach, and this article will show how we did that on a project manager assistant for one of our clients, but also where the approach can still leave some small risks.

What the agent can see, and what it cannot

Our client manages projects on behalf of its own customers. Its project managers spent a large share of their time on recurring manual work: tracking progress, keeping customers informed, and reporting project health internally.

We built an assistant on Hermes, an agent framework, with Claude Sonnet as the underlying model. Before we defined what the assistant would do, we defined what it could reach.

The result is one machine, one read-only account and one inbox, which give the assistant the access it needs to do its work and nothing beyond that…our agents don’t escape our sandbox!

Within that access, the assistant compiles weekly progress reports for customers from pull requests and customer communication. The project manager for each project approves every report before it reaches a customer. It also reviews each project on an ongoing basis and reports to the project manager and to company management.

Why read-only and project-scoped access came first

We treated access as a constraint from the start. Reporting on progress means reading pull requests and customer messages. Nothing in those tasks called for write access, so we did not grant it.

Read-only access limits the cost of a mistake. An agent that misreads a situation can write a poor report, but it cannot change your code. A person can check a poor report. Undoing a bad change takes longer.

A scope list is also easy to review. Someone at the client can read a list of projects and say yes or no to each one. That decision stays with the client, and we take responsibility for setting it up as agreed and documenting it.

There is a trade-off though. An agent that can only read cannot fix anything it finds, such as commenting on a pull request. If you want that later, treat it as a separate decision, with its own review, instead of a quiet widening of the first one.

Five questions to settle before an agent goes live

Access decisions hold up better when they are written down as answers. We recommend asking the same five questions on every agent project, and having the client review the answers before go-live.

Each answer below has two parts. The first is what we set up on the project manager assistant. The second is the practice we recommend for any agent project.

What can the agent read, and who approved that list?

On this project. The agent has a read-only account in the client’s source control system (TFS), scoped to a pre-selected set of projects. It also reads a dedicated inbox.

Good practice.

• Keep an access register on one page. For each system, record the account the agent uses, the permission level, the projects covered, the owner and the approval date.
• Give the agent its own account. Never reuse a person’s login, because then you cannot tell who did what.
• Start narrower than you think you need. Adding a project takes minutes. Explaining an exposure takes much longer.
• Review the register on a fixed schedule, and remove a project from scope when it ends.
• Log what the agent reads, so you can answer “what did it see?” after the fact.

Can it change anything? If so, what, and who approved that?

On this project. Not in the client’s systems. The TFS account is read-only, and the inbox only receives messages, so the agent cannot send email. The assistant prepares reports, and the project manager approves them before anything reaches a customer.

Good practice.

• Treat read and write as separate decisions. Write access to any system is its own request, with its own owner.
• Prefer “propose, then approve.” The agent drafts a change or a message, and a person applies or sends it.
• If you do grant write access, limit it to one narrow area and to actions you can undo. Do not grant deletion.
• Set limits on volume and cost, so a loop or a mistake stops itself.
• Keep a way to switch the agent off quickly, tell people where it is, and test it.

Who can send it messages, and what can a message make it do?

On this project. A dedicated inbox receives messages from the client’s team and from its project customers. The inbox only receives, and nothing travels between the agent and a customer without approval from the project manager for that project.

Good practice.

• Treat every incoming message as untrusted text. A message is something to read and summarize, not a command to follow.
• Separate trust levels. A message from the client’s team and one from a customer should not carry the same authority.
• Limit sender addresses where you can, and flag unknown senders for a person to review.
• Keep permissions small. An agent that can only read and report has little to give a person who tries to manipulate it.
• Limit where the agent can send information, so a manipulated agent cannot forward project details to an outside address. A receive-only inbox, as on this project, closes that route.
• Do not let the agent open or run files from unknown senders.

Where does the data it reads go, including to the model provider?

On this project. The agent runs on a dedicated machine inside the client’s network and uses Claude Sonnet as its underlying model.

Good practice.

• Draw the data flow before go-live: what the agent reads, where it is processed, what is stored, and for how long.
• Check the model provider’s terms on data retention and on training use, for the exact plan you will run.
• Send only what the task needs. Remove or mask personal data that does not change the result.
• Know what the agent keeps. Agents often store notes, files and history on their own machine, so decide who can read that store, how it is protected and when it is deleted.
• If the data includes personal data of people in the EU, bring your data protection officer in early.

Who reviews its output before it reaches a customer or manager, and who owns an error?

On this project. The assistant compiles weekly progress reports for customers. It also reports on project performance to the responsible project manager and to company management. Nothing goes to a customer without approval from the project manager for that project. The manager who approves a report owns what goes out. We own the setup, and we fix the agent when it gets something wrong.

Good practice.

• Name one owner for each type of output. “The agent” is not an owner. A person is.
• Review every customer-facing output at first. Move to sampling only after you have measured how often reviewers make corrections.
• Make outputs checkable. Each statement in a report should point to its source, such as a pull request, so a reviewer can verify it quickly.
• Present judgment calls as indicators. A reading of customer sentiment is a signal to look into, not a verdict on the customer.
• Keep a record of corrections. It shows where the agent is weak and when it is safe to review less.
• Agree with the client whether customers are told that a report was compiled by an agent.

What the approval step costs, and what it still saves

The project manager no longer writes the weekly update. The project manager reads it and approves it, which takes a fraction of the time. That approval keeps a named person accountable for every customer report, so we treat it as part of the design.

The cadence gives one fixed number. Weekly reports mean about 52 reports a year for each project the assistant covers, and the project manager for that project approves each one.

The table below is an illustration, not a client result. It assumes a project manager who runs five projects, needs 45 minutes to write each weekly update by hand, and needs 10 minutes to review and approve one the agent drafted.

What this setup does not protect against

Even with all five answers in place, limiting access reduces risk without removing it. Four limits are worth stating plainly.

• The agent still reads what it can reach. A pull request or a customer message may contain information you would rather keep narrow. Scoping to selected projects limits that exposure, but it does not make it zero.
• The model provider is part of the picture. The agent uses Claude Sonnet as its underlying model. If your rules do not allow project data to reach an external model provider, say so at the start. A model hosted inside your own environment may fit better, with its own trade-offs.
• Outside people can write to the agent. The inbox receives messages from project customers. Any text an agent reads can be misleading or written to steer it, so what the agent is allowed to do with a message matters as much as who can send one.
• Access limits do not make the output correct. A report can still be wrong, and a read on customer sentiment can miss the point. Here the safeguard is the project manager’s approval, which every customer report needs. The project manager remains accountable for what goes out.

How to widen access later, on purpose

Access will grow, because needs grow. The aim is that each step is a decision a person made, not a slow drift.

Treat every request for more access like a small change request, and write down five things:

1. What the agent needs to do that it cannot do now.
2. The smallest permission that allows it.
3. The person who owns the decision and approves it.
4. When the permission expires or comes up for review.
5. How you roll it back if it causes a problem.

Then run the change in a limited form first. Use one project or one type of message, with a person reviewing the results for a defined period. If the results hold, extend it. If not, roll it back and fix the cause.

Here is a concrete case. If the client wanted the assistant to comment on pull requests, that is a write permission. We would request it separately, scope it to one project, and review it as a new decision. We would not add it to the existing read-only account.

Write the access list before the task list

Before any agent goes live on your projects, ask your development partner to answer the five questions above in writing.

1. What can the agent read, and who approved that list?
2. Can it change anything? If so, what, and who approved that?
3. Who can send it messages, and what can a message make it do?
4. Where does the data it reads go, including to the model provider?
5. Who reviews its output before it reaches a customer or manager, and who owns an error?

If any answer is vague, narrow the access until it is not. You can widen it later, on purpose, with a named owner.

Read the full case study, or talk to us about adding an AI agent to your delivery process.