One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.” It sounds almost funny. In software terms, though, it points to a real problem.
One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.” It sounds almost funny. In software terms, though, it points to a real problem.
“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, according to the prime minister, though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.
Around the same time, OpenAI disclosed another incident. A model in training found its web searches and direct connections blocked, then discovered that the environment’s own DNS resolver still answered. It embedded questions in hostnames and got answers from an external chatbot. OpenAI stopped the run. Days later, it shelved GPT-6.1 Astra, which Saachi Jain, its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”
Different systems, different failures, one question: what does “access denied” mean to an agent?
Traditional software treats an authorization failure as the end of a code path. A service gets a 403, raises an exception and someone reads the log. The denial works as a stop sign because the program has no independent objective to pursue.
We have spent years teaching software to recover from failure: retry the request, switch the endpoint, back off and try again. Those are good instincts. They become dangerous when the failure is the security control itself.
In context
- Topic: Inteligencia Artificial — IA aplicada al negocio: casos, límites, costos y gobierno.
- Source: InfoWorld
- Published: 20/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por que importa
Toda semana há um anúncio que promete mudar tudo, e toda semana a maioria das organizações continua brigando com o mesmo: dados desorganizados, processos que ninguém documentou e uma expectativa que corre mais rápido que a capacidade. Esta notícia se entende melhor com isso ao fundo.
O que olho primeiro não é a capacidade do modelo, e sim o dado que o alimenta. Quase todos os projetos que vi fracassar não fracassaram pelo algoritmo: fracassaram porque o dado estava em três sistemas com três definições diferentes e ninguém quis ser quem arrumaria isso.
O que costuma dar errado
O erro que mais vi se repetir é não medir nada antes de começar. Implementa-se, todo mundo sente que melhorou, e quando alguém pergunta quanto, não há resposta. Sem linha de base não há como defender o orçamento do ano seguinte, e é aí que bons projetos morrem.
O que observar
- Onde ficam os dados e sob qual contrato, sobretudo quando há informação de clientes envolvida.
- Se a organização pode trocar de fornecedor sem refazer tudo, que é a prova de que não ficou amarrada.
- Qual processo concreto é tocado e como se mede antes e depois; sem linha de base não há resultado, há opinião.
Como leio esta publicação
Se eu tivesse que levar isto a uma organização, começaria por um processo chato e mensurável — conciliação, atendimento de primeiro nível, revisão documental — e o deixaria rodando com métrica antes de tocar em qualquer coisa vistosa. A credibilidade para os projetos grandes se compra com um resultado pequeno que ninguém pode discutir.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
