Cyber Security Brasilby Igor Deungaro

Tool-Call Logging: The Audit Event That Matters

Tool-Call Logging: The Audit Event That Matters

Almost every AI platform I have seen in production logs the prompt and the response. Almost none logs the tool call with its arguments. And the tool call is what produces an effect in the world — the prompt is only stated intent.

Why prompt logs are useless for investigation

In an incident the questions are always the same: what was accessed, by which identity, when, and what left the environment. Prompt logs answer none of them. Worse: in indirect injection the user's prompt is innocent — the hostile instruction arrived from a repository issue or a page read along the way.

The Invariant Labs case illustrates it well: a malicious issue in a public repository was enough to redirect an agent with GitHub access into reading private repositories and publishing their contents. The user did nothing unusual — they asked for a review of open issues. A prompt log of that incident shows absolutely nothing wrong.

If your only record is what the user typed, you do not have an audit trail. You have chat history.

The minimum event

A useful tool-call event carries seven fields:

  • Agent identity — individual, not the fleet's shared service account.
  • Delegating human identity, where one exists.
  • Server and tool name.
  • Arguments, with sensitive fields masked but the destination always visible — URL, path, table.
  • Outcome: success, denial, error. A denial is worth as much as a success.
  • Task correlation ID, so the sequence of actions can be reconstructed.
  • Provenance of the content that entered the context before the call, where traceable.

That last field is the hardest and the most valuable: it is what connects “read this external page” to “called this write tool thirty seconds later”.

Where the event belongs

In the same SIEM that receives everything else. Not in the AI vendor's dashboard, not in a local file on the agent host. The reason is practical: correlation. The real value shows up when you join tool calls against network flow logs, IAM events and egress proxy logs.

What this lets you detect

  • A tool called outside that agent's historical hours or frequency.
  • An external-read to external-write sequence inside the same task.
  • An argument pointing at private or link-local ranges — an SSRF attempt visible in the log, not only in the outcome.
  • Anomalous call volume, usually the first evidence of an agent stuck in an uncontrolled loop.

None of these detections requires a new tool. They require the event to exist.

Este blog publica em português e inglês. / This blog publishes in Portuguese and English. EN · PT

Denunciar abuso

As inseguranças do sucesso da segurança cibernética

As inseguranças do sucesso da segurança cibernética. Tornar-se um grande profissional não precisa custar sua felicidade, mas a cultura da moagem torna isso provável. Nos últimos anos, a questão da saúde mental no setor de segurança cibernética ganhou destaque. Uma  pesquisa de 2019  revelou que 1 em cada 6 CISOs admitiu se  automedicar  para lidar com o estresse de seu trabalho. A tensão passa pelo escritório do CISO e permeia todo o setor. Um perfil que está crescendo  mais rápido que o orçamento  e uma sofisticação cada vez maior e  o impacto financeiro  dos ataques se combinam para transformar o que antes era um canto do departamento de TI em uma panela de pressão. John Hammond  , pesquisador de segurança cibernética da Huntress, falou sobre “ Hard Truths and Unexpected Realities: Lamentations in Producing Cybersecurity Content ” na  Intigriti 1337UP Live  , uma conferência online sobre bugs, em março de 2022. Seus...

DICA: comandos para pentest e segurança ofensiva

Fala galera, blz ? Segue uma lista de comandos maravilhosa, voltada para teste de vulnerabilidades. Observação Pertinente: Os TIPOS de COMANDOS e as INSTRUÇÕES estão em INGLÊS! NÂO ME RESPONSABILIZO POR USO INDEVIDO. Pré-requisitos: ✔️  Python 3.5 ✔️  OS que suporte Python (eu utilizei Kali) Reconnaissance / Enumeration Extracting Live IPs from Nmap Scan nmap 10.1.1.1 --open -oG scan-results; cat scan-results | grep "/open" | cut -d " " -f 2 > exposed-services-ips Simple Port Knocking for x in 7000 8000 9000; do nmap -Pn –host_timeout 201 –max-retries 0 -p $x 1.1.1.1; done DNS lookups, Zone Transfers & Brute-Force whois domain.com dig {a|txt|ns|mx} domain.com dig {a|txt|ns|mx} domain.com @ns1.domain.com host -t {a|txt|ns|mx} megacorpone.com host -a megacorpone.com host -l megacorpone.com ns1.megacorpone.com dnsrecon -d megacorpone.com -t axfr @ns2.megacorpone.com dnsenum domain.com nslookup -> set type=any -> ls -d domain.com for ...

Atacantes precisam de menos de 10 horas para encontrar fraquezas

Atacantes precisam de menos de 10 horas para encontrar fraquezas. Configurações vulneráveis, falhas de software e serviços da Web expostos permitem que hackers encontrem pontos fracos exploráveis ​​nos perímetros das empresas em apenas algumas horas, não em dias. O hacker ético médio pode encontrar uma vulnerabilidade que permite a violação do perímetro da rede e, em seguida, explorar o ambiente em menos de 10 horas, com testadores de penetração focados na segurança da nuvem obtendo acesso mais rapidamente aos ativos direcionados. Além disso, uma vez que uma vulnerabilidade ou fraqueza é encontrada, cerca de 58% dos hackers éticos podem invadir um ambiente em menos de cinco horas. Isso está de acordo com uma pesquisa com 300 especialistas do SANS Institute e patrocinada pela empresa de serviços de segurança cibernética Bishop Fox, que também descobriu que as fraquezas mais comuns exploradas pelos hackers incluem configurações vulneráveis, falhas de software e serviços da Web expost...

Quem sou eu

Minha foto
Igor Deungaro
Bem Vindo ao Cyber Security Brasil, espero que goste !!!
Ver meu perfil completo

Cyber Security

Rate limiting e circuit breaker para agentes em loop

Um humano comprometido age em minutos e hesita diante de uma instrução estranha. Um agente age em milissegundos, em loop, e não hesita. Essa diferença de velocidade muda qual controle importa: prevenção continua valendo, mas contenção passa a valer mais. Dois modos de falha, mesma mitigação O primeiro modo é malicioso: contexto envenenado manda o agente iterar sobre registros e enviar tudo para fora. O segundo é banal: um bug de orquestração coloca o agente num ciclo que chama a mesma ferramenta milhares de vezes. O segundo é muito mais comum e produz os mesmos sintomas iniciais — o que é uma boa notícia, porque significa que o controle contra erro também serve contra ataque. Os limites que valem a pena Orçamento de chamadas por tarefa. Uma tarefa que precisava de 12 chamadas e já fez 400 está errada, independente do motivo. Corte e peça intervenção humana. Limite por ferramenta, não global. Cinquenta leituras podem ser normais; cinquenta escritas externas quase nunca são. ...

Marcadores