Problem

I want AI coding agents (Claude Code, Cursor, etc.) to read my Railway logs and other read-only stuff. As far as I can tell, any token or CLI login that can read logs can also delete projects/environments, read unsealed variables and deploy. So giving an agent logs means giving it everything.

Why workarounds aren't enough

• Agent hooks and deny rules: they match the command text, and that's easy to get around: a full path to the binary, sh -c, or calling the API directly with the stored token. Claude Code's own docs call this kind of argument matching "fragile".
• A custom logs-only MCP tool: I still need the CLI myself, so my login sits on the same machine the agent runs on. Keeping them apart means building and maintaining a custom tool and a sandbox setup, and every user would have to repeat that for every agent tool they use.

The only reliable limit is one Railway enforces on the token itself.

Request

Tokens with chosen permissions, e.g.:

• Permissions: logs:read, deployments:read, variables:read (masked), etc.
• Scope: limited to a project and/or environment
• Works everywhere: honored by the CLI (RAILWAY_TOKEN), the API and the Railway MCP server

Then I could hand an agent a logs-only token and know it can't do anything else.

Or: read-only by default, with confirmation for anything that changes things

The CLI login is read-only by default. Changes (delete, deploy, reading unsealed variables, etc.) require an out-of-band confirmation, like a browser approval or passkey, that names the action: "Delete environment production?". It has to be enforced on Railway's servers, so the stored login can't be used to call the API directly. That way the same CLI works for me and for my agents, and only I can approve anything beyond reading.

Is something like this on the roadmap? And until then, is there a recommended way to do this?