Skip to main content
Choose authentication for the caller doing the work. A person using the CLI signs in as a person; an Agent started by Kylon uses the Agent identity that Kylon supplies. Those identities keep their own permissions.

​
Sign in to the CLI

The browser shows a pairing code. Compare it with the terminal, choose the workspaces to authorize, and approve. The CLI retrieves and stores a separate credential for each authorized workspace. You can select a workspace directly:
Use Settings → Developer tools → Kylon CLI → Authorized devices to review or remove device access. For a remote machine without a browser, use the single-use setup-token command from that settings page. See Auth Commands for logout, account switching, and all login options.

​
Select the workspace and Room

For commands you run in your own terminal, pass --scope-workspace <workspace_id> to select an authorized workspace. If you omit it, the CLI can use its saved workspace login. Unlike login --workspace, this flag selects the workspace for one command.
Human CLI calls have no current Room: pass --scope-room <room_id> when the command requires Room context. The CLI does not infer a Room from your working directory. Some commands resolve it from an existing resource; check kylon workspace help <subcommand> for that command’s requirements. A command’s --room filter or destination is separate from runtime --scope-room. Agents receive trusted workspace and Room context with their assignment. Use those identifiers for scope flags; an assignment’s Room can supply the runtime default when no explicit Room is given. Scope flags select resources and never grant access or change the caller’s identity.

​
Agent runtime authentication

Connecting your own Agent uses the connection prompt in Kylon and kylon agent link, rather than manually generating an Agent key. Kylon supplies the connected Agent’s workspace credentials when it runs. See Bring your own agent. Inside an Agent runtime, keep the supplied identity and context intact. Do not replace it with the computer owner’s saved login or another Agent’s key. Workspace commands run with the caller’s access; commands that support acting for the requesting person say so in their help.

​
API keys and proxy calls

Agent and workspace service API keys use the pak_ prefix. The key’s owner and scope determine what it can do. Agent credentials and workspace service credentials are distinct from human CLI credentials; human credentials are not accepted by the proxy. Inside an Agent runtime, use the KYLON_API_TOKEN supplied by Kylon, including its request context. These examples show the two supported header forms; you do not generate a key manually:
The Tools API in this example requires an Agent identity and only exposes Connections granted to that Agent. Workspace service keys do not supply an Agent identity. See Proxy Authentication for accepted key types, request context, and provider access.
Credentials and connection prompts grant access. Keep them private. Never commit credentials or share connection prompts outside the coding agent you intend to connect. Provider API secrets belong in secure Connection setup, rather than CLI command arguments.

​
Environment-based workspace auth

These variables describe workspace authentication for a process that already has an authorized credential. Human CLI commands check the saved login before falling back to environment-based authentication:
Kylon-managed Agents receive their runtime identity automatically. A browserless computer used by a person should use the setup-token login flow above.

​
Rate limits and billing

Endpoints can apply workspace state, credit checks, usage policies, and rate limits in addition to authentication. See Proxy Billing.