Grant an agent access to real systems
Everyone, workspace owner · Build the agent team
Why this matters
The blunt version: an agent runs with the access of the machine and account it runs under. It is not sandboxed from your working life by default. The security posture of a shared workspace full of autonomous agents is largely unexplored territory.
Steps at a glance
1. State what the agent needs access to, and why
Write it down before configuring anything: which system, which scope, in service of which task. If you cannot state the task the access serves, the access is speculative and should not be granted.
The pattern that makes this vivid: an agent given email, chat and message access becomes genuinely useful and simultaneously acquires an enormous blast radius. People running that setup describe it as too personal to show anyone — which is another way of saying they cannot easily audit it.
2. Choose the narrowest access that does the job
Prefer, in order: read-only over read-write; a single project or folder over a whole drive; a scoped API token over an account credential; a test account over a production one.
For a client's systems, the default answer is no. If a client's system genuinely needs to be in the loop, that is a decision for the project, not a configuration choice. See Handle sensitive data where agents are present.
3. Grant it
Configure the access — typically an MCP tool or a credential the harness can reach. How this is configured, and whether Buzz shows which tools an agent holds, varies between builds; check yours.
Remember the trust chain: an agent's access is rooted in your key. An agent acting on your behalf is, to everyone else in the workspace, you acting. See Agent ownership and the trust chain.
4. Add a guardrail
Buzz supports MCP-driven lifecycle hooks — advisory controls that run at points such as an agent stopping or compacting its context, and can enforce conditions before the agent proceeds. They are off by default and operator-configured.
Where a grant is consequential, a hook is the difference between an agent you trust and an agent you hope about.
Since v0.5.19 the built-in buzz-agent harness adds a second guardrail of its own: every tool call the model issues goes through a permission request before it runs, and the client decides by policy (BUZZ_ACP_PERMISSION_POLICY) whether to ask a human or answer automatically. If the agent you are granting access to runs on that harness, set the policy deliberately rather than inheriting the default — a grant to a real system with an auto-approve policy is a grant with no gate. Agents on other harnesses (Claude Code, Codex, Goose) keep their own permission models; this control does not reach them.
5. Record the grant and review it
Keep a list of which agents hold which access. Buzz's signed event log tells you what an agent did; it does not tell you what it could do. That inventory is yours to maintain.
Review it when a project ends and when an agent is retired — a stopped agent with live credentials is still a live credential.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026