Skip to content
Apart Research
Apart Research
Contact us
Sprint projectSep 13, 2026Princeton

Proxy Metrics for Early Detection of Synchronized Multi-Agent Intrusions

Mayank Gupta · Team M

Submitted to AI Incident Response Sprint. Sprint projects are early-stage work by participants, not Apart Research publications.

Read the report

Report: Proxy Metrics for Early Detection of Synchronized Multi-Agent Intrusions

Open in a new tab (opens in new tab)
Share

Proxy Metrics for Early Detection of Synchronized Multi-Agent Intrusions. Using the July 2026 OpenAI-Hugging Face incident as a case study, I reconstructed the multi-stage attack locally with hf-ctf (a Minikube build with the original network policies), ran the full exploit chain, and captured packet telemetry. On it I evaluated Synchronized Polling Density ($M_{sync}$), distinct client sources hitting one endpoint per 1-second window. It separated hostile reconnaissance ($M{sync}=2$, at Artifactory's token/repo endpoints) from background noise ($M{sync}=1$), even though the busiest endpoint took 1,472 requests from 1,408 sources, so the metric keys on coordination, not volume, and fires during reconnaissance, before any breach. The peak of 2 reflects the testbed's single linear chain, not a real swarm, so it's a proof of concept. I argue a parallel adversary would push it far higher, and analyze jitter-based evasion.

Reviews

Judging this Sprint?

Review “Proxy Metrics for Early Detection of Synchronized Multi-Agent Intrusions”

Your public critique appears on the project page without your name. Reviews of strong projects are shared with funders, as you choose below.

Not shown on the project page.

Shown on the project page, without your name.

Only the Apart team reads this, and funders if you agree below.

Decline to score

Only when the quality of the writing makes the work impossible to follow. Say why in your private critique; the project page shows only that a judge declined, not why.

How much would this matter for AI safety if it worked? How innovative is it? For scores of 4-5: is this actually new to the field, or replicating recent work?

Scoring guide
  1. 1Negligible. No clear problem addressed, or no meaningful novelty.
  2. 2Limited. Addresses a real problem but with a generic or well-trodden approach. Incremental at best.
  3. 3Moderate. Clear problem with a reasonable approach; some novelty in framing or method beyond routine application of existing tools.
  4. 4Significant. Important problem with an original approach, or identifies a neglected problem area. A valuable contribution others could build on.
  5. 5Exceptional. Tackles a critical AI safety problem with a genuinely novel approach, or opens a new research direction. Clear theory of change. You'd be excited to share this with researchers in the area.

How sound are methodology, implementation, and findings?

Scoring guide
  1. 1Seriously flawed. Methodology broken, results uninterpretable, or implementation doesn't work.
  2. 2Weak. Approach has significant gaps: missing validation, flawed experimental design, or incomplete implementation.
  3. 3Competent. Technically solid given the short duration. Methodology makes sense, results are interpretable, limitations acknowledged, work builds toward clear conclusions.
  4. 4Strong. Thorough methodology with convincing validation. Results clearly support conclusions. Immediately useful for future work.
  5. 5Exceptional. Ambitious scope executed rigorously. Surprising findings, novel methods, or unusually robust validation.

How clearly are work, findings, and impact potential communicated?

Scoring guide
  1. 1Incomprehensible. Cannot determine what the project is actually claiming or doing.
  2. 2Hard to follow. Key information buried, missing, or diluted by excessive length. Significant effort to extract main points.
  3. 3Clear enough. Can understand the problem, approach, and results without undue effort. Core content clearly present: problem, method, findings, limitations.
  4. 4Well presented. Easy to follow, well-structured, appropriate level of detail. Target audience would get it quickly.
  5. 5Exceptionally clear. A pleasure to read. Complex ideas made accessible. Could serve as a model for how to present this type of work.
Sharing your name *

When we share a strong project with funders, your name, scores and public critique go with it, confidentially; this choice is only about whether your name is public. If you think this project deserves funding, please also endorse it: that carries the most weight.

Share my private critique with funders *

See our Privacy Policy.

  1. The approach to detect multi-agent attacks by understanding the structural footprint of the attack and without the need to inspect the payload is simple and promising. Inspecting payloads for thousands of requests simultaneously can be costly and may introduce significant latency. Hence, this approach, without having to inspect the payload content, is certainly interesting. Having said that, here are a few ideas that the author can use to further enhance the approach:

    1. Testing in a real environment with greater concurrency - Testing with multiple workers and agents will help validate the idea even further. The current test uses a single script that issues requests in succession but does not mimic a multi-agent attack scenario
    2. Add a real-world environment scenario where there is a high chance for concurrent connections. See how does that contribute to false positives
    3. One program or process can use multiple source ports. So, using source ports to identify distinct sources may lead to wrong results. What other identity can be used in place of source ports
    Read full reviewShow less

  2. This project has a clear incident response framing and shows real hands on work: reproducing much of the attack chain, capturing network telemetry, and asking whether temporal convergence can surface reconnaissance earlier than breach anchored alerts. The distinction between raw traffic volume and coordinated activity is useful, and the discussion of endpoint sensitivity, multiple time windows, and jitter based evasion points toward practical follow up work.

    The most important issue is that the paper defines M_sync as the number of distinct client sources contacting an endpoint within a sliding window, while the analysis and plotting scripts actually compute a rolling request count. As implemented, a single client making two requests within one second can produce M_sync equal to 2, so the reported result does not yet establish detection of multi agent coordination. TCP source ports would also be an unstable proxy for distinct agents, since one process can open multiple connections.

    The next iteration should align the formula with the implementation, use a more stable identity like workload, pod, authenticated principal, or agent identity, and test with actual parallel workers. Evaluation should include realistic benign fan out, retry storms, deployments, and batch traffic, along with window and jitter sweeps, threshold calibration, and measured false positives and detection rates. Publishing sanitized derived telemetry would also make the reported results independently reproducible.

    Read full reviewShow less

Cite this project

@misc{gupta2026proxy,
  title = {{Proxy Metrics for Early Detection of Synchronized Multi-Agent Intrusions}},
  author = {Mayank Gupta},
  year = {2026},
  month = sep,
  note = {Submitted to AI Incident Response Sprint, an Apart Research Sprint},
  howpublished = {\url{https://apartresearch.com/sprints/projects/proxy-metrics-for-early-detection-of-synchronized-multiagent-intrusions-e4de}},
  url = {https://apartresearch.com/sprints/projects/proxy-metrics-for-early-detection-of-synchronized-multiagent-intrusions-e4de}
}

More from AI Incident Response Sprint

All 231 entriesBrowse all projects

Build something like this at the next Sprint

AI x Epistemics Research Sprint · Nov 13 - 15, 2026