Controle de acesso de agentes de suporte: funções, permissões e o assento da IA

O que o controle de acesso de agentes de suporte abrange

A maioria das equipes pensa em controle de acesso como "agente ou administrador". Na prática são quatro camadas, e uma brecha em qualquer uma desfaz as outras três.

Sou o Rama e construo as integrações de helpdesk da eesel, então passo boa parte da semana do outro lado destas telas de permissão. Toda vez que a eesel se conecta a um helpdesk, precisa pedir escopos e depois viver dentro da função de um agente real. No Zendesk, por exemplo, as respostas da eesel são publicadas como o usuário do Zendesk que aprovou a conexão, então a função dessa pessoa no Zendesk é o teto rígido do que a IA pode fazer. Essa é a lente que uso o tempo todo: controle de acesso trata tanto dos assentos que as pessoas esquecem quanto dos que configuram no primeiro dia.

Se você também separa clientes ou marcas, a camada de visibilidade se sobrepõe a suporte ao cliente multimarca e bases de conhecimento por cliente, que não vou repetir aqui.

Por que escopo de tickets não é o mesmo que controle de acesso

O escopo de tickets é a configuração a que a maioria se refere quando diz "os agentes só veem os próprios tickets". No Zendesk, as opções são todos os tickets, tickets dos grupos do agente, tickets da organização dele ou somente atribuídos. O Freshdesk oferece todos, por grupo ou atribuídos a partir do Growth.

Este é o tipo de equipe que precisa disso, num tópico do r/Zendesk sobre separar divisões:

"the agents would belong to different business divisions under the same overall company. They'd work on tickets that employees submit with sensitive data so this is why we want the agents in one division not to have access to see another agent group's tickets and so on"

u/Quirkyordinaryy, r/Zendesk, Reddit

O escopo cuida da porta da frente. A documentação dos fornecedores registra pelo menos três portas laterais:

• CCs. O Zendesk diz que colocar um agente em CC, inclusive light agents, envia a ele por e-mail todas as atualizações públicas e privadas, independentemente do acesso ao ticket (funções padrão do Zendesk). Um único CC num ticket sensível e a configuração de escopo deixa de importar para aquela conversa.
• Administradores. Administradores veem tudo. O Zoho Desk diz isso claramente: mesmo com o compartilhamento definido como Privado, "support admins can view all the tickets within a department" (regras de compartilhamento de dados do Zoho). Ou seja, a lista de administradores faz parte da sua política de visibilidade, quer você tenha planejado assim ou não.
• Rascunhos de IA. O auto assist do Zendesk "may generate text replies based on that content for agents and end users who don't belong to the related user segment". Em outras palavras, conteúdo restrito da central de ajuda pode chegar a um agente que não conseguiria abrir o artigo. Por padrão, todo grupo tem auto assist (configuração do auto assist).

Dois helpdesks são mais diretos sobre os limites. O Help Scout limita por caixa de entrada e a documentação diz "There is no method to restrict individual conversations" (funções do Help Scout). O Gorgias dá a todas as funções, inclusive Observer, a permissão "View tickets" e uma visualização padrão de todos os tickets abertos, e não documenta nenhum bloqueio rígido para abrir um ticket (permissões de usuário do Gorgias). Nenhum dos dois está errado para uma equipe de uma só marca. Apenas significam que a separação precisa vir de caixas de entrada ou contas separadas, não de uma função.

O que cada helpdesk permite controlar

Esta é a comparação lado a lado que eu gostaria de ter tido na primeira vez que mapeei isso. Os preços são por agente ao mês, conforme a página de preços de cada fornecedor em outubro de 2026, com cobrança anual onde a página mostra as duas.

Fontes: Zendesk, Freshdesk, Gorgias, Help Scout, Front, Zoho Desk, HubSpot.

Algumas células merecem uma frase. Zendesk e Zoho Desk incluem restrições de IP em todos os planos, e no Zendesk agentes e administradores não conseguem contorná-las (restrições de IP do Zendesk). O log de auditoria do Front funciona em todos os planos com 365 dias de histórico e também registra alterações feitas pelo Admin Copilot, pela API e por apps (log de auditoria do Front), o que é incomumente generoso. E o Zendesk no Enterprise elimina por completo a função de agente padrão, então o acesso de cada agente vem de uma função personalizada, com limite de 197 por conta.

O conjunto de permissões personalizado do Front é uma boa imagem do que é "privilégio mínimo" no nível do botão. O próprio exemplo do Front é deixar estagiários redigirem em caixas de entrada compartilhadas com "Send messages" desativado até serem treinados.

Para o detalhe por fornecedor, meu guia de funções do Zendesk percorre a lista completa de permissões, e a versão do Freshdesk cobre os escopos. O Gorgias também tem seu próprio passo a passo de funções.

Quanto custa o privilégio mínimo

O padrão da tabela é que funções de granularidade fina são um recurso dos planos mais altos. Aqui está onde as funções personalizadas são liberadas pela primeira vez em cada helpdesk.

Um consultor de Zendesk no mesmo tópico do r/Zendesk resumiu o que isso significa nos planos mais baixos:

"Groups (even normal) can do this. As long as agents access is set to "Only tickets in their group". Admins will be able to always see all tickets but agents get locked down as long as Access is set that way. If in Enterprise custom roles is how you handle this."

u/TOOtall_G, r/Zendesk, Reddit

O Front ouve essa reclamação há anos. Uma avaliação da Capterra de 2022 (o preço citado é da época, não de hoje) disse assim:

"basic features like a user and team management are exclusive to the highest tier. For this even managing just a few users and their permission and settings is a real pain as long as you're not willing to upgread to the highest tier"

Verified Reviewer, CPO, Food & Beverages, Capterra

Os controles de privacidade custam mais. O mascaramento de dados do Zendesk, que esconde nomes, e-mails e telefones de usuários finais de uma função, está no complemento Advanced Data Privacy and Protection, vendido apenas para planos Enterprise por um preço não divulgado (Zendesk ADPP). O mesmo complemento traz o log de acesso, que registra quem viu quais tickets por 90 dias.

Minha opinião sincera: se permissões por função são um requisito indispensável e você não tem verba para o Zendesk Enterprise, Freshdesk Pro e Zoho Desk Professional são as versões completas mais baratas deste conjunto. Se você já usa o Zendesk no Suite Professional (US$ 115), grupos com escopo somente atribuídos, uma lista curta de administradores e restrições de IP levam você bem longe. Confira meus detalhamentos de preços do Zendesk e preços do Freshdesk antes de fazer upgrade só por causa das funções.

As funções que eu configuraria para uma equipe de suporte típica

A maioria das equipes precisa de cinco formatos de acesso, não de quinze. Este é o esquema do qual eu partiria.

A linha do contratado é a que eu mais caprichava. Depois que a Coinbase revelou em maio de 2025 que funcionários de suporte no exterior foram subornados para extrair dados de clientes, o tópico do Hacker News voltava sempre ao mesmo princípio:

"That's not how front line support agent access should work. You get access based on active cases you are working on, not the keys to the kingdom because you might need to support a member at some future point in time."

lavezzi, Hacker News

Outro comentarista, que construiu um painel de administração para uma empresa de pagamentos PCI Level 1, descreveu os controles que adicionaram ao contratar fora dos EUA: "logging, monitoring and also rate-limiting (ask for manager to approve if more than 5 full details requests, etc.)" (vasusen, Hacker News). Essa última parte, aprovação a partir de um limite, é o mesmo padrão a que volto com a IA. Se você trabalha com um BPO, meus guias sobre terceirizar o atendimento ao cliente e transferência de conhecimento para o suporte offshore cobrem o resto da configuração.

Para a linha do assento leve, escolha o assento de leitura e comentário mais barato que seu helpdesk oferecer. O Zendesk inclui até 100 light agents no Suite Professional (assentos de light agent), os colaboradores do Freshdesk não podem responder publicamente nem editar propriedades do ticket (colaboradores do Freshdesk) e os assentos somente leitura do HubSpot são grátis e ilimitados nos planos pagos (assentos do HubSpot).

Engenheiros e o pessoal de finanças que só precisam ler uma conversa e deixar uma nota não precisam de uma licença de agente completa, como abordei em escalonamento de suporte entre equipes.

Desligamento: onde o acesso permanece

O controle de acesso costuma falhar na saída, não na entrada. Todo helpdesk deixa você remover um usuário. O que muda é o que acontece com os tickets dele, as automações dele e a sua fatura.

Fontes: Zendesk, Freshdesk, Gorgias, Help Scout, Front, Zoho Desk, HubSpot.

Vale conhecer três armadilhas antes do último dia de alguém:

• A ordem importa no Help Scout. Para passar as conversas de quem sai a uma pessoa específica, você executa um Workflow antes, porque "There is no way to do this after the user has been deleted" (Help Scout).
• As integrações quebram junto com a pessoa. O Zoho Desk diz que integrações configuradas por um agente desativado param de funcionar até um administrador autorizá-las de novo, e o Zendesk avisa que apps configurados com as credenciais de quem saiu podem quebrar. Saiba sempre com o login de quem suas integrações rodam, inclusive a sua IA.
• Os dados vão com eles. Rebaixar um agente do Zendesk apaga os dados de CSAT e as macros pessoais dele, e excluir um usuário do Gorgias apaga as estatísticas dele. Exporte antes o que precisar.

A falha mais discreta é que ninguém lembra como as permissões foram configuradas. Um usuário do Zendesk postou isto em abril de 2026:

"We had some turnover in IT so no one who set up Zendesk/my account for our team are here still and I can't figure out how to add it as an option for them."

u/Accountant8622, r/Zendesk, Reddit

Documente a configuração de funções e leia seu log de auditoria uma vez por trimestre. O Zendesk mantém o log indefinidamente no Enterprise, com autor, endereço IP e tipo de atividade de cada alteração (log de auditoria do Zendesk). Meu guia do log de auditoria do Zendesk traz a versão campo a campo.

No Gorgias, o log de auditoria guarda 12 meses de eventos. Para contratações sazonais em assentos temporários, meu post sobre integração de suporte sazonal cobre as regras de cada helpdesk.

Seu agente de IA também precisa de uma função

Esta é a parte que a maioria das revisões de acesso pula. Um agente de suporte de IA lê tickets, pesquisa sua base de conhecimento e, em muitas configurações, responde, etiqueta, fecha e reembolsa. É um membro da equipe com as mãos mais rápidas do prédio, e muitas vezes é configurado por quem tinha permissão de administrador naquela tarde.

A documentação dos fornecedores mostra como isso é desigual hoje:

• Zendesk: qualquer administrador do Support é, por padrão, administrador de cliente dos agentes de IA (acesso a agentes de IA do Zendesk). O agente de IA voltado ao cliente respeita os segmentos de usuários, mas o auto assist do lado do agente não, como vimos acima.
• Freshdesk: criar agentes de IA exige acesso de administrador, e o agente de IA só aprende com artigos visíveis para todos os usuários, então o conteúdo restrito fica totalmente de fora (fontes de conhecimento do Freshdesk).
• Gorgias: somente Leads e Admins gerenciam o AI Agent, mas todas as funções veem as respostas dele (permissões do Gorgias).
• HubSpot: o agente de cliente precisa da permissão "Customer agent editor", e depois de criado "it can't be deleted", só pode ser pausado (agente de cliente do HubSpot).
• Front: as configurações de IA vêm somente com a predefinição de administrador do workspace, não como permissão separada (grupos de colegas do Front).

Nenhum dos sete fornecedores que verifiquei documenta se o agente de IA respeita o escopo de tickets de um agente individual. Então a suposição mais segura é que a IA vê o que a conexão dela vê, e você controla isso na conexão.

Um bom conselho veio de um tópico do r/AI_Agents sobre dar a agentes acesso a dados de clientes:

"You should treat an agent like you would any user: limit access via end points and only give them access to the endpoints they absolutely need. So avoid full/broad access as much as possible."

u/JustKiddingDude, r/AI_Agents, Reddit

Isso combina com o que ouço dos compradores. Um líder de CX de uma marca DTC de suplementos no Gorgias e Shopify, com cerca de 7,000 tickets por mês, disse com clareza numa chamada de vendas com a eesel:

"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Por isso penso no acesso de um agente de IA como três controles separados e depois um nível de permissão para cada ação.

1. Conhecimento. Conecte apenas as fontes de que ele precisa. Se os agentes de uma divisão não veem os tickets de outra, a IA que atende essa divisão também não deveria aprender com eles.
2. Ações. Liste todas as ações e defina cada uma: automática, requer aprovação ou desligada. Consultar um pedido tem baixo risco. Enviar uma resposta ou emitir um reembolso não tem, pelo menos até você ver que ela acerta.
3. Rede. Se a IA chama suas próprias APIs, permita apenas os domínios de que ela precisa e mantenha as credenciais fora das mãos do modelo.

É assim que o colega de IA para helpdesk da eesel é construído. Cada ação é definida por agente como Auto, Requer aprovação ou Desativado, e as aprovações nunca são executadas sozinhas após um tempo limite. Somente Owners e Editors do workspace podem aprovar, e um Viewer pode ler o trabalho do agente, mas o agente não executa ações de escrita em nome dele (funções de conta da eesel). As chamadas de saída só alcançam os domínios que você adiciona em Network Access, e o agente "only ever sees the name of the header, never its value", então as chaves de API ficam fora do modelo.

As mesmas permissões valem no terminal. A CLI da eesel opera o mesmo agente do painel, e eesel integrations zendesk actions imprime todas as ações do Zendesk com a configuração de aprovação, então você audita as permissões de um agente com um comando ou pede a um agente de programação como o Claude Code que faça isso. Escritas pela CLI seguem as mesmas regras, e as escritas de um Viewer ficam sempre retidas para um Editor. --dry-run mostra a chamada exata que uma escrita faria antes de qualquer coisa ser enviada.

A documentação da eesel recomenda começar supervisionado: respostas e tudo o que for irreversível em Requer aprovação, reembolsos e cancelamentos atrás de aprovação para sempre. A maioria das equipes começa com notas internas e depois entrega mais à medida que o agente se prova, o mesmo caminho de um novo contratado. Se você quer o lado humano desse caminho, meu guia sobre como integrar um agente de suporte de IA o percorre, e escalonamento por IA cobre as regras de repasse.

Uma ressalva honesta do lado da eesel: a remoção de PII roda nos tickets antigos antes de serem indexados, mas quando o agente busca um ticket ao vivo do Zendesk para redigir uma resposta, o conteúdo bruto do ticket chega ao modelo. Se mascarar números de cartão nesse ponto é indispensável, combine a eesel com a própria redação do seu helpdesk, como a redação de tickets do Zendesk.

Uma lista de verificação trimestral de revisão de acesso

O acesso vai se desviando. As pessoas mudam de equipe, os contratados terminam e alguém ganha permissão de administrador "só por esta tarde". Eu faria isto todo trimestre:

1. Conte seus administradores. Dois bastam para a maioria das equipes. Cada administrador extra vê todos os tickets.
2. Compare os assentos com a lista de pessoas. Quem saiu e ainda tem um assento é ao mesmo tempo uma brecha de segurança e um item de custo, especialmente no Zendesk, Front e Zoho Desk, onde o assento continua sendo cobrado.
3. Verifique o escopo dos assentos de contratados e terceirizados. Somente atribuídos ou um grupo, sem exportação.
4. Leia o log de auditoria em busca de mudanças de função, exportações e logins de novos endereços IP.
5. Revise seus agentes de IA como qualquer outro assento. Quais fontes, quais ações em Auto, com o login de quem a conexão roda. Faça as mesmas perguntas à sua configuração de IA para solicitações de acesso a sistemas, se tiver uma.

Se você está reforçando a conformidade ao mesmo tempo, minha lista sobre SOC 2 e GDPR para chatbots de suporte e a visão geral de segurança do Zendesk são boas próximas leituras.

Experimente a eesel como colega de IA com escopo definido

Se o seu helpdesk é Zendesk, Freshdesk, Gorgias, Help Scout ou Front e o assento da IA é aquele de que você tem menos certeza, o colega de IA para helpdesk da eesel foi feito para isso. Ele entra na sua fila atual pela integração com o Zendesk (ou Freshdesk e Gorgias), lê apenas as fontes que você conectar e executa apenas as ações que você ativar. Conectar uma ferramenta não muda nada por si só: nenhuma automação é ativada e nenhuma resposta é enviada até você adicionar um gatilho.

Todo ticket em que ela mexe aparece em Activity com o que pesquisou, o que fez, quem aprovou e por quê, e antes de entrar no ar a habilidade de simulação reproduz seus tickets antigos reais para que você veja as respostas antes. Os preços incluem agentes e assentos ilimitados em todos os planos, começando grátis com 100 créditos e depois a partir de $299 por mês por 500 créditos, então adicionar revisores para observar a IA não custa uma licença para cada um. O que ela ainda não é: certificada SOC 2 Type II (isso está em andamento, conforme a página de segurança), e o SSO com 2FA obrigatório é um complemento a partir de $199 por mês. Se você quer uma IA que comece pelas notas internas e conquiste mais espaço, experimente a eesel grátis.