Put the read-only flag in the token, not in the prompt

epilot has published a walkthrough of its CLI in which the two guardrails for AI agents are described as enforced server-side rather than in the client: `epilot auth login --readonly` produces a session that, the company says, physically cannot write because the restriction is baked into the token and the bearer cannot turn it off ^[6]. The second is an access token created with `read_only` and `anonymize` both set to true, which the post says returns all PII anonymized in every response ^[7]. That placement matters because most agent-safety plumbing in circulation today lives in a system prompt or a client config file, and both of those are files the agent can read and edit.

The surface being fenced off is large. epilot says one command, `npx epilot`, exposes every API operation in the terminal, covering entities, journeys, workflows, pricing, files and permissions across more than 50 APIs ^[1][2], with interactive pickers for exploration and `--json` plus `--no-interactive` for scripts ^[3]. The company's argument for skipping a custom integration is that agents already discover operations, read help output and parse JSON, so the CLI is the integration and no MCP server is needed ^[4]. Whether or not you buy that, it means the blast radius of a compromised or merely confused agent is the whole API, which is why the credential design is the load-bearing part rather than the ergonomics.

A read-only switch in a config file is a request. Encoded into the credential and checked at issuance, it becomes a property of the bearer token: the agent can ask for a write, and the server declines, regardless of what the agent has convinced itself of. Anonymization does the same job for exfiltration. epilot's framing is that the worst an agent can do is read data it cannot de-anonymize ^[8]. Note that this is epilot describing its own product; the post does not mention audit logging, token expiry, or scoping a token to a subset of APIs ^[16].

The tension sits inside the same post. The build workflow it advertises runs `epilot app init`, which scaffolds a manifest, a components folder, build tooling and a `SKILL.md` written for agents that Claude Code picks up automatically ^[10], then `add-component` to pull templates from `epilot-dev/app-templates` ^[11], then `epilot app dev` to serve a component from localhost inside the live epilot UI against real data ^[12], then `deploy`, which creates or updates the app, uploads assets and cuts a new version when the current one is locked ^[13]. Deploy is a write. An agent driving that workflow therefore cannot be holding the read-only credential ^[14]. The safe token and the productive token are different tokens, and the post does not say how you are meant to manage the handoff.

The same applies to anonymization: an agent that cannot de-anonymize also cannot join records on a real identifier or verify a specific customer's data, so the anonymized token buys safety at the cost of a class of analysis work ^[15].

Watch for whether anonymization covers every read path, including file downloads and exports, and whether epilot documents an audit trail for tokens created with these flags ^[16]. The broader thing to watch is whether other platforms follow the same pattern and move agent restrictions into token issuance, because a guardrail the agent can edit is not a guardrail.