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.
What breaks in the assessment model when SaaS and AI integrations are excluded?
Assessment scope breaks first. A clean codebase can still sit beside risky connector permissions, delegated tokens, third-party workflows, and AI features that can read, transform, or emit data outside the application boundary. If the review only covers owned code, it misses where permissions, data movement, and runtime behaviour are actually being exercised.
That matters because modern application exposure often sits in the integration layer, not in the app’s core pages or APIs. SaaS connectors can inherit broad OAuth scopes, while AI integrations can introduce tool calls, prompt-driven actions, and data propagation paths that were never part of the original threat model.
When those dependencies are omitted, the assessment no longer tells you whether the system can leak data, over-act on a user’s behalf, or retain access long after the business need has changed. It only describes the app in isolation, which is no longer the real system.
Which risks are typically missed?
The most common gap is authorisation drift. Tokens, grants, and connector scopes can exceed the app’s intended privileges, and the effective access may belong to the integration rather than to the software team that owns the product. That is why OAuth app and SaaS-to-SaaS governance deserves explicit review, not just a note in the architecture diagram, as shown in SaaS-to-SaaS and OAuth App Governance Guide.
A second gap is data-path blindness. SaaS tools can copy, enrich, index, or forward information into systems with weaker controls, and AI integrations can do the same through prompts, memory, and tool outputs. That creates exposure even when the originating application is well built. The issue is not only what the app stores, but what its integrations are allowed to observe and export.
A third gap is runtime trust. In integrated environments, behaviour changes after deployment: a connector can gain new permissions, an AI assistant can invoke a tool differently, or a shadow app can appear with a valid token. That is why integration-centric threat examples matter, such as SalesBleed Salesforce Agentforce 2026, where the issue was not the host application alone but the way an AI-enabled SaaS workflow could be induced to leak data and act under the agent’s identity.
Why does this change the security conclusion?
Because the security boundary moves. Traditional application security assumes you can meaningfully evaluate the app by testing its code, endpoints, and configuration. With SaaS and AI integrations, the boundary extends to external permissions, delegated access, third-party data handling, and runtime decisions made outside the app owner’s direct control. A connected service can therefore become the real control plane.
This is why appsec assessments need to examine connector inventory, granted scopes, token lifetime, human approval paths, and the business flows that integrations can trigger. The question is not only whether the app is vulnerable, but whether the integration graph can create unauthorized action or data exposure without a classic code defect.
For AI-connected systems, the same logic applies to agent tooling and delegated authority. If the integration can search mail, modify records, send messages, or expose files, then the assessment must verify what the tool can touch, what it can return, and how the action is constrained. A useful practitioner lens is the Agentic AI Security Guide, which treats tools, orchestration, and identity as part of the attack surface rather than as post-deployment accessories.
Risk and Threat Considerations
When SaaS and AI integrations are excluded, the main risk is false assurance. Teams may believe they have assessed the application, while the highest-risk paths actually sit in delegated access, third-party connectors, and automated runtime actions that can move data or trigger business functions.
Failure mechanism: A connector, token, or AI tool receives broader access than the core application itself needs, then uses that access to read, copy, transform, or act on data outside the intended trust boundary. Because the activity is performed through a seemingly legitimate integration, it can evade both code-focused review and weakly scoped monitoring.
Impact: Sensitive data can leave the owned application, unauthorized actions can be executed under trusted credentials, and revoked business need may not remove the effective access. The result is hidden blast radius, poor revocation hygiene, and a security assessment that underestimates the real exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Integration scope and delegated actions change authorization boundaries for the app. |
| V10 — OAuth and OIDC | SaaS integrations and tokens depend on OAuth consent, scope and token handling. | |
| Recommendation — Verify authorization boundaries for every connected service and delegated action. Review OAuth consent, scope, and token lifecycle for each integration. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI integrations can overreach through delegated identity and excessive tool privilege. |
| Recommendation — Constrain agent identity and tool privilege to the minimum required actions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Connectors and shadow APIs can enable actions beyond intended business permissions. |
| Recommendation — Test every integration action for function-level authorization gaps. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Connected services often inherit excessive access relative to the app's need. |
| Recommendation — Reduce integration access to the minimum permissions needed for the workflow. | ||
Practitioner Guidance
What to verify: Confirm that the assessment inventory includes all SaaS connectors, OAuth grants, AI assistants, agent tools, and shadow integrations, not just the application’s own endpoints. If a service can read or write business data, it belongs in scope.
Decision rule: If the integration can act with delegated authority, assess the permissions, token lifetime, and revocation path before you decide whether the application is “secure enough.” If those controls are weak, the integration is the finding, even when the core app passes.
What good looks like: The assessment can show who owns each integration, what data it can access, what actions it can perform, and how quickly access can be removed. If that cannot be answered in one review cycle, the assessment boundary is still too narrow.
Practitioner takeaway: Modern appsec fails when it stops at owned code, because the meaningful security question has shifted to who can move data and take actions through connected services.
Related resources from NHI Mgmt Group
- How should security teams govern bearer tokens used by AI agents and SaaS integrations?
- What breaks when organisations do not map the access path of AI and SaaS integrations?
- What breaks when AI agent security is handled like ordinary application security?
- What breaks when AI dependencies are not included in application security reviews?