Access and security

An agent connected to the MCP server works with exactly the access of the credential its client sends: your own sign-in, or an API token from a service account. The server adds no access of its own.

What the server can reach

Each tool call sends requests to Telflo's public API, /api/v1/public, with your client's credential. The server has no other route into Telflo, so its access is the CLI's: a read-only token can read and validate but cannot push, test, or deploy. It has no shell or file access; other tools your client gives the agent, such as a terminal, run under the client's permissions.

The server keeps no session and stores no credential. The API checks the credential on every request, and the server also verifies a sign-in's signature and expiry before any tool runs.

Choose a credential

Signing in reaches every organization you belong to with your full role; a service-account token narrows that to one organization and, if you choose, to reading. Two ways to sign in compares them.

• Start with a Read token when an agent only needs to explore. It can call the 14 read-only tools and none of the 7 writes.
• Give each agent its own service account. Its changes are attributed to it, deleting the account cuts off that agent alone, and its token has its own rate limit. The service account recommendations apply too.

Approvals for writes

Your MCP client decides which calls run without asking you. It tells the 7 writes below from the 14 read-only tools by their annotations.

No tool deletes a configuration, version, fleet, deploy group, or token; some writes replace earlier state: push_configuration overwrites the latest version while it is a draft, deploy_configuration changes the version a deploy group runs, and run_pipeline_test with save_rules replaces the rules saved earlier through the API for that pipeline. Keep your client asking before those three calls, and before get_fleet_install_command, which returns a secret.

The Authorize page

Signing in opens the Authorize page, described in Connect a client. Client registration is open, so any application can register under any name, including "Claude", and the page shows no logo for that reason. The host under You will be sent back to is what an application cannot disguise, because your decision is delivered there. Select Deny unless it belongs to the client you just started connecting.

The scope list does not limit the client. Allowing gives it the same access you have when signed in to Telflo, and a refresh token to renew it, so treat what the client stores as a secret. The page redirects only to http or https addresses, and other sites cannot frame it to hide its Allow button.

Secrets in transcripts

Everything a tool returns joins the agent's conversation, which your client keeps, may write to logs, and sends to its model. Keep credentials out of your configurations with ${env:NAME} references, as Tokens & security recommends.

The tool's description tells the agent to hand the command to the operator who runs it and keep it out of other tools and logs; keep it out of tickets and chats yourself. The description also says runtime secrets go in env, which is written into the command or the linux bundle, so tell the agent to leave secret values out and set them on the host.

If a command leaks, revoke its Quick Deploy link, when it has one, under Install Links on the fleet's Tokens tab to stop further downloads. The install token cannot be rotated or revoked, so if a docker or linux command leaked, or someone else downloaded the values.yaml, re-create the fleet. See Revoke a token.

Revoke access

Signing out of Telflo in your browser signs your account out everywhere, including the MCP clients you signed in; each one stops working when its current access token expires and must sign in again. No Telflo page lists the clients you allowed or withdraws access from one.