Describe the pattern you can actually observe
A burst of activity across many accounts can overwhelm a workflow even when no single account looks unusually busy. Teams may describe this as a bot swarm. That description is a starting hypothesis: it still leaves questions about automation, coordination, permission and impact that the evidence needs to answer separately.
Imagine a fictional limited-release store where many accounts repeatedly request the same reservation during a short window. Record the action, the time window, the reservation pressure and the account context you can establish. Avoid turning a shared timing pattern into a claim that all those accounts belong to one person or organisation.
Look at shared pressure as well as individual use
An allowance per account answers how much each account may do. A capacity rule answers how much the workflow can safely accept in total. Both can matter during a launch. Keep their purposes clear: limiting total active reservations can preserve availability without requiring the system to identify a common operator behind every request.
OWASP describes excessive access to sensitive business flows, including a distributed purchasing example across different addresses and locations. The broader lesson is to examine the business action exposed by the API. For the reservation example, inspect accepted holds, their expiry and available capacity alongside the incoming request count.
Treat shared attributes as context
A shared network address does not establish a shared customer identity. RFC 6269 explains how address sharing can cause one subscriber’s activity to affect others when services apply address-wide penalties. A workplace, household or other shared connection is therefore a reason to inspect the scope of a rule before applying a broad restriction.
The reverse shortcut is also unhelpful: different addresses do not, by themselves, establish unrelated activity. Keep a proposed group explainable through the observations that formed it. If the only common fact is a popular product and a launch time, ordinary demand remains an explanation to examine.
Check what else could create the same pattern
Ask the trading and engineering teams about a promotion, an inventory synchronisation, a retrying integration or a broken page. Compare the timing with those changes. A legitimate campaign can generate concentrated demand; a faulty client can repeat requests. The immediate capacity problem may still need a response, but the longer-term fix depends on the cause.
Use a small incident note with separate entries for what was observed, what the team suspects and what was confirmed. Preserve a bounded sample of relevant records under your retention policy. Collecting more identifiers without a specific question can make the review harder while doing little to improve the decision.
Control the affected action and retain useful access
For the fictional launch, choose a response around reservations: enforce the account’s entitlement, limit active holds and release expired ones. Keep product information available where that remains appropriate. If an approved partner needs a separate allowance, define its permission and capacity explicitly so the exception does not consume the customer allocation unnoticed.
Give temporary incident rules an owner and an expiry. Check the actual execution point: a proposed hold, a queued change and an active platform restriction are different states. Confirm which one applies before telling the team that the workflow is protected. Include a way to correct a mistaken restriction on an individual account.
Evaluate the response without overstating the result
Review whether the affected action remained available to permitted customers, whether the capacity problem eased and which restrictions needed correction. An incident can end while its operator remains unknown. That is a valid outcome if the team records the uncertainty and can explain what the rule achieved.
Blokk Bot’s approach to bot and agent swarms starts with these observable patterns and the customer’s response policy. Useful protection does not depend on claiming a universal identity for every agent. It depends on identifying the action under pressure, applying a justified control and checking its effect on the people and tools meant to use the platform.