Look for repeated sequential requests, high-volume endpoint enumeration, unusual user-agent patterns, and request sets that focus on identity-like fields such as wallets, usernames, and activity markers. Those patterns suggest an actor is building a correlated dataset rather than using the service normally.
How identity aggregation shows up in API traffic
Identity aggregation is usually visible before the payloads look obviously malicious. The signal is not a single request, but a pattern of many small queries that slowly widen the dataset: one identifier, then the next, then a related attribute, then a status field. That pattern matters because it turns a normal API into a source for correlated identity intelligence.
A practical review should treat sequence as more important than volume alone. Benign clients often repeat a narrow workflow with stable timing and a limited field set, while aggregation traffic tends to move across endpoints and query shapes in a way that suggests record stitching rather than task completion.
One useful lens is whether the request stream is expanding the attacker’s view of a person, account, or wallet over time. If the same client keeps probing for usernames, linked accounts, activity markers, profile fragments, or relationship data, the API may be exposing enough consistency for correlation even when each individual response looks harmless.
Response traits that make aggregation easier
APIs enable aggregation when they return identifiers, stable object references, predictable pagination, or repeatable response structures that make matching easy. A response does not need to reveal full personal data to be useful; a durable key, a unique alias, or a reusable activity marker can be enough to join records across endpoints or over multiple sessions.
Response design also matters when the service leaks too much context in adjacent fields. Fields that are not obviously sensitive in isolation can still become powerful when combined, especially if they let a requester infer account ownership, shared infrastructure, transaction history, or temporal behaviour. That is why aggregation reviews should examine what can be correlated, not only what can be directly read.
For API-specific control expectations, OWASP API Security Top 10 is the right external reference point for broken authorisation, enumeration, and other response-driven exposure patterns. Where the traffic is being used to build a larger identity picture, Top 10 NHI Issues and Ultimate Guide to NHIs, What are Non-Human Identities help frame why repeated access and identity-linked fields are often the first warning signs.
What to verify before calling it identity aggregation
Confirmation depends on whether the same client is building a dataset over time, not just whether the endpoint is popular. Look for correlated bursts across related routes, rising coverage of identity-like fields, and request pacing that is consistent with harvesting. If the traffic stops behaving like a business workflow and starts behaving like discovery, aggregation is a strong possibility.
What to verify: Check whether the requests are linking together fields that should rarely be queried in combination, such as usernames, wallets, activity markers, and account metadata. Then compare that pattern with known application flows so you can separate normal retries or pagination from systematic reconstruction of identity records.
Common mistake: Treating each call in isolation. Aggregation almost always hides in the relationship between calls, the breadth of endpoints touched, and the degree to which the requester is converging on a reusable identity graph rather than consuming one service function.
Identity Threat Detection and Response (ITDR) Guide is useful when you want to translate those patterns into detection logic for identity-driven abuse. For teams that need broader governance context, Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a useful anchor for proving that repeated access, ownership, and visibility are governance issues, not just log-analysis problems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Identity aggregation often relies on overbroad object access across user-linked records. |
| API8 — Security Misconfiguration | Predictable responses and overly verbose fields can make aggregation and correlation easier. | |
| API9 — Improper Inventory Management | Aggregation often exploits forgotten or undocumented endpoints that widen the searchable identity surface. | |
| Recommendation — Audit object access paths and block requests that can traverse identity-linked records without authorization. Reduce response verbosity and harden API defaults that expose reusable identity data. Inventory exposed endpoints and remove or protect routes that expand identity discovery. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Aggregation is best detected by correlating repeated request patterns across endpoints and time. |
| AC-6 — Least Privilege | Overbroad access makes it easier to collect linked identity data across many API objects. | |
| Recommendation — Correlate API logs for sequential enumeration and identity-field harvesting patterns. Limit API access so clients can only retrieve the fields and records they truly need. | ||
Practitioner Guidance
What to prioritise: Start with request correlation, endpoint diversity, and field-level inspection. A single suspicious user-agent is rarely enough on its own, but repeated sequential requests across identity-like fields are enough to justify deeper review.
What to measure: Track how often a client expands from one object type to another, how many distinct identity-linked fields it touches, and whether its access pattern is converging on a stable cross-endpoint dataset. Those signals are more useful than raw request count.
Practitioner takeaway: The best indicator is not that an API exposes identity-like data, but that a client is systematically assembling that data into a reusable profile. Once the traffic starts looking like correlation rather than consumption, treat it as an abuse pattern and not a routine integration.
Related resources from NHI Mgmt Group
- Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
- What is the difference between prompt injection risk and identity abuse in agents?
- Should organizations develop SLAs for NHI alert responses?
- Why do non-human identities increase identity blast radius?