Como ativar MFA e proteger a conta de agentes no Tigy

Prepare a recuperação

Use um autenticador que você controla e defina onde guardar os códigos de recuperação com segurança. Não compartilhe uma conta administrativa entre pessoas para evitar convites. Cada responsável deve ter sua própria identificação e acesso apropriado.

Ative e confirme

Abra as configurações da conta e a seção de segurança. Inicie a configuração de autenticação em dois fatores, siga a instrução exibida e informe um código válido para confirmar. Adicionar a conta ao aplicativo sem confirmar o código não conclui a ativação.

Confira um novo acesso

Verifique o estado final antes de sair da conta e faça um novo login pelo método habitual. Complete a etapa adicional quando solicitada. Se o código falhar, confira a conta selecionada no autenticador e a sincronização do relógio do aparelho.

Separe conta de credenciais externas

O segundo fator protege o acesso humano. Credenciais de ferramentas autenticam o destino externo e precisam de armazenamento e revisão próprios. Mantenha segredos fora do prompt, de capturas e de tickets; ao pedir ajuda, descreva a etapa e o erro.

Revise após mudanças

Ao trocar responsáveis, revise membros e integrações vinculadas à conta. Para desativar o segundo fator, siga a ação das configurações e sua confirmação. Não envie códigos de recuperação a colegas como solução para um bloqueio de acesso.

O que a autenticação em dois fatores protege?

Ela acrescenta uma verificação ao acesso humano à conta que administra agentes. Adicionar a conta ao aplicativo autenticador não conclui a ativação: informe o código solicitado e confira o estado final. As permissões continuam determinando quais recursos essa identidade pode alterar.

Um código de login não substitui a credencial usada por uma ferramenta para chamar uma API. Revise chaves e credenciais separadamente, sobretudo ao mudar responsáveis. Não compartilhe códigos de recuperação para resolver acesso de colegas; cada pessoa deve usar sua própria conta e o convite apropriado.

Proteja a conta que pode mudar o atendimento

Uma conta que mantém agentes pode alterar instruções, fontes e ferramentas conforme suas permissões. Uma mudança indevida nessa configuração pode afetar mais que o painel: pode alterar o que o agente diz ou faz durante chamadas. A proteção do login, portanto, faz parte da manutenção do atendimento. Dois fatores adicionam uma etapa de autenticação, enquanto as permissões continuam definindo o alcance das ações disponíveis depois da entrada.

Em uma equipe fictícia, a pessoa que edita o agente tem acesso a uma ferramenta de agenda. Proteger essa identidade é relevante porque ela pode mudar a descrição e o uso da ferramenta. Ainda assim, ativar dois fatores não significa que deve receber administração de todos os recursos. Revise o trabalho necessário e o acesso efetivo. Autenticação e autorização respondem a perguntas diferentes: quem entrou e o que essa identidade pode fazer.

O procedimento documentado do Tigy começa nas configurações de segurança da conta. Inicie a configuração, adicione a conta ao autenticador pelas instruções exibidas, informe um código válido e confirme a ativação. Apenas adicionar a conta ao aplicativo não conclui o processo. Confira o estado final antes de sair. Essa verificação evita acreditar que a proteção está ativa quando uma etapa de confirmação permaneceu pendente.

Use uma conta e um dispositivo apropriados para a identidade que está configurando. Se várias contas aparecem no autenticador, verifique a entrada correta antes de digitar o código. Não compartilhe uma captura que contenha informações de configuração ou códigos para provar que a etapa ocorreu. Ao pedir ajuda, descreva a tela, o passo e o erro sem expor segredo.

O objetivo é manter uma identidade utilizável e protegida, com evidência de ativação concluída. Não transforme o processo em uma promessa de que toda integração ou dado ficou seguro automaticamente. Chaves, credenciais externas e permissões precisam de revisão própria, coordenada com a proteção da conta.

Prepare recuperação sem distribuir códigos à equipe

A documentação orienta guardar códigos de recuperação com segurança e separadamente da senha. Eles não devem ser enviados a outros membros do workspace para facilitar o suporte. Planeje a recuperação no contexto da identidade e do processo da organização, sem transformar códigos em uma credencial coletiva. Compartilhar acesso pessoal para evitar uma dificuldade de login cria um problema diferente do que a configuração pretendia resolver.

Em um exemplo fictício, a pessoa ativa dois fatores e descobre depois que depende de um único dispositivo para entrar. A preparação deveria ter incluído o armazenamento dos códigos conforme as instruções do produto e o processo interno. Não é necessário inventar um método de recuperação alternativo que a documentação não oferece. Use as opções reais e mantenha a informação protegida, com acesso coerente com sua finalidade.

Quando um código é rejeitado, a documentação recomenda verificar a conta escolhida e a sincronização de horário do dispositivo. Um código de outra entrada do autenticador não confirma acesso à conta atual. Descreva essas verificações sem pedir que a pessoa envie o código por mensagem. Se o problema continua, preserve a etapa e o erro para suporte, evitando publicar senha, código de autenticação ou material de recuperação.

Revise o processo quando a pessoa muda de dispositivo ou responsabilidade. A manutenção do atendimento não deveria depender de compartilhar sua senha para que um colega continue o trabalho. A equipe deve utilizar contas e permissões adequadas. Se a identidade possui integrações vinculadas, planeje sua continuidade separadamente da recuperação do login.

Uma preparação útil evita tanto perda de acesso quanto circulação desnecessária de segredos. O teste final deve confirmar que a pessoa consegue entrar pela forma habitual e concluir a etapa adicional quando solicitada. Não desative a proteção apenas porque alguém não sabe qual conta selecionar no autenticador; primeiro diagnostique a situação e siga o procedimento disponível para aquele caso.

Revise conta e credenciais externas separadamente

Dois fatores protegem o acesso interativo à conta conforme o processo do produto. Credenciais de serviços externos permitem que ferramentas acessem os sistemas configurados. Ativar a etapa adicional não deve ser interpretado como troca automática de todas essas credenciais ou como revisão de seu alcance. A documentação orienta conferir credenciais externas quando o acesso de alguém muda ou quando há suspeita de exposição.

Em uma operação fictícia, uma integração continua usando uma chave criada por uma pessoa que deixou a manutenção. Antes de retirar seu acesso, identifique as dependências e atribua um responsável pelo processo de atualização. Não cole a chave no prompt do agente nem em uma página pública para facilitar a transferência. Segredos devem permanecer no mecanismo apropriado de credenciais, conforme a configuração disponível e o processo da equipe.

Se há suspeita de exposição, preserve o contexto mínimo da investigação sem repetir o segredo em todos os relatos. Identifique a integração afetada, as capacidades envolvidas e as ações necessárias no sistema correspondente. A troca ou retirada deve considerar a continuidade: uma credencial removida pode interromper consultas e ações mesmo que o agente continue disponível para conversar. Teste as operações afetadas com dados apropriados depois do ajuste.

Revise também permissões de recurso. Uma identidade autenticada não precisa poder alterar tudo. Alinhe acesso ao trabalho, confira o resumo efetivo e valide a tarefa necessária. Se uma ação é rejeitada, investigue conta, workspace e recurso antes de ampliar o papel para administração. O problema pode estar no contexto ou na integração, e não na falta de um privilégio amplo.

Essas revisões se complementam. Proteção da conta reduz uma via de acesso indevido; controle de permissões limita ações; cuidado com credenciais externas mantém as integrações sob responsabilidade definida. Nenhuma configuração isolada representa todas as camadas. A equipe precisa saber qual controle mudou e qual evidência confirma que o atendimento continua funcionando dentro do alcance autorizado.

Verifique estado final e mantenha uma revisão prática

A conclusão da configuração deve ser observada no estado da conta. Depois de confirmar a ativação, confira o login pelo método habitual e a etapa adicional quando solicitada. Verifique também que a pessoa continua conseguindo executar seu trabalho no workspace. Um problema de permissão descoberto nessa verificação não deve ser atribuído automaticamente aos dois fatores: autenticação e acesso ao recurso continuam sendo decisões distintas.

Monte uma lista curta para manutenção: estado de ativação confirmado, recuperação preparada, papel apropriado e credenciais externas sob responsabilidade definida. Não é necessário reproduzir segredos nessa lista. Ela registra que as verificações ocorreram, não os valores utilizados para entrar. Se a equipe altera a forma de acesso ou muda responsáveis, revise os pontos afetados e preserve continuidade das integrações.

Teste situações de conta errada no autenticador, código rejeitado e ação de workspace indisponível. O diagnóstico deve apontar a próxima verificação concreta: identidade selecionada, horário do dispositivo, estado da ativação ou permissão sobre o recurso. Evite tentativas aleatórias de desativação ou concessão de administração sem entender a causa. Um procedimento claro reduz o tempo de suporte e a chance de ampliar acesso por engano.

Se a pessoa realmente precisa desativar dois fatores, a documentação orienta usar a ação nas configurações e concluir a confirmação exigida. A decisão deve seguir o processo da organização e o contexto real. Não ofereça a desativação como resposta automática a qualquer dificuldade. Primeiro determine se o problema é conta, código, dispositivo ou permissão, porque as soluções não são equivalentes.

Mantenha a revisão proporcional ao atendimento que a identidade administra. Quem pode mudar ferramentas de escrita exige atenção ao alcance da integração e às permissões; quem só revisa resultados ainda precisa proteger seu acesso. Uma rotina útil deixa a equipe com estado conhecido, recuperação preparada e responsabilidades claras. Essa base ajuda a manter o agente sem depender de contas compartilhadas, códigos enviados por mensagem ou suposições de que uma ativação incompleta já protege o login.