Application security assessments now need SaaS and AI supply chain scope

At a glance

What this is: Vorlon argues that application security assessment has to expand from owned software into SaaS and AI ecosystems because blind spots now sit in permissions, data flows, and runtime behaviour.

Why it matters: IAM, AppSec, and cloud security teams need this shift because third-party integrations and AI tools can carry the same access and data exposure risk as code they directly control.

Context

Application security assessment is no longer just a review of code quality or vulnerability counts. The real problem is that modern application ecosystems now include SaaS platforms, AI tools, shadow APIs, and integrations that security teams cannot inspect the way they inspect software they build and own, which changes how risk is measured and governed.

That matters for identity and access management because the most consequential assessment gaps often show up in permissions, tokens, delegated access, and data-sharing paths rather than in source code alone. For teams running IAM, PAM, and NHI programmes, the relevant question is whether application risk scoring includes the identities and access routes that third-party services use at runtime.

Key questions

Q: What breaks when application security assessments do not include SaaS and AI integrations?

A: They miss the places where real risk now concentrates: permissions, data flows, and runtime behaviour outside the owned codebase. That leaves teams with a false sense of coverage because the application may be clean while a connected service, token, or shadow API still exposes sensitive data or enables unauthorized actions.

Q: Why do third-party SaaS tools and AI services create application security blind spots?

A: Because teams usually cannot inspect their code, infrastructure, or full logs, so the assessment shifts from direct testing to indirect evidence. Security teams have to judge configuration, delegated permissions, OAuth scopes, data-sharing rules, and behavioural anomalies instead of assuming traditional AppSec tooling will reveal everything.

Q: How do security teams know if contextual vulnerability management is working?

A: It is working when teams can answer three questions quickly: what can reach this asset, what identities does it trust, and what can an attacker reach from it if it is compromised. If those answers are still manual, slow, or incomplete, then the programme is still operating as a severity queue rather than a risk model.

Q: Should organisations treat SaaS and AI connections as part of the application estate?

A: Yes. If a service can read data, call APIs, or trigger workflows, it is functionally part of the application estate and must be assessed that way. The governance boundary should follow trust and access, not ownership alone, because attackers exploit the seams between systems, not just the systems themselves.

Technical breakdown

Why raw vulnerability counts miss ecosystem risk

A vulnerability list tells you what is technically wrong, but not what is most likely to hurt the business. Contextual assessment adds exploitability, data sensitivity, exposed trust boundaries, and operational dependency to the score. That matters because a medium-severity flaw in a high-value SaaS integration can be more damaging than a critical issue in an isolated environment. In modern app estates, the attack surface includes APIs, third-party connectors, tokens, and runtime behaviour, so the assessment model has to follow the data and the trust path, not just the codebase.

Practical implication: score application risk by business context and access path, not by vulnerability severity alone.

How SaaS and AI tools change the assessment model

Traditional AppSec methods assume visibility into code, infrastructure, logs, and test environments. SaaS and AI services break that assumption because the customer often has only configuration access, limited telemetry, and vendor-defined controls. That means assessment shifts from code review to outside-in evaluation: OAuth scopes, API permissions, data flows, behaviour anomalies, tenant boundaries, and retention settings become the primary evidence. For AI tools, prompt handling, data reuse, and integration behaviour also matter because model interaction can become a data leakage path even when the application itself is not directly owned.

Practical implication: assess third-party applications through permissions, data movement, and runtime behaviour rather than source access.

Why API security and broken access control dominate this problem

The article’s risk list puts broken access control, API security issues, authentication failures, and AI-driven attacks at the centre of the problem. That is because third-party ecosystems tend to fail at the seams: overbroad scopes, weak authorization boundaries, shadow APIs, and business logic abuse let actors do things the original design never intended. In identity terms, those seams often involve human and non-human identities using credentials that were issued for convenience rather than tightly bounded tasks. Once that access exists, assessment has to verify whether the permission model matches the actual data and action pathways.

Practical implication: review scopes, object-level authorization, and delegated access as first-class AppSec controls.

Threat narrative

Attacker objective: The attacker aims to exploit weak ecosystem boundaries to access data, abuse workflows, or hijack actions without needing to compromise owned application code directly.

1. Entry begins through third-party SaaS integrations, AI tools, shadow APIs, or mis-scoped credentials that expose data and actions outside the owned codebase.
2. Credential or authorization abuse follows when overbroad OAuth scopes, weak access control, or poor session handling lets an actor move beyond intended permissions.
3. Impact appears as unauthorized data access, privilege escalation, data leakage, or workflow manipulation across the application ecosystem.

Breaches seen in the wild

• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.
• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.

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

NHI Mgmt Group analysis

Ecosystem assessment is now the real AppSec discipline: organisations no longer secure a single codebase, they secure a mesh of applications, identities, APIs, and data-sharing relationships. That changes the unit of analysis from vulnerability management to trust-boundary management, because the most serious failures now happen where services and permissions connect. Practitioners should treat SaaS and AI integrations as part of the application estate, not as peripheral exceptions.

Application security and identity governance are converging: the article’s most important signal is that assessment quality now depends on knowing which human and non-human identities can act inside the ecosystem. OAuth scopes, service accounts, delegated tokens, and AI-connected access paths are no longer implementation details, they are assessment inputs. This makes NHI governance a core AppSec concern, not a separate discipline, because identity scope is often the control that determines whether third-party access is tolerable.

Contextual scoring is the named concept practitioners should adopt: severity alone is too blunt for ecosystems that mix owned software, SaaS, and AI tools. A contextual score must combine exploitability, business impact, data sensitivity, and reach across integrations, otherwise teams will keep fixing the wrong things first. The practical conclusion is to make risk ranking reflect operational consequence, not scanner output volume.

Shadow APIs and hidden integrations are the governance gap: the article shows that undocumented interfaces and unmanaged connections create attack paths that traditional AppSec reviews miss. Those paths are especially dangerous when they sit behind third-party services that inherit trust from the primary application. Security teams should assume that any unreviewed integration can become an access path until proven otherwise.

Continuous monitoring matters because these ecosystems change faster than annual reviews: the article explicitly notes that high-risk sectors need continuous assessment, and that is the right direction of travel. SaaS and AI tools change scopes, behaviours, and data flows without the visibility teams expect from owned software. The governance lesson is to move from periodic validation to ongoing assurance across permissions, runtime behaviour, and data movement.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.

What this signals

Contextual scoring is becoming the practical control model: assessment programmes that still rank issues mainly by scanner severity will continue to miss the exposures that matter most in SaaS and AI ecosystems. The better model is to combine exploitability, business impact, and trust-boundary reach so remediation effort follows actual risk, not just technical noise.

Application security now depends on identity visibility: once third-party services and AI tools can act inside the environment, access scope becomes a security control, not an admin detail. Teams that cannot explain which human and non-human identities can act across integrations will struggle to prove that their AppSec programme is complete.

Secrets management remains underweighted in many programmes: secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security 45%, API security 42%, and endpoint security 36%, according to the 2024 State of Secrets Management Survey. That ordering is a warning sign for ecosystem security because integrations, tokens, and delegated access are exactly where SaaS and AI risk concentrates.

For practitioners

• Map the full application ecosystem Inventory owned applications, SaaS tools, AI services, APIs, data stores, and third-party integrations so assessment scope matches the real attack surface.
• Score risk with business context Rank findings by exploitability, data sensitivity, business impact, and trust-boundary exposure instead of relying on raw vulnerability counts.
• Review OAuth scopes and delegated access Check whether third-party tools and connected services hold permissions that exceed their actual task requirements, especially for data access and action permissions.
• Test for shadow APIs and business logic abuse Look for undocumented interfaces, GraphQL exposure, automated workflow abuse, and actions that bypass intended authorization paths.
• Build continuous assurance around runtime behaviour Monitor integration behaviour, data movement, and unusual access patterns so changes in SaaS and AI services are detected after deployment, not only at review time.

Key takeaways

• Application security assessment is shifting from single-application testing to ecosystem risk management because third-party services now participate in the attack surface.
• Identity and access controls are central to that shift, since permissions, delegated tokens, and integration scopes often determine whether a connected service becomes a security problem.
• Contextual scoring is the decisive improvement, because teams need to prioritise by exploitability, data sensitivity, and business impact rather than by scan output alone.

Key terms

• Contextual Risk Scoring: A decision model that combines multiple signals, such as device integrity, app tamper evidence, location, and transaction value, to estimate the risk of a specific action. For mobile banking, it is more defensible than binary blocking because it evaluates the situation rather than only the device state.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to connect access control with broader security programmes. It gives identity and security teams a common foundation for managing the permissions that third-party services and AI-connected systems rely on.