A IA Agêntica Está Quebrando as Premissas de Confiança Humana da Segurança
- Aisha Washington

- 12 de ago.
- 15 min de leitura
A IA agêntica chegou ao Google News com um conflito contundente: sistemas autônomos agora podem agir mais rápido do que os controles centrados em humanos projetados para contê-los.
Uma análise recente da Forbes argumenta que os programas de segurança ainda pressupõem que as pessoas iniciam ações importantes e permanecem responsáveis por elas. Os agentes de IA enfraquecem ambas as premissas. Eles podem selecionar ferramentas, recuperar dados, chamar APIs e concluir tarefas de várias etapas com envolvimento humano limitado.
O artigo reflete um debate mais amplo sobre segurança, não uma violação isolada ou anúncio de produto. Microsoft, Google Cloud e grupos de padrões de segurança estão desenvolvendo controles para agentes como atores digitais distintos. Esse trabalho desafia um modelo mais antigo, construído em torno de usuários humanos, aplicações previsíveis e permissões relativamente estáveis.
Essa tensão importa porque um agente não precisa ter intenção maliciosa para causar danos. Uma instrução comprometida, permissão excessiva, memória contaminada ou plano equivocado pode produzir uma sequência prejudicial de ações legítimas.
O embate central, portanto, é autonomia versus controle centrado em humanos. As empresas querem agentes capazes de concluir o trabalho sem aprovação constante. As equipes de segurança precisam de evidências de que cada identidade, permissão, chamada de ferramenta e ação consequente permanece restrita.
A solução não é simplesmente colocar outra pessoa ao lado de cada fluxo de trabalho. Essa abordagem elimina grande parte da velocidade que as empresas esperam de sistemas autônomos. Em vez disso, a segurança deve se aproximar do caminho de execução do agente, onde o software pode aplicar limites antes que uma ação ocorra.
Por Que a Segurança da IA Agêntica Chegou ao Google News
A notícia não é que a IA pode cometer erros. A mudança é que esses erros agora podem alcançar sistemas reais e desencadear ações reais.
A IA generativa tradicional normalmente espera que uma pessoa envie um prompt. Ela retorna texto, uma imagem ou código para que alguém revise. Essa interação cria um ponto de controle evidente entre a saída do modelo e o impacto operacional.
A IA agêntica remove ou reduz esse ponto de controle. Um agente de IA é um sistema que busca um objetivo por meio de planejamento, uso de ferramentas e ações repetidas. Ele pode reunir informações, escolher um caminho e se ajustar após uma etapa malsucedida.
Essa capacidade muda o cálculo de risco. Um chatbot pode recomendar a exclusão de um banco de dados de produção. Um agente com privilégios excessivos pode tentar a exclusão, repetir a tentativa após um erro e procurar outra credencial.
A mesma distinção se aplica ao trabalho comum de escritório. Um assistente que redige um e-mail cria um artefato passível de revisão. Um agente que encontra destinatários, anexa documentos internos e envia a mensagem pode expor informações antes que alguém perceba.
Um argumento de segurança da Forbes descreve agentes atravessando ambientes, identidades e limites de dados que as equipes de segurança normalmente gerenciam separadamente. O autor, o executivo da Cyera Jason Clark, apresenta isso como um problema estrutural para os controles existentes.
Essa fonte é uma contribuição do Forbes Technology Council, não uma reportagem investigativa independente. Suas afirmações devem ser lidas como a análise de um executivo do setor. Ainda assim, sua preocupação central aparece em pesquisas independentes, orientações de fornecedores e padrões técnicos emergentes.
A mudança importante é a autoridade delegada. Um agente pode operar por meio da identidade de um usuário, de uma conta de serviço ou de sua própria credencial. Cada modelo cria questões difíceis sobre responsabilidade e escopo de permissões.
Usar a conta de um usuário dá ao agente todos os direitos atribuídos a essa pessoa. Contas de serviço compartilhadas dificultam a atribuição. Uma identidade separada para o agente melhora a visibilidade, mas somente se os sistemas puderem avaliar continuamente seu contexto.
Os agentes também criam cadeias mais longas de causalidade. Um agente pode pedir a outro que pesquise registros. O segundo pode chamar uma ferramenta de terceiros, que recupera dados e os transmite a outro modelo.
Cada transferência cria outra decisão de confiança. As equipes de segurança devem determinar quem iniciou a tarefa, qual agente agiu, qual autoridade recebeu e se essa autoridade permaneceu válida.
A exposição no Google News dá a essa questão maior visibilidade, mas a agregação não é o evento em si. O evento real é a convergência entre implantação e evidências de segurança. Os agentes estão entrando nos fluxos de trabalho enquanto os controles de identidade continuam orientados a humanos e cargas de trabalho estáticas.
Essa lacuna transforma uma discussão de arquitetura em uma questão operacional. Os líderes de segurança agora precisam governar ações produzidas por sistemas que interpretam objetivos em vez de seguir uma única sequência fixa.
A Segurança Ainda Pressupõe Que Há um Humano ao Teclado
A maioria dos sistemas de acesso responde se uma identidade tem permissão, mas os agentes os forçam a perguntar se esta ação ainda se encaixa no propósito delegado.
A segurança centrada em humanos se baseia em várias premissas práticas. Uma pessoa faz login, entende as regras organizacionais e executa ações em um ritmo aproximadamente humano. Investigadores podem questionar essa pessoa quando a atividade parece incomum.
Nenhuma dessas premissas se transfere de forma limpa para um agente. Um agente pode tomar milhares de decisões sem fadiga. Também pode interpretar uma instrução ambígua de forma diferente em duas sessões semelhantes.
A gestão tradicional de identidades e acessos, geralmente chamada de IAM, controla quem pode acessar sistemas e o que essa identidade pode fazer. As funções frequentemente concedem um conjunto estável de permissões com base em um cargo ou função técnica.
Um funcionário do setor financeiro pode receber acesso a faturas, ferramentas de pagamento e sistemas de relatórios. Uma conta de serviço pode receber acesso ao banco de dados para uma aplicação. Revisões então confirmam que essas permissões continuam adequadas.
Um agente pode atravessar esses limites em uma única atribuição. Uma solicitação para resolver um problema de fornecedor pode exigir e-mail, contratos, faturas, status de pagamento e mensagens internas. Funções estáticas têm dificuldade para expressar a autoridade exata necessária para esse objetivo temporário.
A Cloud Security Alliance relatou uma lacuna significativa de visibilidade em uma pesquisa empresarial de 2026. Embora 73% das organizações esperassem que os agentes se tornassem vitais dentro de um ano, 68% não conseguiam distinguir claramente a atividade de agentes da atividade humana. As conclusões aparecem em sua pesquisa sobre agentes autônomos.
Essa distinção é essencial para a investigação. Se um agente usa o token de um funcionário, um log convencional pode mostrar apenas a identidade do funcionário. Os analistas podem não saber se a pessoa clicou em um botão ou delegou a ação ao software.
A premissa humana também molda o design de aprovações. Muitos controles tratam a autenticação como o principal evento de confiança. Quando um usuário passa por essa barreira, os sistemas permitem atividades autorizadas até que a sessão termine ou outra política intervenha.
Os agentes exigem decisões mais frequentes. A permissão deve depender da tarefa, da etapa atual, do recurso solicitado, da ferramenta, da sensibilidade dos dados e das consequências da ação proposta.
Considere um agente de pesquisa encarregado de montar uma apresentação trimestral sobre o mercado. Ler fontes públicas aprovadas se encaixa nesse propósito. Abrir arquivos confidenciais de aquisições não, mesmo quando o executivo solicitante pode acessá-los.
A identidade emprestada do agente pode autorizar ambas as ações. Um controle orientado por propósito ainda deve rejeitar a segunda, porque ela fica fora da tarefa atribuída.
A velocidade agrava essa fraqueza. Uma pessoa que encontra falhas repetidas de acesso pode parar e entrar em contato com o suporte. Um agente pode tentar novamente, escolher outra ferramenta ou buscar em seu contexto disponível uma credencial diferente.
Esses comportamentos podem se assemelhar a um ataque mesmo quando o agente segue seu objetivo. Eles também podem amplificar um comprometimento real, porque a automação elimina os atrasos que normalmente dão aos defensores tempo para reagir.
As equipes de segurança, portanto, estão sob pressão para separar três identidades: o delegador humano, o agente executor e o serviço ou ferramenta que recebe a solicitação. Perder qualquer parte dessa cadeia enfraquece a atribuição.
A resposta necessária não é um diretório maior de funcionários. É um modelo de autorização que preserve o contexto de delegação em cada etapa e faça o acesso expirar quando a tarefa terminar.
Autonomia e Controle Puxam em Direções Opostas
Os recursos que tornam os agentes valiosos também tornam a confiança permanente perigosa: independência, persistência, amplo acesso a ferramentas e planejamento adaptativo.
Um agente útil precisa ter liberdade suficiente para escolher ações. Se cada etapa menor exigir aprovação humana, o agente se torna uma interface elaborada para trabalho manual.
No entanto, autonomia irrestrita cria um modelo de segurança inaceitável. Um modelo pode interpretar mal um objetivo, seguir conteúdo malicioso, selecionar o registro errado ou divulgar informações por meio de uma ferramenta aprovada.
A injeção de prompt ilustra o conflito. Esse ataque insere instruções no conteúdo que um modelo lê, esperando que o modelo trate esse conteúdo como comandos. Uma página da web, documento, e-mail ou resposta de ferramenta pode conter o texto hostil.
Uma aplicação convencional separa instruções executáveis de dados comuns por meio de código e limites de sistema. Modelos de linguagem processam ambos pelo mesmo contexto de raciocínio, tornando essa distinção mais difícil de aplicar de forma consistente.
Um agente que navega na web pode encontrar uma instrução oculta dizendo para revelar informações armazenadas. Se o agente tiver acesso a memória sensível e a uma ferramenta de comunicação, uma página contaminada pode conectar essas capacidades.
A falha abrange várias camadas de controle. O modelo classifica erroneamente dados como uma instrução. A aplicação permite uma leitura desnecessária de dados. A ferramenta aceita uma ação de saída sem verificar seu propósito.
Bloquear uma frase suspeita não pode resolver essa cadeia. Atacantes podem reescrever instruções, dividi-las entre conteúdos ou explorar referências indiretas. Os defensores precisam de controles fora do próprio processo de raciocínio do modelo.
As orientações de segurança para agentes da Microsoft recomendam identidades digitais únicas, acesso de privilégio mínimo, mecanismos de proteção, fluxos de aprovação e auditoria. Esses controles reduzem a dependência de que o modelo obedeça a uma instrução escrita.
Privilégio mínimo significa conceder apenas o acesso necessário para uma tarefa específica. Para os agentes, esse princípio deve se tornar mais restrito e temporário do que muitas funções empresariais existentes.
Um agente de despesas pode precisar ler um recibo enviado e um documento de política. Ele não precisa de acesso permanente às despesas de todos os funcionários. Também não deve aprovar sua própria exceção.
Credenciais de curta duração podem limitar a exposição. Um intermediário pode emitir uma credencial para um agente, tarefa, recurso e janela de tempo. O serviço receptor pode verificar essas condições antes de aceitar uma ação.
Etapas de alto impacto precisam de barreiras mais fortes. Enviar dinheiro, excluir registros, alterar sistemas de produção ou expor dados regulamentados deve acionar verificações determinísticas de política. Determinístico significa que as mesmas condições definidas produzem a mesma decisão.
O modelo pode propor uma ação, mas não deve decidir se sua própria ação é permitida. Essa separação reflete práticas de segurança conhecidas, nas quais as aplicações solicitam acesso e os sistemas de política avaliam a solicitação.
A aprovação humana ainda tem um papel, especialmente quando a intenção não pode ser expressa com segurança em código. No entanto, os prompts de aprovação devem fornecer contexto significativo. Um botão genérico de “permitir” transfere o risco sem melhorar o julgamento.
Um revisor deve ver o ser humano que fez a solicitação, o agente executor, o recurso afetado, a ação proposta, o resultado esperado e o motivo da escalada. A aprovação deve abranger apenas essa ação, e não todas as etapas posteriores.
Esse modelo preserva uma autonomia útil dentro de limites definidos. Os agentes podem lidar com consultas e análises de baixo risco sem interrupções. Ações com consequências enfrentam verificações progressivamente mais rigorosas.
A troca envolvida nunca desaparece. Limites mais rígidos reduzem a flexibilidade, enquanto uma autoridade mais ampla aumenta o possível impacto dos erros. As empresas precisam decidir onde a autonomia gera valor suficiente para justificar esse risco residual.
A Identidade É Necessária, mas Não Pode Explicar a Intenção
Dar um nome a cada agente melhora a responsabilização, mas a identidade por si só não pode determinar se uma ação válida faz parte da tarefa atual.
A identidade tornou-se o ponto de partida mais comum para a segurança de IA agentiva. Isso faz sentido. Os defensores não podem governar ou investigar um ator que não conseguem distinguir de usuários e serviços em segundo plano.
O Google Cloud afirmou em maio de 2026 que os controles tradicionais não foram projetados para agentes autônomos que interagem com dados sensíveis na velocidade das máquinas. Seus controles de identidade de agentes concentram-se em gerenciar o acesso dos agentes e reforçar as defesas em tempo de execução.
A Microsoft trata de forma semelhante um agente como um ator digital que deve receber uma identidade separada. Isso permite que políticas e registros diferenciem as ações de um agente das ações da pessoa que lhe atribuiu a tarefa.
A Coalition for Secure AI vai além em sua estrutura de IAM agentivo. Ela analisa como os protocolos de identidade existentes precisam representar agentes, autoridade delegada e decisões de acesso.
Esses esforços pressionam fornecedores estabelecidos de IAM, plataformas de nuvem e desenvolvedores de aplicações. Cada camada precisa transportar contexto suficiente para que sistemas posteriores tomem decisões de autorização bem fundamentadas.
Uma identidade única pode responder qual agente fez uma solicitação. Ela não pode responder automaticamente por que a solicitação existe, se o plano mudou ou se o recurso continua necessário.
Essa limitação importa porque um agente comprometido pode se autenticar corretamente. Credenciais roubadas, instruções envenenadas, memória alterada ou uma resposta de ferramenta manipulada nem sempre produzem uma identidade inválida.
O agente pode executar ações individualmente permitidas que formam uma sequência prejudicial. Ler registros de clientes, compactar arquivos selecionados e enviar uma mensagem externa podem parecer normais quando avaliados separadamente.
Juntas, essas ações podem representar roubo de dados. Os sistemas de segurança precisam examinar a trajetória, isto é, o caminho ordenado de decisões e ações ao longo da tarefa.
Um artigo de pesquisa de 2026 sobre garantia de trajetória argumenta que verificações por ação são insuficientes para sistemas de agentes. Os autores enfatizam a verificação arquitetural de identidades, delegação, comunicações e controles de execução.
Essa abordagem se assemelha à detecção comportamental, mas acrescenta contexto da tarefa. Um agente encarregado de resumir contratos não deveria começar a alterar políticas de acesso, mesmo que suas permissões técnicas permitam essa ação.
Controles em tempo de execução podem comparar a ação atual com o objetivo original, o plano aprovado, as etapas anteriores e a autoridade restante. Eles podem pausar a execução quando a trajetória se desvia dos limites esperados.
Os registros também precisam de maior precisão. Uma trilha de auditoria útil deve registrar o delegador, a identidade do agente, a versão do modelo, a chamada de ferramenta, o recurso acessado, a decisão de política e o efeito colateral resultante.
No entanto, as organizações devem ter cautela ao registrar raciocínios privados ou prompts sensíveis sem limites. Registros detalhados podem conter dados confidenciais, credenciais, informações de funcionários ou conteúdo de clientes.
A auditabilidade, portanto, cria suas próprias obrigações de segurança e privacidade. Os logs exigem controles de acesso, regras de retenção, resistência à adulteração e uma finalidade definida. Mais telemetria não é automaticamente uma telemetria mais segura.
A memória introduz outra complicação. Um agente pode reter preferências, histórico de tarefas ou contexto operacional entre sessões. Uma memória corrompida pode afetar ações posteriores muito tempo depois que o conteúdo malicioso original desaparece.
As organizações precisam de procedência para essas memórias. A procedência registra de onde a informação veio, como ela mudou e qual processo aprovou seu uso contínuo.
Fluxos de trabalho com conhecimento sensível também se beneficiam de manter o material-fonte organizado e rastreável. Uma base de conhecimento pesquisável pode apoiar a revisão humana, mas não substitui a autorização de agentes.
A identidade é, portanto, um plano de controle, não a resposta completa. A execução segura também exige limites de finalidade, aplicação externa de políticas, monitoramento de trajetória e registros recuperáveis.
O Problema Mais Difícil É a Responsabilização Após a Delegação
Um agente pode executar uma decisão sem se tornar legal, operacional ou eticamente responsável por suas consequências.
A segurança centrada em humanos pressupõe que a responsabilização acaba levando a uma pessoa ou organização. Sistemas agentivos complicam esse caminho sem eliminá-lo.
Um líder empresarial pode autorizar um agente para um resultado amplo. Um desenvolvedor pode selecionar suas ferramentas. Uma equipe de plataforma pode gerenciar credenciais. Uma equipe de segurança pode definir políticas, enquanto um fornecedor disponibiliza o modelo subjacente.
Quando o agente causa danos, cada participante pode apontar para outra camada. O líder não escolheu a ação exata. O desenvolvedor não criou o conteúdo malicioso. O provedor do modelo não concedeu acesso à produção.
Essa fragmentação cria uma lacuna de propriedade. A atribuição técnica pode identificar qual componente agiu, mas a responsabilização organizacional precisa identificar quem aceitou o risco e quem pode parar o sistema.
Todo agente em produção precisa de um proprietário responsável. Esse proprietário deve aprovar a finalidade do agente, os limites de dados, as ferramentas, a classificação de risco e o caminho de escalada.
Propriedade não deve significar revisar cada resultado. Significa manter as condições sob as quais a autonomia permanece aceitável. Também significa suspender o agente quando as evidências ficarem fora dessas condições.
As equipes de segurança precisam de um inventário atualizado de agentes e de suas capacidades. Cada registro deve incluir o proprietário do agente, delegadores, credenciais, ferramentas conectadas, acesso a dados, dependências de modelos e consequências permitidas.
O inventário deve refletir implantações reais, não apenas projetos aprovados. Agentes podem entrar por meio de funcionalidades de software, automações criadas por funcionários, frameworks de desenvolvimento, extensões de navegador e integrações de terceiros.
A descoberta é difícil porque um agente pode se parecer com tráfego comum de API. Ele pode usar um token de usuário ou uma conta de serviço existente. Sem sinais específicos de agente, os defensores veem a ação, mas não identificam o ator.
A responsabilização também depende da reversibilidade. Os sistemas devem definir quais ações podem ser desfeitas e com que rapidez. Enviar um rascunho para uma fila de revisão é reversível. Publicá-lo abertamente cria um impacto mais amplo e menos previsível.
A mesma distinção se aplica às operações de segurança. Um agente pode recomendar o isolamento de um dispositivo. Desconectar automaticamente uma estação de trabalho hospitalar ou um servidor de produção envolve um risco operacional diferente.
As organizações devem classificar as ações por consequência. Acesso somente leitura, elaboração interna, comunicação externa, transações financeiras, alterações de permissões e operações destrutivas não devem compartilhar uma única política de aprovação.
A visão cética merece atenção aqui. Alguns controles de agentes propostos continuam sendo alegações de fornecedores, recomendações arquiteturais ou padrões iniciais. Sua eficácia em ambientes de produção heterogêneos ainda não foi comprovada em larga escala.
Identidades únicas não impedem decisões ruins. Logs detalhados não interrompem uma ação já concluída. Aprovações humanas podem se tornar rotineiras, apressadas ou vulneráveis a contextos enganosos.
Até mesmo um mecanismo externo de políticas pode conter erros. Uma regra pode omitir um fluxo de trabalho incomum ou permitir uma combinação prejudicial de ações individualmente aceitáveis.
Os programas de segurança devem, portanto, evitar afirmar que a identidade de agentes “resolve” o risco autônomo. Ela melhora a visibilidade e a aplicação, mas a incerteza residual permanece nos modelos, ferramentas, dados e decisões organizacionais.
O objetivo mais seguro é a falha limitada. Um agente deve ter acesso limitado, tempo limitado, autoridade de gastos limitada e capacidade limitada de afetar outros sistemas.
Quando ocorrer uma falha, as equipes devem conseguir reconstruir a sequência, conter o agente, revogar suas credenciais, restaurar os recursos afetados e atualizar a política.
Esse modelo trata os erros como eventos operacionais esperados. É mais realista do que presumir que cada prompt, resposta do modelo e chamada de ferramenta se comportará como pretendido.
Três Sinais Mostrarão se a Segurança Está Acompanhando o Ritmo
A próxima fase será medida por controles aplicáveis e evidências de produção, não por alertas adicionais sobre riscos autônomos.
O primeiro sinal é a adoção de identidades de agentes com escopo de tarefa. Plataformas de nuvem e aplicações empresariais precisam mostrar que um agente pode receber autoridade temporária sem herdar o acesso completo de um usuário.
Observe credenciais vinculadas a um delegador específico, finalidade, conjunto de ferramentas, recurso e horário de expiração. Observe também se aplicações posteriores conseguem avaliar esse contexto em vez de aceitar um token de portador genérico.
O suporte disseminado reforçaria a ideia de que a infraestrutura de identidade existente pode evoluir para agentes. A adoção lenta exporia um difícil problema de interoperabilidade, especialmente entre várias nuvens e fornecedores de software.
O segundo sinal é o teste independente de controles em tempo de execução. Os fornecedores descrevem cada vez mais proteções, monitoramento e autorização específica para agentes. Os compradores precisam de evidências de que esses sistemas bloqueiam ataques realistas de várias etapas e violações acidentais de políticas.
Os testes devem incluir injeção indireta de prompts, memória envenenada, ferramentas comprometidas, escalada de privilégios e combinações prejudiciais de ações permitidas. Também devem medir falsos positivos que interrompem trabalhos legítimos.
Resultados fortes em diferentes modelos e aplicações sustentariam a transição para a aplicação em tempo de execução. Resultados limitados a demonstrações controladas enfraqueceriam as alegações de que a arquitetura está pronta para implantação ampla.
O terceiro sinal é se as organizações conseguem reconstruir ações de agentes após um incidente. Reguladores, seguradoras, clientes e auditores internos perguntarão quem delegou a autoridade e por que uma ação com consequências passou pela política.
Um registro completo deve conectar a solicitação humana ao agente, modelo, ferramentas, dados, aprovações e efeito colateral final. Links ausentes revelarão que a responsabilização ainda depende de inferência.
Esse sinal também testa a prontidão operacional. Uma empresa pode ter logs detalhados, mas nenhum proprietário autorizado a suspender o agente. Outra pode revogar credenciais, mas não ter um ponto de recuperação limpo.
Leitores que acompanham a IA agentiva pelo Google News devem separar três histórias diferentes. A capacidade dos modelos descreve o que os agentes podem tentar fazer. A adoção de produtos descreve onde as empresas os implantam. A maturidade de segurança descreve se essas implantações continuam governáveis.
Essas curvas não avançam na mesma velocidade. As capacidades e integrações dos agentes podem se expandir por meio de atualizações de software. O redesenho de identidade, o suporte de aplicações, as práticas de auditoria e a propriedade organizacional exigem mudanças coordenadas.
Os desenvolvedores devem perguntar de que autoridade um agente realmente precisa antes de conectar mais uma ferramenta. Compradores empresariais devem exigir evidências sobre separação de identidade, aplicação de políticas, registros e contenção de incidentes.
Os profissionais do conhecimento devem perceber quando um assistente começa a executar ações em vez de apenas propô-las. Esse limite determina se um erro permanece um rascunho ou se se torna um evento operacional.
A pergunta mais útil não é se um agente se comporta como uma pessoa. É se o sistema consegue restringir um ator que opera de forma diferente de qualquer pessoa.
A supervisão humana continua importante, mas não pode seguir sendo o único mecanismo de segurança. As pessoas não conseguem revisar cada decisão tomada na velocidade das máquinas sem eliminar a autonomia que as empresas adquiriram.
A segurança precisa codificar a intenção humana em limites técnicos aplicáveis. Precisa preservar essa intenção ao longo de delegações, chamadas de ferramentas, memória e planos em constante mudança.
O ciclo de atenção do Google News passará para outra manchete. O teste subjacente permanecerá: as organizações conseguem conceder autonomia útil sem conceder autoridade invisível, persistente e sem prestação de contas?
Antes de implantar o próximo agente, mapeie uma tarefa completa, da instrução à consequência. Identifique cada credencial, fonte de dados, ferramenta, aprovação e etapa de recuperação. Qualquer elo ausente não é apenas uma lacuna na documentação. É um ponto em que a ação autônoma pode superar o controle humano.


