CtrlK
BlogDocsLog inGet started
Tessl Logo

coding-agent-helpers/compact-debug-ledger

Use when a debugging thread needs to be compressed into a reusable investigation ledger. Capture the target, evidence, attempted fixes, ruled-out hypotheses, viable hypotheses, and next experiments. Good triggers include "compact this debugging session", "summarize what we've tried", and "turn this into a debugging ledger".

99

3.66x
Quality

100%

Does it follow best practices?

Impact

99%

3.66x

Average score across 8 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

task.mdevals/scenario-7/

Compacting a Verbose Security Incident Investigation

Problem Description

A security team has been investigating a suspected unauthorized data access incident over two days. The investigation log is long and contains a lot of back-and-forth between team members, re-explanations of context to people joining late, false starts, and follow-up questions that went nowhere. You need to distill it into a compact reference document that another analyst could act on immediately.

Produce a compact investigation record from the log below and save it as security_investigation.md.

Input Files

The following file is provided as input. Extract it before beginning.

=============== FILE: inputs/security_log.md ===============

Security Incident Investigation Log

Day 1

[10:05] DataDog alert: Unusual spike in API calls to /export endpoint from a single user account (user_id: 44821). 3,400 calls in 2 hours vs typical 5-10/day.

[10:12] Alex: That's definitely anomalous. Let me pull the logs. Can someone also check if this IP is on any blocklists?

[10:15] Sam: On it.

[10:20] Alex: Logs show all calls are authenticated with a valid session token. The user is a legitimate customer account (Acme Corp, enterprise tier).

[10:25] Sam: IP (203.0.113.47) is not on any blocklists. It's a Cloudflare datacenter IP though — might be running through a proxy.

[10:30] Alex: So either the account was compromised and someone is exfiltrating data, or the customer wrote an automated script that's hammering our API. Or their API key leaked.

[10:35] Jordan (joining late): Hi, what's going on? Can someone catch me up?

[10:36] Alex: We have a user making 3,400 API calls in 2 hours. Checking if it's malicious.

[10:45] Sam: Checked the customer's contract — they're on the enterprise tier which allows bulk export. But our ToS says no automated scraping without approval.

[10:50] Alex: Are they exporting different records each time or the same ones?

[10:55] Jordan: I can check. Let me query the access log... they're downloading different record IDs each call. It's a sequential pattern — looks like they're paginating through the entire dataset systematically.

[11:00] Alex: That's concerning. How much data have they pulled?

[11:05] Jordan: About 2.1 million records based on the record IDs in the logs.

[11:10] Sam: Is that PII?

[11:12] Alex: Yes, those records contain customer email addresses and transaction amounts. This could be a GDPR issue depending on their DPA.

[11:15] Jordan: Should we suspend the account?

[11:20] Alex: Not yet. Let's check if there's a support ticket or communication from this customer about doing a data migration. Don't want to cut off a legitimate use case.

[11:30] Sam: No active support tickets. But there was an email from Acme Corp's IT team 3 days ago asking about "bulk data export options." We replied explaining the API but they never confirmed they'd use it.

[11:45] Alex: Okay so they might just be doing a migration without telling us. But the volume is unusual even for that. Let me check rate limit logs — are they hitting our rate limits?

[11:50] Jordan: Not hitting rate limits. They seem to have figured out the maximum sustainable request rate to avoid triggering them.

[11:55] Alex: That's suspicious. A legitimate migration wouldn't usually be designed to avoid rate limits.

[12:00] Sam: I have to jump on another call. Will be back in an hour.

[12:01] Jordan: Same, I have a lunch meeting.

[12:02] Alex: I'll keep monitoring.

[13:00] Jordan (back): Any updates?

[13:05] Alex: They stopped at noon exactly. Total: ~3.8 million records over 4 hours. The Cloudflare IP resolved to an automation provider (Zapier? No... looks like it's UiPath, an RPA tool).

[13:15] Jordan: So they're definitely running an automated script. RPA tools are used for legitimate business automation but also for scraping.

[13:20] Alex: I think this is probably a rogue employee or contractor at Acme Corp running an unauthorized export, or it's a deliberate exfiltration disguised as an automation task.

[13:30] Sam (back): What did I miss?

[13:31] Alex: 3.8M records exported via UiPath RPA, stopped at noon, ongoing investigation.

[13:35] Sam: We should check the session token — when was it issued and when does it expire?

[13:45] Alex: Token was issued 5 days ago, expires in 30 days. Standard enterprise token.

[13:50] Jordan: Should we check if this user account has had any login events from other unusual locations?

[13:55] Alex: Yes, good idea. Auth logs show... 4 login events in the past 5 days, all from the same Cloudflare/UiPath IP range. No logins from the user's usual location (UK) since 3 days ago.

[14:10] Sam: So either the account is compromised or the user themselves is running this from an RPA tool (which would be unusual for a typical enterprise user).

[14:20] Alex: I'm going to email Acme Corp's primary contact to ask if they authorized this export. We should also put a soft rate limit on the account pending their response.

[14:30] Alex: Email sent. Soft rate limit applied (max 100 calls/hour down from 10,000/hour).

[15:00] No response yet.

Day 2

[09:00] Alex: Still no response from Acme Corp. Let me escalate.

[09:30] Jordan: I looked at similar patterns in our logs. Found 2 other enterprise accounts that had similar bursts 2 weeks ago — one was confirmed as a legitimate migration, one we never investigated. The uninvestigated one also used a Cloudflare IP.

[09:45] Alex: The uninvestigated one might be related. Can you check if they're also Acme Corp accounts or a different customer?

[10:00] Jordan: Different customer — TechFlow Ltd. Also enterprise tier. Also exported ~3M records. I don't think they're connected but it's suspicious.

[10:30] Alex: Acme Corp finally responded: they say they authorized a "data migration project" but their IT team "may have exceeded the intended scope." They're asking to restore normal rate limits.

[10:45] Sam: That sounds like a half-admission. We need legal to review whether this constitutes a data breach under GDPR Article 33.

[11:00] Alex: Agreed. I'm looping in legal. For now, keeping the soft rate limit.

[11:15] Jordan: What about TechFlow? Still uninvestigated.

[11:20] Alex: Let's add that as a follow-on. This Acme investigation takes priority.

evals

tile.json