Agent Safety & Permissions

Know what an agent can do

A chat assistant may only suggest text, while a coding agent can often read project files, edit them and run terminal commands. That extra ability is useful for exploring a project, but it means a mistaken instruction can affect real files. Before using an agent, learn which folder it can access and whether it asks before running commands or applying changes.

For your tutor-mode quest, keep the agent working inside the project folder you intend to change. Open that folder in your editor or launch the tool from it. Do not point an agent at your home folder or an entire drive: the project boundary limits accidental reads and edits.

Keep credentials out of prompts

Never paste passwords, API keys, access tokens or the contents of .env files into a prompt. These values can grant access to accounts or services. If an error mentions a secret, replace the value with a placeholder such as [REDACTED] while keeping the useful error wording.

Use .gitignore to keep local secret files out of Git. A file being hidden in your editor does not automatically mean it is safe; check what you are sharing and what you stage for a commit. If a secret is exposed, revoke or rotate it through the service that issued it—deleting the visible text may not undo exposure.

Review before accepting

Read every proposed change before you accept it. Check the file names, inspect the diff, and ask whether each edit belongs to the task. A command that deletes files, installs software, changes permissions or contacts a service deserves extra scrutiny. If you do not understand a command, ask the agent to explain it before running it.

git status --short
git diff

These checks show changed files and their edits; they do not prove a change is correct. You remain responsible for testing the result and deciding whether to keep it.

Test the boundaries safely

Your optional CLI quest can test whether an agent respects tutor mode: ask it to explain a concept without writing code. Use a disposable project and harmless files. Do not test by granting broad access or asking it to handle credentials. If it ignores the boundary, stop, inspect any changes and tighten the instructions before continuing.

Good safety habits make experimentation possible. Restrict the working folder, protect secrets, review commands and diffs, then test changes yourself. An agent can assist, but it does not take responsibility for your project.

A folder choice is not an enforced sandbox

An agent launched inside a project may still be able to read parent folders, execute programs or contact external services. An instruction saying “stay here” is behavioural guidance, not an operating-system restriction. Inspect the tool's real access and approval settings. Do not assume .gitignore prevents reads: it controls Git's untracked-file handling only.

Evaluate a proposed action concretely

“List this project's files” is different from “upload this project's files to an external service”. Both may start by reading the same folder, but the second shares data. “Show git diff” is different from “discard all changes”. Before approval, ask what files are affected, whether data leaves your machine, whether anything is deleted/overwritten and how you will verify or recover.

For harmless practice, use a disposable folder with a single note and no credentials. Ask the agent to explain a command without running it, then compare that explanation with official documentation. Do not grant access to your home directory, cloud credentials, account cookies or private work merely to test whether a rule is obeyed.

Keep a known working commit before accepting a code change, review the diff afterward and test the visible result. Git helps recover committed source, but cannot automatically reverse an external email, a database write or an uncommitted deletion. If a tool makes an unexpected action, stop, inspect and revoke exposed credentials if needed rather than simply adding a stronger sentence to AGENTS.md.

Before completing this lesson, identify an enforced permission versus an instruction, and classify one harmless read, one file-changing operation and one external-data action. These are judgment checks—not an invitation to test destructive commands.