Review an audit log for suspicious activity with AI, with zero data retention
An agent reads a day of administrative events and flags the suspicious sequence with event IDs and a recommended response.
- Read-only connection
- Zero data retention
- Budget cap
Watch a real run
A real run on Oct 7, 2026, replayed. Model: openai/gpt-6-luna.
- Queuedbudget $0.03 reserved
- MicroVMmicroVM ready
- MicroVMworker started · shell off · web off
- Connectionops GET /audit-log
- Result
ops GET → 200 - MicroVMmicroVM destroyed
- Succeeded2 model calls, 3,902 tokensRecorded output (English)
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 destroyed$0.003879 charged, $0.026121 released
Zero data retention was on for this run.
Run it yourself
Open the sample in the playground with the whole request filled in. It runs on your own account, within the budget shown, against the same read-only sample systems.
Budget for this sample: $0.03
How it works
Audit logs are sensitive, so the run uses zero data retention and a read-only connection. The agent points at the exact event IDs, explains why the sequence is unusual (off-hours, skipped multi-factor, privilege change, bulk export) and does not accuse a person.
What the agent can and cannot do
The permissions are part of the request. Anything not listed here is not available to the run.
| Setting | Allowed |
|---|---|
| Connections | ops: GET only, at ephemer.al/api/samples/ops-api |
| Web | Off |
| Shell | Off |
| Files | None |
| Zero data retention | On: no trace is recorded and the output is returned once |
| Budget | $0.03, a hard cap |
| Timeout | 60 seconds |
Credentials never enter the machine: a broker adds them to each call and enforces the methods above.
The code
This is the exact request the sample sends. Set EPHEMERAL_API_KEY to a member key of your organization.
curl -X POST $EPHEMERAL_URL/v1/runs \
-H "Authorization: Bearer $EPHEMERAL_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d @request.jsonFull request body request.json
The same body, with the files 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
}