10. Permissões e segurança

Três níveis de permissão

1. Auto-aprovadas — read_file, list_directory, search_files, glob, get_diagnostics, read_dev_server_logs, etc. Não interrompem o fluxo.

2. Aprovação inline (diff) — write_file, edit_file, create_file. Vês o diff inline e clicas Yes/No (ou aceitas tudo de uma só vez se ligares "Auto-approve diffs").

3. Prompt forçado — comandos perigosos (rm -rf, git push --force, chmod, etc.), ficheiros sensíveis, e acções do browser tool. Sempre pedem permissão, mesmo que tenhas "Approve all" ligado.

Permissões para browser (`/te2e`)

No /te2e, as acções do browser (navegar, clicar, escrever) seguem o sistema de permissões normal e pedem aprovação como qualquer outra ferramenta sensível. A excepção é a leitura do estado da página — equivalente a inspeccionar o DOM no DevTools, é puramente read-only e não pede aprovação.

Sandbox

A lista de comandos perigosos é gerível em Settings → Sandbox. Podes:

Bloquear completamente (o agente não consegue correr)
Sempre pedir (default)
Ajustar conforme o teu nível de conforto

Ficheiros sensíveis

.env, .env.*, credentials.json, serviceAccountKey.json, e ficheiros com nomes contendo "secret", "token", "key" — bloqueados completamente. O agente nunca os lê, escreve, edita ou apaga. Não há override possível: nem o user a aprovar manualmente, nem Approve all, nem nada.

Como o agente pede credenciais (formulário seguro)

Como o agente não consegue ler o .env, foi desenhado um flow específico para quando precisa de credenciais novas (API keys, passwords, secrets) que o user tem de fornecer.

Tool `request_credentials`

Em vez de pedir "cola aqui a chave da Stripe" no chat (onde ficaria registada para sempre), o agente invoca a tool request_credentials que renderiza um cartão com formulário no chat.

O cartão tem:

Nome do serviço (ex: "Stripe API")
Campos (um por credencial):
id — nome da variável de ambiente (ex: STRIPE_SECRET_KEY). Validado: tem de match ^[A-Z_][A-Z0-9_]*$
label — texto humano (ex: "Secret Key")
type — password (mascarado, default) ou text
required — boolean
helperText — instrução opcional (ex: "Encontra em Stripe Dashboard → Developers → API keys")

O fluxo

Agente: invoca request_credentials
   ↓
TM Code: renderiza form no chat com campos password
   ↓
User: preenche os valores (visíveis no form, nunca aparecem na transcript)
   ↓
User: clica "Submit"
   ↓
TM Code: chama write_env_vars (Rust) que grava no .env do projecto
   ↓
Agente: recebe APENAS confirmação "STRIPE_SECRET_KEY: written, STRIPE_PUBLISHABLE_KEY: written"
   ↓
Agente: continua a tarefa (referencia process.env.STRIPE_SECRET_KEY no código)

O agente nunca vê os valores. Só sabe:

Que keys foram pedidas
Confirmação que foram escritas
Os nomes (não os values)

A transcript do chat não regista os valores. Mesmo se exportares a sessão ou enviares um issue report, os secrets ficam onde devem ficar: no .env local, fora do git.

Ferramentas afins

provision_auth — caso especial para auth GIP/Firebase. O TM Code platform gere o tenant Firebase do lado dele; o agente invoca provision_auth(provider: 'gip') e o backend cria/devolve o tenant + escreve as credenciais públicas (VITE_FIREBASE_API_KEY, VITE_FIREBASE_AUTH_DOMAIN, VITE_FIREBASE_PROJECT_ID, VITE_FIREBASE_TENANT_ID, GIP_TENANT_ID, GCP_PROJECT_ID) no .env do projecto. Service accounts privados (que dariam admin) ficam só no worker do TM Code — o user nunca os tem, o agente nunca os pede.

write_env_vars — comando Rust low-level que grava chaves no .env (criando o ficheiro se não existir, preservando comentários e ordem das chaves existentes). Não é exposto directamente ao agente; é chamado pelo backend do TM Code via request_credentials e provision_auth.

Como funciona em prática

Quando pedes "adiciona pagamentos com Stripe":

1. Agente analisa o projecto, decide que precisa de duas keys

2. Invoca request_credentials com serviceName: "Stripe", fields: [STRIPE_SECRET_KEY, STRIPE_PUBLISHABLE_KEY]

3. Vês o cartão no chat — preenches as keys (geralmente copy-paste do dashboard do Stripe)

4. Clica em "Submit"

5. As keys são escritas em .env

6. O agente continua a implementar Stripe, referenciando process.env.STRIPE_SECRET_KEY no código que escreve

Em momento nenhum os valores aparecem em texto livre, no histórico do chat, ou são enviados ao modelo.

← Toda a documentação · versão markdown