Polymarket data exposure shows how public APIs enable identity aggregation

At a glance

What this is: This is an analysis of an alleged Polymarket data exposure that appears to involve aggregation of public API and blockchain-derived metadata, not a confirmed backend breach.

Why it matters: It matters because API-driven platforms can still create identity and privacy risk even when no internal system is penetrated, which is directly relevant to IAM, NHI, and access governance programmes.

By the numbers:

• The incident allegedly involved more than 10 million records and approximately 300,000 user-associated identities.
• Polymarket processed over $4.9 billion in trading volume in early 2026 alone.

👉 Read Gurucul's analysis of the alleged Polymarket data exposure

Context

API exposure is a governance problem when public endpoints, on-chain data, and user metadata can be combined into identity intelligence at scale. In this case, the core question is not only whether a breach occurred, but whether the platform’s public data surface made user correlation too easy for an attacker to automate.

For identity teams, the lesson extends beyond Web3. Any environment that exposes reusable identity signals through APIs, tokens, public metadata, or federated attribution creates an aggregation layer that can be exploited without defeating a perimeter. That is a familiar NHI problem, even when the subject looks like a platform incident rather than a classic credential compromise.

Key questions

Q: What breaks when public APIs expose too much identity metadata?

A: Public APIs become a source of identity intelligence rather than just application functionality. Attackers can enumerate records, correlate stable identifiers, and enrich the results with external data. The result is deanonymisation, profiling, and targeting even when no internal system is compromised. Security teams should assess what can be reconstructed, not only what can be directly accessed.

Q: Why do public metadata and blockchain-linked identities increase privacy risk?

A: Because they create a durable correlation layer. Even when individual data points are non-sensitive, repeated access to public records can link wallet activity, platform behaviour, and external OSINT into a coherent profile. That profile is often more valuable than a single stolen record and can support phishing, social engineering, and surveillance.

Q: How can security teams tell whether an API is enabling large-scale scraping?

A: Look for sequential request patterns, repeated access across related endpoints, high-frequency lookups from the same source, and unusually broad traversal of records. If those behaviours can assemble a meaningful identity dataset faster than expected, the endpoint is enabling extraction. Rate limits alone are not enough if the returned metadata remains highly joinable.

Q: Who is accountable when exposed platform data can be assembled into user profiles?

A: Accountability sits with the platform owner and the teams governing data exposure, access design, and identity minimisation. If public or lightly protected endpoints can be combined into a profiling dataset, the issue is not just abuse by an external actor. It is a governance failure in how the data surface was designed and approved.

Technical breakdown

How public API aggregation turns metadata into identity intelligence

Public APIs often expose small pieces of data that look harmless in isolation, such as usernames, wallet references, timestamps, profile attributes, or activity records. At scale, those fragments can be enumerated, joined, and enriched into a usable identity graph. The technical risk is not the presence of one endpoint, but the ease with which endpoints can be queried repeatedly, correlated across sources, and merged with blockchain data or OSINT. That turns exposure into reconnaissance material even when no backend compromise exists.

Practical implication: inventory public endpoints and test whether repeated requests can reconstruct user identity or activity patterns.

Why rate limiting and authentication are not the same control

Rate limiting slows abuse, but it does not change what the endpoint reveals. Authentication can restrict access, but it also needs policy design that distinguishes harmless operational queries from high-value enumeration. If an API returns enough metadata to support correlation, an attacker does not need to break in. They only need enough access to automate collection and enough visible structure to join the results. This is why exposure assessments must examine data value, not only access method.

Practical implication: treat high-value metadata fields as governed assets and reduce what public or lightly authenticated APIs disclose.

Blockchain-linked identity exposure creates a durable correlation layer

When on-chain records, public platform metadata, and external sources can be stitched together, pseudonymity weakens quickly. The issue is persistence: blockchain-linked identifiers are difficult to change, so once correlation is built, the resulting profile can survive long after the original dataset is stale. That makes the exposure more than a one-time privacy issue. It becomes a repeatable intelligence source for profiling, phishing, and behavioural mapping.

Practical implication: assess whether your identity model allows durable correlation across public data sources and immutable external identifiers.

Threat narrative

Attacker objective: The likely objective is to turn public and semi-public identity signals into a reusable intelligence dataset for profiling, monetisation, or targeted abuse.

1. Entry occurs through large-scale enumeration of publicly accessible API endpoints and collection of on-chain identity data rather than a confirmed intrusion into internal systems.
2. Escalation happens when automated extraction combines platform metadata, wallet attribution, and external enrichment to build a much larger identity graph than any single source reveals.
3. Impact follows in the form of profiling, deanonymisation, social engineering enablement, and reconnaissance for future attacks against affected users.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public data aggregation is a governance failure when identity signals remain machine-readable at scale. This incident appears to sit closer to exposure-by-enumeration than backend compromise, but that distinction does not reduce the identity risk. When API output, blockchain attribution, and user metadata can be assembled into a profile, the governance problem is the amount of identity intelligence the system makes available without any meaningful friction. Practitioners should treat public data minimisation as an identity control, not a privacy afterthought.

Metadata minimisation is the named control gap here, because the exposed value was correlation, not access. The article’s own evidence points to automated collection of public data and on-chain attribution rather than exploitation of a secret or defect. That means the security failure is a design assumption that public equals low-risk. In practice, public fields can become privileged once they support clustering, deanonymisation, and targeting. The implication is that exposure review must focus on joinability, not just visibility.

API-driven platforms now carry an identity blast radius that looks more like NHI sprawl than traditional data leakage. Once user-associated records can be queried, recombined, and enriched automatically, the attack surface is governed by how much identity context the platform emits per request. That is the same structural issue IAM and NHI teams face when service accounts and tokens disclose too much by default. Practitioners should align API governance with identity governance, because enumeration is now part of the access model.

Decentralised identity correlation changes the privacy and threat model for any system built on public attestations. The more the ecosystem relies on reusable identifiers, the easier it becomes to link behaviour across sessions and services. That does not require advanced intrusion capability, only persistence and scale. The implication for security programmes is straightforward: if identity data can be stitched together externally, your exposure boundary is already wider than your access boundary.

Reconnaissance value is now a first-order outcome of exposed metadata, not a secondary concern. The incident shows how attackers can convert user-visible platform information into targeting lists, behavioural profiles, and social engineering inputs. This is especially relevant where identity is tied to financial activity or pseudonymous participation. Practitioners should evaluate public data surfaces as intelligence assets in the hands of an attacker, not as neutral interface conveniences.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs , Key Challenges and Risks.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity exposure persists without clear ownership or control.
• That visibility gap is why practitioners should also read the NHI Lifecycle Management Guide for offboarding, rotation, and access-review patterns that reduce residual exposure.

What this signals

Identity intelligence is becoming the new extraction target. When public APIs, metadata fields, and external identifiers can be combined cheaply, the security question shifts from whether data is public to whether it is joinable. That shift mirrors a broader NHI pattern: the problem is rarely one secret in isolation, but the ease with which many small exposures become one large profile.

With 79% of organisations already reporting secrets leaks and 77% of those incidents causing tangible damage, per the Ultimate Guide to NHIs, governance has to treat exposed data paths as active security surfaces. Public access is not the same as low-risk access, especially when the output can be recombined into identity intelligence.

Exposure minimisation is now part of identity architecture. Teams that design APIs, wallet attribution flows, or public metadata views need to think like adversaries who collect, correlate, and persist data over time. That is why NHI controls such as visibility, lifecycle review, and data minimisation increasingly overlap with traditional IAM and privacy disciplines.

For practitioners

• Map joinable identity fields across public APIs Identify which fields can be combined to reconstruct user identity, wallet attribution, activity history, or behavioural patterns. Prioritise endpoints that return stable identifiers, timestamps, or relationship data, and classify them as exposure-sensitive assets rather than ordinary application output.
• Reduce metadata returned by unauthenticated or lightly authenticated endpoints Remove fields that are not operationally necessary, especially those that enable correlation across systems. Where data must remain available, separate presentation data from enrichment data and require stronger access controls for the richer view.
• Test for automated enumeration and scraping behaviour Monitor for sequential requests, high-frequency access from single sources, and repeated lookups across related endpoints. Use these tests to validate whether a determined actor can assemble identity data at scale without triggering controls.
• Treat blockchain-linked identifiers as durable exposure risk Review how public or pseudonymous identifiers can be linked back to named users or repeatable behaviours through external datasets. Where correlation is easy, assume the resulting profile can be reused for phishing, profiling, or later-stage targeting.

Key takeaways

• Publicly accessible data can still create serious identity risk when APIs and external signals make correlation easy.
• The scale described in the incident shows that aggregation, not intrusion, can be enough to produce a high-value intelligence dataset.
• Practitioners should treat metadata minimisation, endpoint governance, and enumeration monitoring as part of identity security, not just application hygiene.

Key terms

• Metadata Aggregation: The process of combining many small, often non-sensitive data points into a richer identity or behavioural profile. In security analysis, the risk is not any single field, but the ability to correlate fields across systems, sessions, or public sources to reveal more than the owner intended.
• Identity Correlation: The linking of separate identifiers, records, or behaviours to the same person, wallet, account, or device. It matters in API and Web3 environments because correlation can expose patterns, relationships, and histories even when no system breach occurs.
• Exposure Surface: The set of data, endpoints, and signals that can be observed or queried by an external party. For identity security, the exposure surface is broader than the access surface because publicly visible fields can still be abused for recon and profiling.

What's in the full article

Gurucul's full blog post covers the operational detail this post intentionally leaves for the source:

• The sample-data correlation steps used to compare public API output with the circulated dataset.
• The specific monitoring activities Gurucul recommends for detecting automated enumeration and scraping.
• The full list of exposed-data risks tied to wallet deanonymisation, profiling, and behavioural mapping.
• The recommended defensive actions for rate limiting, authentication, and anomaly detection at the API layer.

👉 Gurucul's full post covers the exposure mechanism, detection opportunities, and recommended monitoring activities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.