“Clone it and let the agent read the repo” sounds like a harmless first move. It is also how a project’s own instructions, prompt templates, themes, and extension code become part of an agent’s working environment. On August 4, the alejandro-ao/tau repository added Project Trust: a flow that makes the agent ask before it loads those project-controlled inputs.
That is a useful reframing: a repository is not merely where an agent works; it can be an input bundle that tries to shape how the agent works. The alejandro-ao/tau project’s public guide says the new gate checks names and metadata first, then asks before reading scoped AGENTS.md, project .tau and .agents skills and prompts, themes, system-prompt files, and extension candidates.
Local is no longer enough
The decision is tied to the canonical working directory rather than a guessed repository root. A reader can trust the exact folder, its displayed parent, or just the current run; they can also decline, with the same exact-folder or run-only choices. A child decision overrides an inherited parent one. In headless work, unresolved trust follows a user setting, while --approve and --no-approve apply only to that invocation.
The implementation matters because it is trying to stop “ambient” project material from sneaking in during ordinary lifecycle changes. The new tests cover a declined destination project after a session replacement, a reload that fails without replacing the live snapshot, and a project extension that must not survive a move to a different folder. This is not a warning banner bolted onto startup; it is an attempt to make the input choice survive the awkward parts of a working session.
A gate, not a moat
The strongest challenge to the story is also the sentence Tau puts in bold: Project Trust is not a sandbox. It does not constrain files, processes, shells, tools, network access, credentials, package installation, prompt injection, or data exfiltration. A project you trust can still be malicious. User-level resources and explicitly supplied CLI paths remain eligible, and project extensions still need their own opt-in.
That honesty makes the change more interesting, not less. It separates two decisions that agent tools often blur: whether a project gets to supply context at all, and what an agent is later allowed to do with that context. If you use Tau on unfamiliar clones, inspect the trust prompt as carefully as you inspect a permission prompt. The next signal worth watching is whether this boundary stays comprehensible when teams move between projects, reload sessions, and encounter more elaborate project-provided agent setup.