Before You Give AI Access to Your Files, Set These Boundaries

An AI agent can be useful inside a project folder. It can read requirements, inspect a draft, update files, and help you continue unfinished work.

But the folder you connect may also contain old exports, client records, credentials, or documents unrelated to the task. Access to the whole workspace is often broader than the work requires.

Start with the smallest useful access scope. Separate what the agent can read, what it can change, and what it can send or publish.

A written instruction helps describe that boundary. The environment must enforce the parts you need to rely on.

Separate three decisions

Before connecting an agent, answer these questions independently:

Permission to read a document is not permission to publish its contents. Permission to edit a draft is not permission to deploy it.

The examples in this article describe a proposed workflow, not a security certification or a guarantee about any particular installation.

Instructions guide behavior; permissions restrict access

An instruction such as “skip private files” expresses intent. By itself, it does not remove the tool’s ability to read those files.

Likewise, a metadata label, an ignore file, or an exclusion in one search script is effective only within the mechanism that actually respects it. A different reader, shell command, connector, or linked directory may have a different access scope.

Use the controls your environment provides: scoped folders or mounts, tool permissions, restricted accounts, sandboxing, and limited connector credentials. Check both file tools and command execution paths when they are available.

For example, Claude Code’s permission documentation distinguishes instructions that guide the model from permission rules enforced by the application. Other tools have their own controls and limitations; verify the behavior of the tool you use.

A folder name or a Markdown rule is not an access-control system.

Choose useful context before opening the workspace

Begin with the active task and select the supporting material it needs.

For a website article, that might mean the draft, approved product facts, and the existing article layout. It probably does not require payroll records, unrelated customer exports, or your entire personal drive.

A practical retrieval policy can leave these categories out of routine discovery:

• Archived material that may describe superseded decisions.
• Generated reports, caches, and large logs unrelated to the task.
• Attachments whose contents have not been reviewed for relevance.
• Sensitive records outside the authorized work scope.

Treat secrets separately: keep credentials in appropriate secret-management facilities, and do not provide real credentials as sample context. Share sanitized configuration examples when the task needs to understand the shape of a setting.

Some excluded material may be needed later. Retrieve a specific authorized source when that need is established, instead of making every session scan everything.

Record the intended scope

Use a short task brief alongside the actual environment controls:

## Task access brief

Purpose: prepare a website article for review.

Read:

- The selected draft.
- Approved public product information.
- The existing article layout.

Write:

- The designated review copy.

External actions:

- No production publication is included in this task.
- Report when another source or action is needed.

Handling:

- Keep private source details out of public copy.
- Treat missing or unclear disclosure approval as unresolved.

This is a communication aid. Configure and test the corresponding permissions separately. Access labels in notes can help communicate handling expectations, but they do not automatically configure a sandbox or prevent disclosure.

In a KOS workflow, the task brief and selected project context should make the intended work clear. Whether a tool can cross that boundary depends on its configuration and the surrounding environment.

Verify with harmless files

Test the setup before connecting sensitive material.

Create a harmless sample in the permitted review folder and another dummy file in a location that should be inaccessible. Use the tool’s documented testing procedure to confirm that the approved file is available and the restricted location is blocked.

Check read and write boundaries separately. If the agent can use both a file tool and a shell, a denial from one does not establish that the other is restricted. Review linked folders and connected services too; their effective permissions may differ.

Use dummy content throughout. Never place a real secret in a file to see whether the agent can find it.

If the boundary does not hold, fix the configuration before continuing. An assistant promising to avoid a readable file is not evidence that access has been denied.

Keep a small access checklist

Before the next task, confirm:

• The connected folder or service matches the work scope.
• Private material outside that scope is inaccessible where required.
• Write access is limited to the intended destination.
• External actions and publication have explicit authorization boundaries.
• Available access paths have been tested with harmless content.
• The output is reviewed for unintended private details before sharing.

For guidance on giving tools consistent project instructions, read One Router, Many Agents. Use The Second Brain Maintenance Model to keep the supporting context current.

The KOS Starter Kit provides a starting structure for project context. Pair that structure with the permission controls of your chosen tools and environment.

Give the agent enough access to complete the task, and verify the boundaries that matter before expanding them.