Read-only and project-scoped tokens: how to keep an AI agent on a leash

"Should I give an AI agent access to my task list" is really three separate questions wearing one trench coat: how much can it see, how fast can I cut it off if something's wrong, and what still needs my sign-off even while it's connected. None of those depend on which model you're using — they're properties of how the server enforces access, not the agent's judgment.

Why scope matters more than the model

An agent can only do what its credentials let it do, regardless of how capable or careful the underlying model is. That's a deliberately boring, server-side guarantee rather than a hope about model behavior — the same reason you'd scope an API key for any other service down to exactly what it needs, not everything it could theoretically touch.

Full access, read-only, or one project

Every account gets its own MCP endpoint and its own tokens — never a shared or global one. On Pro and Teams, a token can be scoped down further: read-only, so an agent can see the queue and comment context but never change anything, or single-project, so it only ever sees one project's tasks and none of the rest of your account. Start narrower than you think you need; broadening later is easy, narrowing after the fact means you're trusting an agent that's already had wider access.

Revoking access instantly

Regenerating or revoking a token invalidates it immediately — no waiting for a cache to expire somewhere. And if you're recovering from something you're not sure about, changing or resetting your password revokes every API credential on the account at once, MCP tokens and connected apps included, so a suspected compromise doesn't leave agent access quietly alive after you've already changed the password.

The approval gate as a second leash

Scoping is about what an agent can see and touch; the approval gate is about what it can finish without asking. A task marked auto-OK can be closed directly — fine for low-stakes, reversible work. Anything else routes through propose_completion and sits in pending approval until a human signs off, and only a human can mark a task auto-OK in the first place. The two mechanisms cover different risks: scope limits blast radius, the gate limits unsupervised finality.

Auditable runs and budgets

Every agent session runs as a logged run with its own tool-call and time budget. check_budget tells you what's left before a session's allowance is spent, and once a budgeted task's allowance runs out, start_run is refused outright rather than letting the session keep going on borrowed time. That's a third, independent lever — not about access or finality, but about how much any single session can do before it has to stop and check back in.

A sane default setup

Start an agent read-only or scoped to one project, leave most tasks off auto-OK, and watch a few runs before loosening any of it. Widen the token's scope, or start marking routine tasks auto-OK, once you've actually seen what the agent does with the access it has — not before. None of this is about distrust; it's the same posture you'd take onboarding a new hire into a system with real consequences.