$37M for AI Attack Path Hunting: How to Start Mapping Your Own Infrastructure

A Security’s $37M raise is interesting because it points to a real shift in how defenders buy security: not just more alerts, but better visibility into how an attacker can move from one weak point to a high-value target.

I read funding news like this as a signal, not a victory lap. The basic problem has not changed: most environments already have too many identities, too many trust relationships, and too many systems that were connected “temporarily” and never cleaned up. What has changed is the attacker side. AI does not create new bugs out of thin air, but it does make recon, relationship stitching, and path enumeration cheaper. That means the old assumption — “if we patch the obvious exposure and watch the perimeter, we are fine” — gets weaker every month.

The sensible response is attack-path hunting: build a graph of your own environment, then ask one very specific question over and over, “If an attacker starts here, what can they reach next, and what control stops them?”

Why $37M for attack-path hunting matters now

What AI-assisted attackers change about defender assumptions

The practical change is volume and speed.

A human operator used to spend a lot of time just figuring out where to look: which cloud account mattered, which SaaS app was tied to production, which service principal had a weird level of access, which group nesting led to admin rights. AI-assisted workflows compress that work. Even when the attacker still needs skill, they can automate the boring parts:

• enumerate accounts and exposed services
• map naming patterns across cloud, directory, and SaaS
• correlate leaked credentials with likely reuse targets
• summarize trust relationships from public metadata and internal misconfigurations

That matters because defenders often treat these relationships as “indirect.” They are not indirect once they connect to production, secrets, or admin consoles.

The good news is that the same automation can help defenders. A graph-based view is a natural fit for machines: collect nodes, collect edges, normalize identity, score paths, and run checks whenever something changes.

Why perimeter thinking fails once identities and SaaS are connected

Perimeter thinking assumes you can draw a hard line around the environment. In a modern stack, that line is already broken by design:

• employees log into cloud and SaaS from unmanaged devices
• workloads call other workloads using tokens, not just IP addresses
• group membership grants roles across several systems
• secrets move through CI/CD pipelines and runtime environments
• third-party integrations hold durable access that looks like internal trust

That is why “blocked at the firewall” is usually a weak explanation. An attacker does not need to cross the perimeter if they can reuse an identity, abuse a delegated permission, or ride a trusted integration.

The report about A Security raising $37M is a reminder that this is now a product category, not just a consultant slide deck. Teams are spending money because the old control model is too flat. Attack paths turn the environment into something you can reason about.

The practical promise of attack-path mapping, not just alerting

Alerting tells you something bad happened, or might be happening.

Attack-path mapping tells you something more useful for prevention: which chain of trust would make the bad thing possible in the first place.

That changes prioritization:

• a vulnerability on an isolated lab host is lower value than a weakly protected identity that leads to prod access
• a SaaS account with no downstream privileges is less urgent than one that can reset MFA or read secrets
• an overbroad role assignment may matter more than ten medium-severity CVEs

If you can see the path, you can decide whether to break it by removing an edge, hardening a control, or isolating the target.

Define the graph before you collect the data

Nodes: assets, identities, workloads, secrets, and control planes

I usually start by deciding what counts as a node. If you skip this, the inventory turns into a pile of CSVs with no shared language.

A practical minimum is:

The point is not perfect taxonomy. The point is consistency. If the same thing appears as a “user” in one dataset and an “account” in another, you need a canonical identity layer before the graph becomes useful.

Edges: login, trust, network reachability, role assignment, and data access

Edges are the real value. They describe what can lead to what.

Common edges include:

• logs_into
• member_of
• assumes_role
• can_call
• can_read
• can_write
• reachable_from
• trusts
• rotates_secret_for
• administers

A login edge is not the same as a role edge. A network edge is not the same as data access. Attack-path hunting works because it keeps these relationships separate.

For example, a developer laptop may be able to log into the identity provider, which grants access to a cloud console, which can assume a role, which can read a secret, which authenticates to a production database. None of those edges looks dramatic by itself. Together, they are the path.

What is a real attack path versus a noisy relationship

Not every relationship should be treated as an exploitable path.

A noisy relationship might be:

• an inactive group membership inherited from an old project
• a network route that exists but is blocked by conditional access
• a shared library or vendor integration with no meaningful privilege
• an artifact of data import, not an actual permission

A real attack path usually has three properties:

1. It starts from a plausible initial access point.
2. Each step grants new privilege, reachability, or control.
3. The final node is worth the effort: prod data, billing, secrets, admin control, or a high-impact workload.

If you cannot explain why each edge matters operationally, it probably does not belong in the attack-path model.

Build an inventory from the sources that already exist

Cloud IAM and org hierarchy data

You do not need to begin with a perfect scanner. Start with the systems that already own authority.

For AWS, Azure, and Google Cloud, that means pulling:

• accounts, projects, subscriptions, and folders
• users, roles, service principals, and managed identities
• group memberships and role bindings
• inline policies and attached policies
• trust policies and delegated admin relationships
• key metadata such as last-used timestamps and credential age

The important part is hierarchy. Attack paths often move through the org structure before they hit a workload. A role in one account may be able to assume another role through a trust policy. A folder-level grant may silently cover more resources than the team expected.

If you only inventory “resources” without the org structure, you will miss the edges that matter most.

Endpoint, directory, and SaaS telemetry

Cloud data is only half the picture. A lot of real paths begin at an identity provider, endpoint, or SaaS app.

Useful sources include:

• directory logs from Entra ID, Okta, or similar providers
• endpoint management data from MDM or EDR
• device compliance and sign-in risk state
• SaaS admin logs for GitHub, Google Workspace, Slack, Atlassian, and ticketing systems
• browser or session telemetry where allowed and appropriate

This data tells you whether an account is merely present or actually usable. It also helps separate abandoned access from active access.

One thing I look for is “admin by convenience” behavior: a user who can reset MFA, invite external users, create tokens, or manage app integrations in a SaaS platform. Those capabilities often become stepping stones to deeper access.

CI/CD, secrets, and service-account metadata

The path from developer tooling to production is one of the most common blind spots.

Inventory:

• pipeline definitions
• build agents and runners
• environment variables and secret references
• deployment keys and signing certificates
• service accounts used by jobs
• artifact registries and publish permissions

A pipeline is not just a build system. It is often a credential broker. If a CI job can read a secret and deploy to prod, that is an edge. If that same job can be modified by a broad set of developers, the path becomes much more dangerous.

Service accounts deserve special attention because they are often under-monitored and over-permissioned. They do not complain, they do not rotate themselves, and they often outlive the human teams that created them.

Handling stale, duplicate, and partially trusted records

Real inventories are messy. Expect these problems:

• duplicate identities across systems
• stale group memberships
• inactive service principals still holding permissions
• assets that were decommissioned but still appear in logs
• partially trusted records from third-party integrations
• conflicting timestamps between source systems

Do not delete these records too aggressively. Mark them with confidence and freshness metadata instead.

A simple approach is to attach fields like:

• source
• last_seen
• confidence
• authoritative_system
• status

That keeps the graph honest. A path through two high-confidence edges is more interesting than a path built on stale data imported six months ago.

Normalize identity and privilege relationships

Map human users, service principals, and machine identities separately

This is one of the most common modeling mistakes: treating all identities as if they behave the same way.

They do not.

• Human users can be phished, MFA-fatigued, or socially engineered.
• Service principals can be over-granted and rarely reviewed.
• Machine identities may be short-lived but highly privileged.
• Break-glass accounts are unusual and should be treated as exceptional.

If you flatten these together too early, you lose the attacker model. The route from a phished user to a service principal is different from the route from a compromised workload to another workload.

Keep the identity classes separate, then connect them through explicit relationships.

Collapse inherited permissions and group nesting into effective access

The permission model an operator sees is rarely the permission model the system enforces.

A user may get access through:

• direct role assignment
• nested groups
• inherited org or folder grants
• project-level overrides
• delegated admin paths
• temporary elevation that was never removed

You want effective access, not just declared access.

A useful rule is: if a principal can act because of multiple overlapping grants, reduce them to the minimum explanation that still describes the real path. This makes the graph easier to query and easier to explain to an engineer.

For example, if user-a is in group-b, and group-b has a role on project-c, then the edge you care about is not merely “belongs to group.” It is “can administer project-c through group-b.” That is the security-relevant fact.

Spot privilege amplification across cloud, SaaS, and admin consoles

Privilege amplification is where the graph earns its keep.

Some common amplifiers:

• a SaaS admin can reset a cloud identity provider password
• a cloud role can read a secret used by a deploy bot
• a GitHub maintainer can modify CI workflows that mint production tokens
• a helpdesk role can trigger account recovery or MFA reset
• an internal portal can grant access to a separate admin console

These are not exotic attacks. They are ordinary trust relationships that become dangerous when combined.

The key question is: does the edge increase the set of reachable privileges? If yes, it belongs in the path model.

Model the paths an attacker actually follows

Initial access paths from exposed services, phishing, and credential reuse

Start with plausible footholds, not fantasy ones.

Common initial access sources include:

• exposed login pages and password reset flows
• phishing-resistant gaps, such as legacy auth or app passwords
• credential reuse from previous breaches
• public APIs with overly broad client credentials
• forgotten admin panels or partner portals
• remote access systems with weak conditional access

The point is not to model every theoretical exploit. The point is to model the entry points your environment actually presents.

A path hunt should answer: if someone starts with one valid identity or one exposed service, how far can they get before a meaningful control stops them?

Lateral movement through trust edges and delegated permissions

Once inside, lateral movement usually follows trust.

Look for:

• delegated permissions across tenants or projects
• assumed roles in other accounts
• shared credentials in automation
• read access to deployment metadata or source control
• write access to configuration that controls another system

This is where many environments are fragile. Teams treat internal trust as if it were low-risk because it is “inside.” But once an attacker has an internal identity, trust edges become transport.

The interesting part is not the movement itself. It is whether the trust edge was intended, necessary, and bounded.

Privilege escalation through overbroad roles and token reuse

Privilege escalation does not always mean exploit code. Often it is just bad role design.

Examples include:

• roles that can list or read secrets they do not need
• tokens that can be reused longer than their purpose
• administrator roles with no condition on device, location, or session risk
• workflows that let a low-privilege user create a high-privilege token indirectly
• service accounts that can mint access for other systems

Token reuse is especially dangerous because it blurs intent. A token issued for build automation may end up working in a place it never should have reached.

The graph should capture token origin, scope, and lifetime. Without that, you cannot distinguish “temporary high trust” from “permanent high risk.”

Impact edges that reach crown-jewel systems or sensitive data

A path only matters if it reaches something valuable.

Common crown jewels include:

• production databases
• billing systems
• secrets managers
• CI/CD signing keys
• customer data exports
• admin consoles
• cloud organization control planes

When I score a path, I care more about whether it touches one of these targets than whether it traverses a lot of systems. A short path to a secrets manager is worse than a long path to a non-sensitive wiki.

Prioritize by blast radius, not by raw vulnerability count

Scoring entry points by reachable privilege gain

Vulnerability counts are a weak prioritization signal. A single exposed identity can be more important than ten low-risk findings.

A better score asks:

• What can this principal reach?
• How many steps until it reaches a privileged node?
• Does it cross trust boundaries?
• Does it unlock secrets, admin controls, or prod data?
• How many systems inherit the impact?

You can think of this as “reachable privilege gain.”

A path that upgrades a session from user to helpdesk-admin is more urgent than a path that only reaches another ordinary app.

Ranking paths by exposure of production data, billing, or secrets

When ranking, I would prioritize targets in this order:

1. secrets and signing material
2. cloud org or tenant admin
3. production data stores
4. deployment and release systems
5. billing and finance systems
6. internal collaboration systems

That is not universal, but it is a sane starting point.

The reason is simple: once secrets or admin control are exposed, the blast radius multiplies. One bad path can explain several incidents, not just one.

Separating theoretical paths from reachable paths in your environment

This distinction matters a lot. A graph can produce frightening-looking routes that are not actually usable because of one missing condition.

Examples:

• the target role exists, but MFA is required and enforced
• the service account exists, but the secret is rotated and no longer valid
• the path depends on a group membership that was removed last week
• a network route exists, but the application enforces device posture
• a SaaS admin capability is visible, but the account has just-in-time approval

Do not ignore theoretical paths, but label them correctly. A reachable path is a current defense problem. A theoretical path is a configuration review candidate.

A concrete walk-through: from one exposed account to a high-value target

Start with a public login or API foothold

Here is a safe, realistic example.

Assume you have a public SaaS login for a customer portal or partner system. The account is low privilege, but it can authenticate successfully. From that start, you map outward:

• the account belongs to a partner group
• the partner group is assigned access to a support dashboard
• the support dashboard can request account recovery actions
• the support workflow can trigger MFA reset in the identity provider
• the identity provider session can access an admin console
• the admin console can read a secrets reference needed by a deployment pipeline

That is a real path shape. The specific products will differ, but the structure is common.

The key point is that the foothold was not a vulnerability in the classic sense. It was valid access with surprising reach.

Follow role assumptions, tokens, and group memberships

In practice, I would trace the path by asking four questions at each hop:

1. What identity is acting here?
2. What new authority did it gain?
3. Is the authority direct, inherited, or delegated?
4. What token, session, or group membership makes it possible?

That is usually enough to expose the hidden chain.

A small script can help you represent the path as adjacency edges:

const graph = new Map();

function addEdge(from, to, type) {
  if (!graph.has(from)) graph.set(from, []);
  graph.get(from).push({ to, type });
}

addEdge("partner-user", "support-dashboard", "member_of");
addEdge("support-dashboard", "idp-mfa-reset", "can_trigger");
addEdge("idp-mfa-reset", "admin-console-session", "unlocks");
addEdge("admin-console-session", "secret-reference", "can_read");
addEdge("secret-reference", "deploy-pipeline", "authenticates");

function walk(start, seen = new Set()) {
  if (seen.has(start)) return;
  seen.add(start);
  for (const edge of graph.get(start) || []) {
    console.log(`${start} --${edge.type}--> ${edge.to}`);
    walk(edge.to, seen);
  }
}

walk("partner-user");

This is not a security product. It is a sanity check. If you can express the path in this small a form, your real graph model is probably on the right track.

Confirm which controls break the chain and which do not

Every step should have a control attached to it.

Ask whether the control actually blocks the path:

• Does MFA block the session, or can it be reset through support?
• Does conditional access deny the admin console from unmanaged devices?
• Does the secret have a short TTL?
• Can the pipeline only read a scoped credential, or can it mint broader access?
• Is the support workflow audited and approval-gated?

Often the answer is “we thought so, but not fully.”

That is the value of path hunting. It converts vague trust into testable checkpoints.

Record the path in a form engineers can reproduce

A good finding is not a screenshot. It is a reproducible chain with minimal assumptions.

I like a record that includes:

• starting node
• required preconditions
• edge sequence
• controls that failed to stop it
• final impact
• recommended fix
• verification method after remediation

Example format:

Start: partner-user in external tenant
Path:
1. partner-user can open support-dashboard
2. support-dashboard can trigger idp-mfa-reset
3. reset grants admin-console-session
4. admin-console-session can read secret-reference
5. secret-reference authenticates deploy-pipeline

Impact: access to production deployment credentials

Fix: remove support-triggered MFA reset, require approval + step-up auth, rotate exposed secret, scope pipeline secret to one workload
Verify: repeat the path check and confirm the session no longer reaches admin-console-session

That is the kind of artifact an engineering team can act on.

Safe implementation patterns for your own infrastructure

Queries and scripts for building a minimal relationship graph

You do not need a giant platform to begin.

A simple ingestion loop can work:

1. export IAM, directory, and SaaS metadata
2. normalize identifiers
3. write edges into an adjacency list or graph database
4. compute reachable nodes from selected starting points
5. rank paths by target sensitivity

A minimal adjacency model in JavaScript might look like this:

const nodes = new Map();
const edges = [];

function upsertNode(id, data) {
  nodes.set(id, { ...(nodes.get(id) || {}), ...data });
}

function addEdge(from, to, relation, confidence = 1) {
  edges.push({ from, to, relation, confidence });
}

upsertNode("user:alice", { type: "human", source: "idp" });
upsertNode("role:prod-read", { type: "role", source: "aws" });
upsertNode("secret:deploy-key", { type: "secret", sensitivity: "high" });

addEdge("user:alice", "role:prod-read", "member_of", 0.95);
addEdge("role:prod-read", "secret:deploy-key", "can_read", 0.9);

That is enough to start asking useful questions.

Example checks for AWS, Azure, Google Cloud, and SaaS access

I would focus on questions like these:

• AWS: who can assume a role that can read Secrets Manager or modify IAM?
• Azure: which principals can reset users, manage apps, or read directory roles?
• Google Cloud: which groups map to project owners or workload identity federation?
• SaaS: who can create tokens, reset MFA, install apps, or export data?
• CI/CD: who can edit workflows, variables, runners, or deployment environments?

You do not need every API on day one. Start with the permissions that can change identity, secrets, or deployment control.

Using graph databases or simple adjacency lists without overengineering

Graph databases are useful when the environment is large and the questions are complex. But do not overbuild too early.

A simple adjacency list can work if:

• your environment is small to medium
• you only need a handful of path queries
• you are still validating your edge model
• you want the fastest route to useful output

Use a graph database if you need:

• multiple hop queries across many systems
• path ranking and centrality
• historical snapshots
• interactive exploration by analysts

The important thing is not the storage engine. It is whether you can answer: “What changed, what is reachable now, and what should not be reachable?”

How to cut attack paths once you can see them

Remove unused trust edges and stale privileges

The cleanest fix is often to delete the edge entirely.

Look for:

• old groups with no current owner
• roles that were created for a one-time migration
• dormant integrations with persistent credentials
• service accounts that still have access after a project ended
• redundant admin paths that duplicate another control

If nobody can explain why a trust edge exists, it probably should not.

Add conditional access, MFA, JIT access, and workload isolation

Controls that actually reduce path reachability include:

• conditional access with device and risk checks
• phishing-resistant MFA for high-value identities
• just-in-time elevation for admin tasks
• session-bound tokens with short TTLs
• workload isolation between build, staging, and prod
• separate admin planes for support and production operations

The key is to make each edge harder to reuse. A path that requires step-up auth and human approval is much less attractive than one that works with a reused session cookie.

Protect secrets, service accounts, and break-glass credentials

Secrets are often the shortest path to the worst outcome.

Defend them by:

• storing them in a real secret manager, not environment sprawl
• scoping them to one service or one workflow
• rotating them automatically
• blocking long-lived broad credentials
• auditing who and what can read them
• keeping break-glass access rare, monitored, and rehearsed

Break-glass accounts deserve special handling. They should not be part of ordinary path scoring unless they are actually usable, because when they are, the blast radius is huge.

Add logging that proves whether the path is still possible

A path is not really fixed until you can prove it is broken.

Useful evidence includes:

• denied login or role-assumption events
• failed secret reads
• blocked token minting
• conditional-access denials
• approval logs for JIT elevation
• audit trails for admin actions and recovery workflows

If your logs do not show the attempted step, your graph will drift from reality. Verification is part of the control.

Operationalize it so the graph stays useful

Run path checks on a schedule and after identity changes

Attack-path data ages quickly.

Run checks:

• nightly or weekly for high-value systems
• immediately after IAM changes
• after SaaS admin changes
• after CI/CD permission updates
• after org or tenant restructuring

If you only review paths during an audit, the graph becomes a museum piece.

Tie findings to tickets, ownership, and remediation SLAs

A path finding should land somewhere actionable.

Every finding should carry:

• owner team
• affected systems
• severity or blast radius
• expected fix type
• SLA or remediation target
• verification step

If ownership is unclear, the issue will stall. The graph is only useful when it can route work.

Track whether the same path reappears after fix cycles

This is where teams separate one-off cleanup from real control improvement.

Track:

• whether the same path returns after a new integration
• whether a removed edge reappears under a different name
• whether a new SaaS app creates an equivalent privilege chain
• whether temporary exceptions become permanent again

A recurring path is usually a design smell, not a missed ticket.

Conclusion: mapping paths is the defensive work that scales

The $37M raise around A Security is notable because it validates a practical truth: defenders need to see how trust connects, not just where the next alert fires.

If you only remember one thing, make it this: an attack path is a chain of ordinary permissions that becomes dangerous when connected. AI makes that chain easier for attackers to discover. Your job is to make it easier for your team to see, rank, and break first.

What teams should do first this week

Start small:

1. Pick one crown-jewel system.
2. List the identities and services that can reach it.
3. Normalize those identities across cloud, directory, SaaS, and CI/CD.
4. Build the first path graph with confidence and freshness metadata.
5. Remove one stale trust edge or overbroad privilege.
6. Re-run the path check and confirm the edge is gone.

That is enough to get value without buying a platform on day one.

Where the A Security funding story fits into a broader control strategy

The funding story is a market signal, but the control strategy is bigger than one vendor. Attack-path hunting works best when it is treated as a continuous engineering discipline:

• model trust explicitly
• verify effective access, not just declared access
• prioritize blast radius
• fix the shortest dangerous paths first
• keep the graph updated as identities change

That is the defensive posture that scales when attackers automate more of their reconnaissance. If you can map your own infrastructure honestly, you are already ahead of the teams still hoping the perimeter will hold everything together.