Revise um log de auditoria em busca de atividade suspeita com IA, com retenção zero de dados
Um agente lê um dia de eventos administrativos e sinaliza a sequência suspeita com os IDs dos eventos e uma resposta recomendada.
- Conexão somente leitura
- Retenção zero de dados
- Limite de orçamento
Veja uma execução real
Uma execução real em 7 de out. de 2026, reproduzida. Modelo: openai/gpt-6-luna.
- Na filaorçamento de $0.03 reservado
- MicroVMmicroVM ready
- MicroVMworker started · shell off · web off
- Conexãoops GET /audit-log
- Resultado
ops GET → 200 - MicroVMmicroVM destroyed
- Concluída2 chamadas ao modelo, 3,902 tokensSaída gravada (em inglês)
Verdict: High-severity suspicious activity: [email protected]’s account had a linked off-hours access and privilege/data-access sequence from an IP not seen in its earlier events.
Severity Event IDs Why unusual Recommended response high ev013–ev020 Three failed logins were followed by a successful login using a recovery code at 23:14 UTC, outside the stated 08:00–19:00 UTC business hours. From the same IP, the account then granted admin access to an external address, exported 48,210 rows, created an API key, and that address logged in. Contain the account and review its sessions, recovery-code use, role change, export, and API key; revoke access or credentials as appropriate. No finding for the rest of the log.
- Worker destruído$0.003879 cobrados, $0.026121 liberados
A retenção zero de dados estava ativada nesta execução.
Execute você mesmo
Abra o exemplo no playground com a requisição inteira preenchida. Ele roda na sua própria conta, dentro do orçamento indicado, contra os mesmos sistemas de exemplo somente leitura.
Orçamento deste exemplo: $0.03
Como funciona
Logs de auditoria são sensíveis, então a execução usa retenção zero de dados e uma conexão somente leitura. O agente aponta os IDs exatos dos eventos, explica por que a sequência é incomum (fora do horário, autenticação multifator ignorada, mudança de privilégio, exportação em massa) e não acusa uma pessoa.
O que o agente pode e não pode fazer
As permissões fazem parte da requisição. Tudo o que não está listado aqui não está disponível para a execução.
| Configuração | Permitido |
|---|---|
| Conexões | ops: somente GET, em ephemer.al/api/samples/ops-api |
| Web | Desativado |
| Shell | Desativado |
| Arquivos | Nenhuma |
| Retenção zero de dados | Ativada: nenhum rastro é registrado e a saída é devolvida uma única vez |
| Orçamento | $0.03, um limite rígido |
| Tempo limite | 60 segundos |
As credenciais nunca entram na máquina: um broker as adiciona a cada chamada e aplica os métodos acima.
O código
Esta é a requisição exata que o exemplo envia. Defina EPHEMERAL_API_KEY com uma chave de membro da sua organização.
curl -X POST $EPHEMERAL_URL/v1/runs \
-H "Authorization: Bearer $EPHEMERAL_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d @request.jsonCorpo completo da requisição request.json
O mesmo corpo, com os arquivos inline.
{
"prompt": "Review the audit log from GET /audit-log on the ops connection and the business hours it states. Reply in Markdown, at most 200 words: a one-line verdict, then a table of suspicious findings with severity (high, medium, low), the event IDs, why they are unusual, and a recommended response. Treat patterns, not single events, as findings: an off-hours login alone is low. Say 'no finding' for the rest of the log in one line. Describe behavior of accounts, never accuse a person. Use only what the data returns and never guess; if a call fails or a field is missing, say so.",
"connections": {
"ops": {
"type": "http",
"url": "https://ephemer.al/api/samples/ops-api",
"auth": {
"type": "bearer",
"token": "sample_read_key"
},
"allowed_methods": [
"GET"
],
"instructions": "GET /audit-log returns the date, a note on business hours, and events with id, at (UTC), actor, action, target, ip, result and sometimes reason, mfa, rows or role."
}
},
"shell": false,
"timeout_seconds": 60,
"max_cost_micros": 30000,
"zero_data_retention": true
}