Attack surface discovery is becoming core to modern threat defence

At a glance

What this is: This is a security analysis of why attack surface discovery has become foundational as threats now emerge from unknown, unmanaged, and fast-changing assets.

Why it matters: It matters to IAM, PAM, NHI, and broader security teams because discovery is what links assets, identities, privileges, and exposure before attackers exploit the gap.

By the numbers:

• Vulnerability exploitation reached 20% of breaches in 2025, a 34% year-over-year increase, according to Verizon's 2025 DBIR.
• 73% experienced a security incident caused by unknown or unmanaged assets, according to Trend Micro's 2025 research.
• 48.9% of organisations are entirely blind to machine-to-machine traffic and cannot monitor the AI agents already running in their environment, according to Salt Security's 1H 2026 research.
• 87% of organisations were hit by API attacks in 2025, according to Akamai's SOTI 2026 report.

👉 Read Xygeni's analysis of attack surface discovery and modern security threats

Context

Attack surface discovery is the practice of continuously finding and cataloging every asset an organisation owns or touches so that exposure can be assessed against a complete picture rather than a partial inventory. In modern environments, that matters because the primary security threat is often not a novel exploit but an unknown or unmanaged asset, including APIs, dependencies, and AI agents that were never added to a formal register.

This article frames the problem as a visibility and governance gap, not a tooling gap. For IAM and NHI teams, the intersection is direct: every undocumented API, service account, token, or agent expands the identity and access surface even when it is not treated as an identity programme asset. That makes continuous discovery a prerequisite for governance, not an optional add-on.

The starting position described here is increasingly typical in software and cloud environments. What changes is the pace, as ephemeral assets, machine-to-machine traffic, and AI-introduced dependencies make point-in-time inventories obsolete almost immediately.

Key questions

Q: How should security teams implement attack surface discovery across cloud and development environments?

A: Start with continuous enumeration, not periodic scans. Connect cloud inventories, CI/CD pipelines, dependency data, and runtime telemetry so newly introduced assets are discovered as they are created. Then attach ownership, sensitivity, and access-path data so the output becomes actionable governance, not another disconnected asset list.

Q: Why do unknown assets create both security and compliance risk?

A: Unknown assets cannot be patched, retired, audited, or assigned confidently. That creates a dual failure: security teams miss exposed systems, while compliance teams lack defensible evidence of control over software, hardware, and licence usage.

Q: What do security teams get wrong about governing AI agents?

A: They often treat agents like another automation layer instead of governed non-human actors with their own access paths. Once an agent can connect to tools and data at runtime, the programme needs attribution, scoped privileges, and lifecycle oversight. Otherwise, the agent becomes an unreviewed extension of the enterprise access model.

Q: Why do IAM and NHI teams need to care about vulnerability discovery?

A: Because vulnerabilities become far more dangerous when they expose credentials, service accounts, or privileged workflows. IAM and NHI teams control who or what can move after a flaw is found, how far it can move, and how quickly access can be revoked. That makes identity governance part of exploit containment.

Technical breakdown

Why blind spots turn into active threat surface

A blind spot becomes attack surface the moment an attacker can reach it but defenders cannot see or classify it. In practice, that includes forgotten staging systems, shadow APIs, orphaned dependencies, and AI tooling introduced outside formal change control. The core technical issue is not discovery alone, but discovery that keeps pace with deployment velocity and asset churn. Without continuous enumeration, classification, and ownership mapping, security teams are always validating yesterday's environment while today's exposure is already live.

Practical implication: teams need continuous discovery workflows tied to change events, not periodic inventories that lag behind deployment.

How attack surface discovery fits the SDLC

In software delivery, attack surface discovery has to follow the code path from commit to runtime. That means detecting open-source packages, CI/CD components, AI models, agents, and MCP servers as soon as they appear, then correlating each asset with reachable secrets, permissions, and data. This is where discovery moves from asset listing to governance: it reveals what an introduced dependency can touch, which identities it inherits, and where it widens privilege or exposure.

Practical implication: map new code and runtime components to the identities and secrets they can reach before promotion to production.

Why APIs and AI agents are now central discovery targets

APIs and AI agents are especially important because they expand machine-to-machine communication faster than traditional asset governance can absorb. An API can expose data without looking like a classic endpoint problem, and an AI agent can act as a new runtime identity with tool access, credentials, and delegated actions. That makes their discovery an identity issue as much as a cyber issue, because unmanaged access paths are still access paths even when the system is software-driven rather than human-driven.

Practical implication: treat AI agents, MCP-connected services, and undocumented APIs as governed access paths with explicit ownership and review.

Threat narrative

Attacker objective: The attacker aims to exploit the gap between what the organisation believes it owns and what is actually reachable, turning unmanaged assets into privileged access or data theft paths.

1. Entry occurs through an unknown or unmanaged asset such as a forgotten API, shadow dependency, or AI-enabled service that is not in the security team's authoritative inventory.
2. Escalation follows when that asset exposes credentials, trust relationships, or implicit permissions that defenders never mapped to a business owner or control boundary.
3. Impact arrives when the attacker uses the invisible path to reach data, move laterally, or trigger supply chain abuse before the organisation can detect the exposure.

NHI Mgmt Group analysis

Attack surface discovery is now an identity governance control, not just a visibility control. The article is correct that the gap between known and exposed assets is where modern threats thrive, but that gap also includes identities, secrets, and delegated runtime access. Once AI agents, service accounts, and undocumented APIs are treated as first-class assets, discovery becomes the control that makes IAM and NHI governance possible at scale. Practitioners should therefore treat discovery as a prerequisite to access governance, not a separate cyber programme.

AI-introduced assets create a new kind of governance debt: invisible access paths. An agent, MCP server, or generated dependency can exist long before it is formally owned, reviewed, or offboarded. That creates persistent exposure even when infrastructure looks clean on paper. The named concept here is discovery debt: the accumulated risk created when asset creation outpaces the organisation's ability to see, classify, and govern it. Teams should measure this debt explicitly rather than assuming inventory coverage is complete.

API and machine-to-machine visibility is becoming the limiting factor in cloud and application security. The article's emphasis on APIs aligns with broader evidence that machine traffic is harder to observe than human access, and that matters for IAM because every unmapped API is effectively an unmanaged entitlement surface. Where access is not centrally known, least privilege cannot be enforced with confidence. Practitioners should align discovery outputs to entitlement reviews, not just to asset dashboards.

Supply chain exposure belongs in the same governance model as internal asset sprawl. Open-source dependencies are not simply code artifacts; they are externally sourced trust relationships that can import identity, credential, and runtime risk into the build. The distinction matters because a package can become an access path even when the underlying infrastructure remains unchanged. Security teams should fold dependency discovery into the same control plane used for secrets, service accounts, and workload identity.

Continuous discovery is the practical enabler for Zero Trust and Zero Standing Privilege. Those models assume organisations can continuously validate what exists, who or what can reach it, and whether the access is still justified. Without discovery, both become aspirational rather than operational. The governance conclusion is straightforward: if the asset is unknown, the privilege attached to it is already outside control.

What this signals

Discovery debt will become a board-level governance issue wherever organisations rely on fast-moving cloud, API, and AI delivery. The practical signal is not how many assets exist, but how many cannot yet be tied to an owner, an identity, or a control boundary. Teams should expect security and platform operations to converge around a shared inventory layer rather than keep separate truth sets.

For identity programmes, the next maturity step is to make discovery output consumable by IAM, PAM, and NHI workflows. That means enriching assets with entitlement data, expiry status, and offboarding triggers so access review can focus on what is actually live. The most useful control is the one that turns unknowns into reviewable access paths before an incident does.

Machine-to-machine traffic and AI-connected services will continue to outpace manual governance unless organisations design for continuous validation. Reference controls such as the MITRE ATT&CK Enterprise Matrix and NIST SP 800-53 Rev 5 Security and Privacy Controls help, but only if discovery first reveals the full attack surface. The operational lesson is to measure coverage gaps as a risk metric, not a tooling metric.

For practitioners

• Establish continuous asset discovery across code, cloud, and runtime Instrument pipelines and runtime environments so new services, APIs, dependencies, and AI agents are detected as they appear, not at audit time. Feed discoveries into a single inventory with ownership, data sensitivity, and access paths attached.
• Map discovered assets to identities and secrets For each asset, identify the service accounts, tokens, certificates, and permissions it can use or inherit. Prioritise anything with standing privilege or no named owner, because those are the paths most likely to be abused.
• Correlate discovery with exposure and reachability Do not stop at listing assets. Tie each one to internet exposure, reachable data, and the controls that should constrain it, including segmentation, authentication, and approval boundaries.
• Bring AI agents and MCP-connected services into governance reviews Treat AI agents, MCP servers, and other machine-driven components as governed access paths. Require explicit registration, review, and offboarding so shadow AI does not become shadow access.

Key takeaways

• Modern security failures increasingly start with assets that were never formally discovered or governed.
• Attack surface discovery becomes especially important when APIs, AI agents, and dependencies create machine access paths faster than teams can review them.
• Identity and access programmes should consume discovery data directly, because unknown assets are usually unknown privilege.

Key terms

• Attack Surface Discovery: The process of finding and classifying assets that can be reached, tested, or abused by an attacker. In modern AppSec, discovery must be continuous because build pipelines, AI-assisted code, and microservice sprawl can change the attack surface faster than manual review can track.
• Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Discovery Debt: The gap between what an organisation believes it has in its data estate and what it can actually find and verify. Discovery debt weakens access control, retention, and AI governance because downstream policies depend on inventories that may already be stale.

What's in the full article

Xygeni's full article covers the operational detail this post intentionally leaves for the source:

• Concrete examples of how attack surface discovery applies across code, CI/CD, cloud, and runtime assets.
• The article's full breakdown of threat categories, including supply chain, API, AI-layer, and credential abuse patterns.
• Practical distinctions between discovery and management, including how findings should be prioritised and closed.
• The article's discussion of why blind spots grow in SDLC workflows and how that affects remediation timing.

👉 Xygeni's full article expands on blind spots, threat categories, and SDLC exposure patterns.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle fundamentals. It is built for practitioners who need to connect discovery, access, and governance across modern identity programmes.