How we built AI-powered attack surface management in-house

Key Takeaways

• A well-defined security methodology, encoded as a reusable AI skill, can run reconnaissance and analysis at a scale no manual review matches, without adding tools, licenses, or headcount.
• AI can execute the mechanical work of an assessment — enumeration, correlation, evidence gathering — but exploitability and severity calls stay with a human at every validation gate.
• Combining an outside-in view, an inside-out view, and threat intelligence gives a genuinely complete picture of exposure, rather than three disconnected reports.

Every security team hits the same wall eventually: the number of exposed subdomains, APIs, and product surfaces keeps growing faster than any team can manually review. The reflex response is to buy more: more scanning tools, more licenses, more analysts. That fixes the budget line, not the problem.

The Product Security team at Precisely took a different route. Rather than add another vendor to the stack, the team built AI-powered attack surface management directly into how it works: a structured methodology, encoded as a skill an AI model can load and run, that thinks through an external assessment the way a senior security engineer would.

This isn’t a scanner, and it isn’t a dashboard. It’s a codified way of thinking, built so a model can execute it end to end while a human makes the calls that matter most: what’s exploitable, and what’s just noise.

What makes traditional attack surface management fall behind?

Most attack surface programs run on a familiar cycle: periodic scans, a report, a backlog, and a gap until the next cycle. That cadence made sense when product surfaces changed slowly, but it doesn’t hold up against how fast modern engineering organizations ship. New subdomains, APIs, and integrations appear continuously, and dev or proof-of-concept environments get stood up and forgotten just as fast.

The usual fix is to add tools or people. Both help at the margin, but neither solves the underlying issue: attack surface management is fundamentally a judgment problem, not a coverage problem. Pointing a scanner at a target is easy. Knowing what a result means, whether it chains into something serious, and when to stop digging is the real skill. That skill has historically lived only in the heads of experienced security engineers, which makes it slow to scale.

That’s the gap the team set out to close: not more scanning, but a way to scale the judgment itself.

How do you turn a security methodology into an AI skill?

There’s a meaningful difference between an instruction and a methodology. An instruction tells an AI model what to do. A methodology tells it how to think.

The team encoded the full external assessment approach into a structured skill file: how to sequence phases, how to prioritize what to check first, what a per-endpoint review should cover, and how individual findings connect into a larger attack chain. When a model loads that skill, it behaves closer to how a senior security engineer works: running tools, interpreting output, reassessing as evidence builds, and constructing a structured report along the way.

The harder problem was keeping a human in the loop without slowing everything down. The answer was a layered controls and human validation before reporting rather than a checkpoint at every tool call. Before any finding makes it into a report, it has to clear two questions: Is there a working reproduction that confirms the behavior? And does it feed, amplify, or complete a larger attack chain?

The value is in the methodology, not the model. Encode the right approach, give it the right context, and it executes at a scale and speed no human team can match. But it doesn’t replace the judgment call at the end, that part stays human.

A model can run a scan. Without the methodology behind it, it won’t know what the result means.

What does an AI-led assessment involve?

An assessment like this moves through a handful of broad categories rather than a single scan:

• Reconnaissance and mapping: building a current picture of what’s exposed: subdomains, live hosts, technology stacks, and how everything is organized.
• Authentication and API surface review: looking at how sign-on, session, and API endpoints are exposed and protected.
• Client-side exposure review: checking what production code reveals about the systems behind it.
• Live validation: testing every finding by hand, with a working reproduction, rather than trusting an automated pass or fail.
• Infrastructure expansion: following the trail into connected infrastructure and regional environments that don’t always show up through standard discovery.

Live validation is where the process earns its credibility. In practice, testing regularly changes the picture: some findings get downgraded once someone tries to reproduce them, others turn out to be more serious than they first looked. That’s by design. The skill is built to generate hypotheses that get stress-tested, not automated checks that just return a pass or fail.

Assessment Impact

What does this approach typically uncover?

The categories of exposure this kind of assessment tends to catch are consistent across most fast-moving organizations, and they’re the ones conventional periodic scanning tends to miss:

• Authentication surfaces like SSO, OAuth, and login endpoints that don’t get the same scrutiny as the core product, especially in pre-production environments.
• API documentation and developer tooling left reachable from the outside, which hands anyone who finds it a map of the internal API surface.
• Information leaking through client-side code: production builds that ship more detail than intended about how a system is put together.
• Legacy infrastructure that keeps running long after the product it supported has moved on, often with weaker controls than anything built more recently.

None of these require a sophisticated attacker to find; they require someone who’s looking systematically and consistently, rather than on a fixed audit cycle. That’s the pattern this approach is built to catch.

How do outside-in, inside-out, and threat intelligence work together?

External assessment covers what’s publicly reachable. It doesn’t cover what’s already leaked, or what’s misconfigured behind the perimeter, so the team built two more layers to go with it.

The first runs the other direction: inside-out. An automated pipeline pulls high- and critical-severity findings from the team’s cloud security posture management tooling across its cloud environments, then applies a ground-truth exposure filter that checks the specific details that determine reachability — public IP presence, storage bucket access policies, endpoint accessibility, routing configuration — so what reaches the team is confirmed exposure, not everything a scanner flagged as theoretically risky. That filter turned out to be the most important design decision in the whole pipeline: without it, the signal gets buried under findings that are technically true but not exploitable from the internet.

The second is threat intelligence: monitoring breach databases, infostealer sources, and dark web forums, cross-referenced against the company’s domains, infrastructure, and email patterns. The output classifies automatically, separating low-priority signal — an employee’s email turning up in an unrelated third-party breach — from high-priority signal, like credentials captured directly from a compromised device. The high-priority cases trigger an immediate response: password resets, session invalidation, and a review of what that device could reach.

Together, the three layers answer three different questions: what’s reachable from the outside, what’s misconfigured on the inside, and what’s already out there.

Maintaining a strong commitment to trusted data

There’s more to build here. The team is expanding into persistent tracking that flags drift on already-known assets, and paying closer attention to development and proof-of-concept endpoints. Both are common blind spots across the industry, worth watching regardless of how mature an attack surface program already is.

The bigger pattern holds regardless of company size: an attack surface is always larger than anyone assumes, and the only way to really know what’s exposed is to look systematically and continuously, not on a fixed audit cycle. AI changes the economics of that work. It doesn’t change who makes the call on what’s genuinely risky. That judgment, built from experience and context, stays human.

Explore how security work fits into the broader trusted data commitment at Precisely in the Trust Center.