🚨 NOVA NOTÍCIA EM DESTAQUE! 🚨
Sua opinião é importante: leia e participe!
Apoie esse projeto de divulgacao de noticias! Clique aqui
A primeira onda de preocupação com a IA empresarial foi direta. Eram simplesmente funcionários colando dados confidenciais em ferramentas públicas de IA. As equipes de segurança responderam com políticas de uso, bloqueios de domínio e regras de prevenção contra perda de dados. Essa resposta fez sentido na época.
Não cabe mais no problema.
Shadow AI passou de uma preocupação de vazamento de dados para um problema de controle de acesso. A ameaça não é o que os funcionários digitam nas ferramentas de IA. Trata-se de quais agentes de IA estão operando dentro da organização, a quais sistemas corporativos eles estão conectados e quais ações eles estão autorizados, ou não, a realizar.
De ferramentas passivas a atores ativos
Funcionários e unidades de negócios estão construindo agentes de IA em um ritmo que a maioria das equipes de segurança não consegue acompanhar. Assistentes personalizados, agentes de codificação, automações de fluxo de trabalho e aplicativos de agente estão sendo criados em departamentos, alguns em plataformas sancionadas, mas muitos por meio de extensões de navegador, recursos nativos de SaaS, ferramentas de desenvolvedor, servidores MCP, agentes baseados em endpoint e scripts personalizados. Muitos começam como experimentos rápidos. Alguns são incorporados em processos de negócios críticos em poucos dias.
O perfil de risco destes agentes é fundamentalmente diferente do shadow IT tradicional. Um aplicativo SaaS não sancionado é um destino para dados. Um agente de IA é um ator que pode chamar APIs, usar credenciais armazenadas, recuperar registros, modificar configurações, acionar fluxos de trabalho downstream e executar ações em sistemas de produção, muitas vezes sem que um humano autorize explicitamente cada etapa.
Um funcionário colando um registro de cliente em uma ferramenta pública de IA é um incidente de vazamento de dados. Um agente de IA personalizado conectado ao Salesforce, Snowflake, GitHub, Gong e Slack é um incidente de controle de acesso esperando para acontecer. Ele poderia expor dados, mas também poderia executar ações de leitura, gravação e exclusão nesses dados. Ele também pode ser executado em contas de serviço com permissões que ninguém auditou e permanecer ativo seis meses depois que o funcionário que o criou mudou de função ou deixou a empresa. Uma nova pesquisa da Token Security e da Cloud Security Alliance mapeia exatamente o quão difundida esta exposição se tornou.
Por que os controles existentes não alcançam isso
A maioria dos controles de segurança empresarial foram projetados para identidades humanas e cargas de trabalho determinísticas. Políticas IAM, regras DLP e monitoramento de rede assumem comportamento previsível e caminhos de acesso definidos. Os agentes de IA quebram essas suposições.
Um agente encarregado de resolver uma implantação com falha pode ler logs, consultar sistemas de monitoramento, modificar configurações de infraestrutura, abrir tickets, acionar pipelines de automação e notificar equipes de engenharia, tudo em sequência, todos usando as mesmas credenciais herdadas. Para evitar a interrupção dos fluxos de trabalho, os desenvolvedores concedem permissões amplas antecipadamente. Essas permissões se acumulam. Os agentes herdam privilégios de criador, o acesso temporário torna-se permanente e as equipes de segurança e identidade perdem visibilidade sobre o que essas identidades estão realmente fazendo.
O bloqueio de domínios públicos de IA não atinge nada disso. No momento em que um agente possui credenciais para sistemas empresariais, a fronteira já foi ultrapassada. A remediação automatizada de identidades não humanas é onde essa lacuna é preenchida.
Qual é a aparência de um inventário real de IA sombria
Descobrir a Shadow AI requer examinar os ambientes onde os agentes realmente vivem, como plataformas de IA, aplicativos SaaS com automação integrada, contas na nuvem, ferramentas de desenvolvedor, endpoints e provedores de identidade. Aqui estão seis perguntas para definir se as equipes de segurança têm controle real.
Onde os agentes estão sendo criados ou instalados? Isso inclui plataformas óbvias de IA, mas também assistentes de codificação, recursos de agente nativos de SaaS, ferramentas de desenvolvedor local e aplicativos internos que adicionaram silenciosamente recursos de IA.
Quem é o proprietário de cada agente e quem pode usá-lo? Sem propriedade, não há responsabilidade. Um agente criado para uma equipe financeira de três pessoas e compartilhado por toda a organização carrega um perfil de risco muito diferente de um agente com escopo definido para um único usuário.
A quais recursos e serviços o agente está conectado? Um agente pode parecer inofensivo no nível da plataforma enquanto mantém conexões com bancos de dados confidenciais ou sistemas de produção por meio de credenciais que foram concedidas informalmente e nunca revisadas.
Que identidades e segredos ele usa? Os agentes autenticam por meio de contas de serviço, chaves de API, tokens OAuth, funções IAM na nuvem e segredos de longa duração. Cada tipo de credencial acarreta riscos diferentes.
Qual é a intenção do agente e o que ele realmente fez? A configuração por si só não mostra se um agente está lendo dados, gravando registros ou acessando sistemas fora do escopo pretendido. Compreender a intenção e o contexto comportamental é necessário para priorizar a resposta.
O agente ainda está ativo? Os dados do Agentic Pulse da Token Security descobriram que 65,4% dos chatbots agentic nunca foram usados desde a criação, mas
Não cabe mais no problema.
Shadow AI passou de uma preocupação de vazamento de dados para um problema de controle de acesso. A ameaça não é o que os funcionários digitam nas ferramentas de IA. Trata-se de quais agentes de IA estão operando dentro da organização, a quais sistemas corporativos eles estão conectados e quais ações eles estão autorizados, ou não, a realizar.
De ferramentas passivas a atores ativos
Funcionários e unidades de negócios estão construindo agentes de IA em um ritmo que a maioria das equipes de segurança não consegue acompanhar. Assistentes personalizados, agentes de codificação, automações de fluxo de trabalho e aplicativos de agente estão sendo criados em departamentos, alguns em plataformas sancionadas, mas muitos por meio de extensões de navegador, recursos nativos de SaaS, ferramentas de desenvolvedor, servidores MCP, agentes baseados em endpoint e scripts personalizados. Muitos começam como experimentos rápidos. Alguns são incorporados em processos de negócios críticos em poucos dias.
O perfil de risco destes agentes é fundamentalmente diferente do shadow IT tradicional. Um aplicativo SaaS não sancionado é um destino para dados. Um agente de IA é um ator que pode chamar APIs, usar credenciais armazenadas, recuperar registros, modificar configurações, acionar fluxos de trabalho downstream e executar ações em sistemas de produção, muitas vezes sem que um humano autorize explicitamente cada etapa.
Um funcionário colando um registro de cliente em uma ferramenta pública de IA é um incidente de vazamento de dados. Um agente de IA personalizado conectado ao Salesforce, Snowflake, GitHub, Gong e Slack é um incidente de controle de acesso esperando para acontecer. Ele poderia expor dados, mas também poderia executar ações de leitura, gravação e exclusão nesses dados. Ele também pode ser executado em contas de serviço com permissões que ninguém auditou e permanecer ativo seis meses depois que o funcionário que o criou mudou de função ou deixou a empresa. Uma nova pesquisa da Token Security e da Cloud Security Alliance mapeia exatamente o quão difundida esta exposição se tornou.
Por que os controles existentes não alcançam isso
A maioria dos controles de segurança empresarial foram projetados para identidades humanas e cargas de trabalho determinísticas. Políticas IAM, regras DLP e monitoramento de rede assumem comportamento previsível e caminhos de acesso definidos. Os agentes de IA quebram essas suposições.
Um agente encarregado de resolver uma implantação com falha pode ler logs, consultar sistemas de monitoramento, modificar configurações de infraestrutura, abrir tickets, acionar pipelines de automação e notificar equipes de engenharia, tudo em sequência, todos usando as mesmas credenciais herdadas. Para evitar a interrupção dos fluxos de trabalho, os desenvolvedores concedem permissões amplas antecipadamente. Essas permissões se acumulam. Os agentes herdam privilégios de criador, o acesso temporário torna-se permanente e as equipes de segurança e identidade perdem visibilidade sobre o que essas identidades estão realmente fazendo.
O bloqueio de domínios públicos de IA não atinge nada disso. No momento em que um agente possui credenciais para sistemas empresariais, a fronteira já foi ultrapassada. A remediação automatizada de identidades não humanas é onde essa lacuna é preenchida.
Qual é a aparência de um inventário real de IA sombria
Descobrir a Shadow AI requer examinar os ambientes onde os agentes realmente vivem, como plataformas de IA, aplicativos SaaS com automação integrada, contas na nuvem, ferramentas de desenvolvedor, endpoints e provedores de identidade. Aqui estão seis perguntas para definir se as equipes de segurança têm controle real.
Onde os agentes estão sendo criados ou instalados? Isso inclui plataformas óbvias de IA, mas também assistentes de codificação, recursos de agente nativos de SaaS, ferramentas de desenvolvedor local e aplicativos internos que adicionaram silenciosamente recursos de IA.
Quem é o proprietário de cada agente e quem pode usá-lo? Sem propriedade, não há responsabilidade. Um agente criado para uma equipe financeira de três pessoas e compartilhado por toda a organização carrega um perfil de risco muito diferente de um agente com escopo definido para um único usuário.
A quais recursos e serviços o agente está conectado? Um agente pode parecer inofensivo no nível da plataforma enquanto mantém conexões com bancos de dados confidenciais ou sistemas de produção por meio de credenciais que foram concedidas informalmente e nunca revisadas.
Que identidades e segredos ele usa? Os agentes autenticam por meio de contas de serviço, chaves de API, tokens OAuth, funções IAM na nuvem e segredos de longa duração. Cada tipo de credencial acarreta riscos diferentes.
Qual é a intenção do agente e o que ele realmente fez? A configuração por si só não mostra se um agente está lendo dados, gravando registros ou acessando sistemas fora do escopo pretendido. Compreender a intenção e o contexto comportamental é necessário para priorizar a resposta.
O agente ainda está ativo? Os dados do Agentic Pulse da Token Security descobriram que 65,4% dos chatbots agentic nunca foram usados desde a criação, mas
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #esqueça #o #vazamento #de #dados: #a #verdadeira #ameaça #da #shadow #ai #é #o #controle #de #acesso
⚡ Fique ligado: novidades e promoções em breve por aqui! ⚡
Postar um comentário