Before a team adopts AI agents, somebody sensible asks the blocking question: if we add this thing to our workspace, what can it read? It is the right question, and most answers to it are reassuring rather than specific.
Here is a specific one. An agent in Atwork is limited by two independent things — the scope you gave it, and the permissions of the real person it is acting as — and the narrower of the two always wins.
This assumes you know roughly what a custom agent is and how it gets work; if not, start there and come back.
What determines what an agent can reach?
Two settings, applied together.
Scope is where the agent is allowed to work: which spaces, and which sheets inside them. This is set once when the agent is built and it is a hard boundary, not a preference. An agent scoped to your Marketing space has no path to your HR sheets — it will not find them, cannot be talked into finding them, and does not know they exist.
Capabilities are what it may do inside that scope: read only, or also create and update items. These are separate choices, so a read-only agent with wide scope and a write-capable agent with one sheet are both coherent configurations, and both are safer than the thing people imagine when they hear AI agent.
The reason to keep these distinct in your head is that they answer different worries. Scope answers what data is involved at all. Capabilities answer what could change.
Whose permissions does an agent use?
A real person's — never its own, and never an unrestricted service account.
Which person depends on how it was invoked, and the distinction is worth getting right rather than glossing:
- When you mention an agent in a comment thread, it acts with your access. Same spaces, same sheets, same items you could open yourself.
- When an agent works a task from your board, it acts with the access of the person who created that item. That is the identity the work authorises against, not the identity of whoever assigned it.
In most teams those are the same person, or two people with equivalent access, so it rarely changes anything day to day. But if your workspace has genuinely asymmetric permissions between colleagues who share a board, that is the detail to check before you grant an agent write access — the relevant question for an assigned task is what the item's creator can see, not what the assigner can see.
What holds in both cases: the agent's reach is the intersection of its configured scope and a real human's permissions. Adding agents does not mint a new identity with a view across everything, and it does not surface data that nobody on your team can already open.
What happens when an agent changes something?
It happens under the agent's own identity, in the same history as everyone else's changes.
Agent activity is not anonymous and not hidden in a separate log. The agent appears as the actor on the item, its comments carry its name and avatar, and its edits sit in the same activity trail as a human colleague's. If you want to know what a given agent has touched this week, you look in the same place you would look for a person.
That is what makes write access acceptable at all: every field an agent changes is recorded against its name, so you can always reconstruct what it did and when. Treat its edits the way you would treat a new colleague's — visible and reviewable after the fact, which is exactly why you keep a human in the review path while you are still calibrating it.
Compare this with the common alternative, where someone pastes workspace data into a general chat tool and pastes the result back. That leaves no trail at all, and the data has left your workspace entirely. The agent-shaped version is the more contained of the two.
How should you scope a new agent?
Start narrower than feels necessary, and widen based on evidence rather than anticipation.
A sequence that works for most teams:
- Read-only, one space. Let it summarise and answer questions. Nothing it does can be wrong in a way that costs you anything.
- Read-only, the spaces it clearly needs. Widen once you have seen what it actually reaches for.
- Write access on one sheet. Give it the ability to change things only where you have already read a week of its output and found it sound.
- Widen from there, one step at a time.
The failure mode this avoids is the common one: granting everything on day one because it is easier than thinking about it, then discovering the agent's judgment is imperfect on data that mattered. Nothing about the technology forces that choice — it is purely a configuration habit.
The support triage agent walkthrough is a worked example of a properly narrow first scope: one space, write access on one sheet, and a human reviewing every result.
Which data should stay out of scope entirely?
Some categories are worth excluding by default, not because an agent handles them badly, but because the cost of being wrong is asymmetric:
- Compensation, performance reviews, and anything HR-confidential. Even read access invites accidental disclosure through summaries shared in a thread.
- Anything under a contractual confidentiality obligation where processing by a third-party model is not covered by the agreement you signed.
- Credentials and keys, wherever they are stored. These should not be in a workspace sheet regardless, but check.
- Personal data you do not have a basis to process this way, if you operate under GDPR or a comparable regime. Your data protection assessment governs here, not your enthusiasm for the feature.
For everything else, scope by usefulness rather than by caution. An agent that cannot see enough to do its job is not safe, it is just useless, and a useless agent gets replaced by someone pasting data into a chat window — which is the outcome you were trying to avoid.
Does the same reasoning apply to connected assistants?
Largely yes. If someone on your team connects your workspace to an assistant over MCP, that connection also authenticates as a specific person and reaches only what that person reaches.
The difference worth noting is not access but destination: data pulled through a connection travels into that assistant's context, which means your organisation's policy about which AI vendors may process which data applies. Access control and data governance are separate questions, and connected assistants are a governance question more than a permissions one.
What should you tell your team before rolling agents out?
Three sentences cover most of it, and getting ahead of the question prevents the quiet non-adoption that follows unexplained AI features.
- Agents see only the spaces and sheets we scoped them to.
- An agent always acts as one of us — your access when you mention it, the item creator's access when it works a task from the board. It never has a view of its own.
- Everything an agent does is recorded under its own name, so we can always see what it changed.
Add a fourth if you are granting write access anywhere: say exactly which sheet, and who reviews the output. People are markedly more comfortable with an AI teammate whose remit they can state out loud.
The short version
An agent's reach is the intersection of two things: the scope you configured, and the permissions of the person it is acting as — you when you mention it, the item's creator when it works an assigned task. Everything it does is recorded under its own name. Start it read-only on one space, and widen it when the output has earned it.
Start free and build a read-only agent on one space — the cheapest way to see the model in action is to watch a harmless one for a week.