Quando a pessoa que criou a integração sai da agência: quem é dono das suas automações
Automações de agência costumam nascer no login de uma pessoa. Quando ela sai, o fluxo quebra — ou pior, continua funcionando com acesso que ninguém controla. Como organizar chaves, webhooks e permissões antes do problema aparecer.
Toda agência que automatiza algo passa pelo mesmo ponto. Alguém da equipe monta um fluxo no N8N que puxa os números das campanhas e joga numa planilha. Funciona. Mês seguinte, o fluxo ganha um ramo que avisa no Slack quando o custo por lead sobe. Funciona também. Seis meses depois existem onze automações rodando e ninguém sabe exatamente com qual credencial cada uma se autentica.
O problema aparece de duas formas, e as duas doem.
Na primeira, a pessoa que criou tudo aquilo sai da agência. O acesso dela é revogado no dia seguinte, como manda o processo, e metade dos fluxos para de funcionar sem aviso. Ninguém percebe até o cliente perguntar por que a planilha parou no dia 3.
Na segunda, pior, o acesso não é revogado — porque a credencial é um token solto num nó de automação, e não um login que o RH sabe desligar. A pessoa saiu há oito meses e uma chave criada por ela continua lendo dados de cliente todos os dias. Se você tem automações rodando hoje, vale olhar onde elas se autenticam. Em plataformas que tratam isso bem — é o caso de API, webhooks e MCP na Blocos —, a chave carrega a identidade de quem a criou, e desligar a pessoa desliga o acesso. Mas isso é uma decisão de arquitetura, não um padrão do mercado.
Automação não é exceção ao controle de acesso
Agência média já tem um processo razoável para contas de anúncio: entra alguém, recebe acesso; sai alguém, perde acesso. O ponto cego é que automação parece uma categoria diferente de coisa. Não é um login, é "uma integração". Então ela escapa da checklist de offboarding.
Mas uma chave de API é um login. Com uma diferença relevante: ela não dorme, não tira férias e não pede confirmação em duas etapas. Se ela tem permissão de escrita, ela pode pausar campanha, alterar orçamento, mudar configuração. Se ela tem permissão de leitura, ela carrega dados de todos os clientes que a pessoa enxergava.
A pergunta prática não é "a automação é segura?". É:
Em nome de quem essa chave age?
O que ela pode fazer além do que o fluxo usa hoje?
Quem na agência saberia dizer que ela existe, se eu perguntar amanhã?
Se você não consegue responder as três sobre cada integração ativa, o risco não é teórico.
O princípio simples: a chave herda, não amplia
A regra que resolve a maior parte dos casos é a mais chata de todas: uma credencial de automação nunca deve poder fazer mais do que a pessoa que a criou.
Parece óbvio, mas o padrão oposto é comum. Alguém precisa que um fluxo leia dados de um cliente específico, o acesso disponível é um token administrativo global, e o fluxo nasce com permissão para o mundo inteiro. Funciona na primeira tentativa, o que é exatamente o motivo pelo qual ninguém volta para ajustar.
Duas práticas tornam isso administrável:
Separe leitura de escrita. A maioria dos fluxos de agência só lê. Relatório, alerta, planilha, dashboard — tudo leitura. Escrita é a minoria, e é onde mora o estrago possível. Chaves diferentes para finalidades diferentes significam que uma credencial exposta num log de automação não vira capacidade de mexer em campanha.
Amarre a chave a um cargo, não a uma vontade. Se o analista júnior vê três clientes, a chave que ele cria vê três clientes. Isso evita a escalada silenciosa de privilégio, onde a automação se torna o caminho mais fácil para ver o que você não deveria ver. Na Blocos, as chaves saem com as permissões do cargo de quem as gerou, o que torna a herança o comportamento padrão em vez de uma disciplina que alguém precisa lembrar de aplicar.
Webhook ou consulta periódica: a escolha muda o risco
Existe uma decisão técnica aqui com consequência operacional direta.
Se a sua automação pergunta à plataforma "mudou algo?" a cada cinco minutos, você tem uma credencial em uso constante, milhares de chamadas por mês e um fluxo que descobre tarde o que aconteceu. É o padrão de quem começou pela API e nunca revisitou.
Se a plataforma avisa a sua automação quando algo acontece, a direção se inverte. O fluxo fica parado até existir motivo para rodar. Menos chamadas, menos superfície, e o evento chega perto do momento em que ocorreu — o que importa quando o assunto é orçamento estourando ou campanha reprovada.
Webhook não substitui API. Ele dispara o aviso; você ainda consulta para buscar o detalhe. Mas inverter quem inicia a conversa reduz muito o volume de credencial circulando por aí.
O detalhe que todo mundo esquece
Um endpoint de webhook é uma porta pública na sua automação. Valide a origem do evento, não confie em qualquer POST que chegue na URL. N8N, Make e Zapier todos oferecem autenticação no nó de entrada — e quase ninguém liga.
Registro de chamadas é o que transforma suspeita em resposta
Quando algo estranho acontece — um número que não bate, uma campanha que mudou sem explicação, um cliente perguntando quem acessou o quê — a diferença entre cinco minutos e cinco dias de investigação é ter registro.
O que você quer poder ver: qual chave chamou, o que pediu, quando, e se deu certo. A Blocos mantém 30 dias de registro das chamadas, o que cobre bem o cenário mais comum: você descobre o problema no fechamento do mês e precisa olhar para trás.
Trinta dias também é o horizonte de uma faxina trimestral útil. Liste as chaves ativas, cruze com o registro e pergunte: essa aqui chamou algo nos últimos trinta dias? Se não, ela não está sustentando nenhum fluxo — está só existindo. Revogue.
MCP mudou quem precisa saber de API
Até pouco tempo atrás, automação era assunto de quem programa ou de quem domina N8N. O Model Context Protocol muda a entrada: em vez de montar nós, você conecta o assistente à plataforma e pede em linguagem natural o que precisa.
Isso é ótimo para a operação. Um gestor pede "me traz o custo por resultado dos últimos 14 dias dessas três contas" e recebe, sem abrir dashboard e sem pedir para o time técnico montar nada. Na Blocos é 1 endereço para conectar o Claude — e o mesmo caminho serve para ChatGPT, Cursor e o próprio N8N.
E é justamente por ser fácil que a governança importa mais, não menos. Quando conectar leva dois minutos, muita gente conecta. Se a credencial do assistente herda as permissões de quem a criou, isso é saudável: cada um conversa com o recorte de dados que já podia ver. Se ela herda um token administrativo, você acabou de dar acesso irrestrito a uma interface de conversa.
Um checklist curto para fazer essa semana
Não precisa de projeto. Precisa de uma hora:
Liste as integrações ativas. Onde elas rodam, o que fazem, quem montou.
Identifique a credencial de cada uma. Se você não sabe de quem é a chave, essa é a primeira a resolver.
Rebaixe o que for possível. Fluxo que só lê não precisa de chave de escrita.
Adicione "revogar chaves de API" ao offboarding. Ao lado de e-mail e acesso às contas de anúncio.
Marque uma revisão trimestral. Chave sem uso recente sai.
Documente num lugar só. Uma página com nome do fluxo, finalidade, credencial e responsável resolve 90% das dúvidas futuras.
O objetivo não é burocratizar automação — é o contrário. Agência que sabe onde estão suas integrações automatiza mais, porque não tem medo de criar a próxima. Quem não sabe acaba paralisado no dia em que alguém pede um fluxo novo e ninguém lembra como o antigo funciona.
Se quiser ver como esse desenho fica na prática — chaves com permissão herdada, webhooks avisando a sua automação e MCP para executar pela conversa —, os detalhes estão em API, webhooks e MCP.
