How to Scope Agent Permissions by Project

Scope Agent Permissions by Project

Give an autonomous agent the narrowest project, folders, actions, external systems, and duration needed to produce a verified result. Keep irreversible authority, sensitive data, and public release separate unless the goal explicitly requires them and an authorized person has approved the scope.

Project-level permissions are useful because two tasks on the same machine rarely deserve the same access.

An agent preparing public content may need transcripts and web research. It does not need private mail or production publishing credentials. An agent fixing a repository may need source files and test commands. It does not automatically need cloud billing, DNS, or customer data.

flowchart TD
    A["Define the verified outcome"] --> B["Identify required assets"]
    B --> C["Identify required actions"]
    C --> D["Deny unrelated sensitive scope"]
    D --> E["Choose Ask or Allow for the remainder"]
    E --> F["Choose local or isolated worktree mode"]
    F --> G["Execute and record evidence"]
    G --> H["Revoke temporary access and review release"]

Start with the result, not the preset

Permission design begins with the task.

Name the artifact or state that should exist when the work is complete. Name the checks that prove it. Then work backward to the files, commands, domains, tools, credentials, and external actions needed to reach that state.

This keeps the permission decision tied to evidence.

“Full access because the agent is capable” is not a task requirement. “Read these episode folders, write derived drafts inside this package, and run this validator” is.

Create an asset boundary

Identify the folders and systems that contain the source material and the intended output.

Google's projects documentation says an Antigravity 2.0 project can span multiple folders. It also says project permissions inherit global rules and can be augmented at the project level.

Add a folder because the goal needs it, not because it is nearby. If the project spans a source repository and a separate documentation folder, name both. If private evidence should be readable but never modified, preserve that distinction in the available controls and operating procedure.

Keep secrets, identity records, production configuration, unrelated repositories, and personal files outside the project unless the task genuinely requires them.

Separate actions from assets

Access to a folder does not answer which actions are acceptable.

An agent may need to read a configuration file without changing it. It may need to run tests without installing packages. It may need to create a draft without sending it. It may need to inspect a deployment without deploying.

Google's permissions documentation represents sensitive operations as actions against targets. It describes Deny, Ask, and Allow lists and gives Deny the highest precedence.

Use that precedence deliberately. Deny actions that should not happen in the project. Ask when a human needs to judge the specific target or consequence. Allow only the repeatable actions that are necessary and understood.

Treat external connections as authority

Model Context Protocol servers can add live context and executable tools.

Google's MCP documentation explains that MCP can connect the agent to databases, developer tools, file parsers, and external APIs. It documents Ask as the default for unconfigured MCP tools and allows rules for a specific tool, a server, or all MCP tools.

The widest wildcard is rarely the best starting point.

A connected tool may be able to read customer records, create issues, change infrastructure, send communications, or make purchases. The fact that the tool is installed does not mean every project should use every action.

Name the server, tool, operation, data class, and release boundary. Confirm how the connected system authenticates, logs, scopes, and revokes access.

Use hooks as controls only after reviewing the script

Hooks can run commands before or after tools, before or after model calls, or when the loop stops.

Google's hooks documentation describes events that can allow, deny, or ask before a tool runs and can execute validation or diagnostics at other stages.

That makes hooks useful for enforcing tests, blocking dangerous commands, recording actions, or checking a completion condition.

It also makes the hook itself part of the trusted computing base. A hook can read inputs, run local commands, alter behavior, or fail. Review the script, its permissions, its timeouts, its output contract, and the data it can expose.

A safety label on an unreviewed hook is not a safety control.

Choose local work or isolation

The project model distinguishes direct local work from isolated Git worktrees.

Local mode is appropriate when the agent needs to operate in the active folder and the user is managing one interactive change. It creates shared state with other local work.

Worktree mode is useful when concurrent agents could conflict, the active checkout should remain untouched, or the result needs an isolated review. It reduces one class of interference. It does not eliminate unsafe commands, sensitive data exposure, dependency risk, or merge errors.

Isolation should follow the threat and coordination model.

Do not confuse broad authority with autonomy

In E118, Dalton demonstrates a custom unrestricted mode because he disliked repeated prompts. He also describes sandboxing the development folder, limiting iterations, and keeping a kill path.

That is a personal risk decision, not a default recommendation.

Current Google documentation says terminal sandboxing is in preview on macOS and Linux and is coming later to Windows. Platform behavior and release status need verification.

Even a strong sandbox does not authorize an irreversible external action. An email, publication, payment, deletion, credential rotation, or production deployment can be valid at the operating-system level and still exceed the user's intent.

Autonomy means the agent can continue within a known boundary. It does not mean the boundary disappears.

Add time and completion boundaries

Permissions should not outlive the work without a reason.

Record which access is permanent, project-scoped, conversation-scoped, or temporary. Decide what should be removed after the task. Keep a separate approval for release actions that occur after the artifact is prepared.

The goal should also define when the agent stops. A maximum iteration count can contain runaway work, but it is not proof of success.

Completion requires the expected artifact, required validation, documented exceptions, and no remaining authorized work.

Verify the authority map

Before execution, read the project as if the agent used every allowed action.

Could it modify source material that should be immutable? Could it reach credentials unrelated to the task? Could a connected tool send or publish? Could two agents write the same files? Could a hook expose a transcript or secret? Could a successful test still leave a public action unauthorized?

After execution, inspect the changed files, commands, tool activity, external state, and validation evidence. Revoke temporary access and retain the record needed to explain what happened.

The Antigravity subagent documentation says subagents inherit safety configurations. That makes the parent authority map even more important. Delegation can multiply execution, but it should not multiply permission.

The project is the security sentence

A useful permission design can be read as one sentence.

This agent may use these sources and tools to create this result, inside this boundary, until these checks pass. It must ask before these consequential actions, can never perform these denied actions, and cannot release the result without this authority.

If that sentence is unclear, the configuration is probably unclear too.

E120 explores the larger AI-coworker relationship. E118 supplies the operating condition that makes such a relationship credible: autonomy should be bounded, observable, and reversible where possible.

Editorial and authority note

This guide is general educational content, not a security architecture, threat model, privacy assessment, secrets policy, data-governance plan, access-control specification, product guarantee, or legal opinion. Product behavior and sandbox availability are time-sensitive. Security, privacy, secrets, data, legal, technical, editorial, accessibility, and founder review remain required before publication.

AI assisted with research, structure, drafting, and validation. Dalton Anderson remains the attributed author and final editorial authority.