Notifications
Clear all
Topic starter
02/08/2026 12:14 pm
TL;DR: SaaS sprawl, over-permissioned apps, and shadow AI are shifting security incidents toward identity and access decisions inside cloud platforms, with one example showing more than 2,000 AI apps in active use and risky connections handled through automated investigation and remediation. The governance gap is no longer visibility alone, but whether teams can turn identity context into enforceable action fast enough.
NHIMG editorial — based on content published by torq: AMP'd Sessions Episode 6 on SaaS access risk with Reco
By the numbers:
- Enterprises often have more than 2,000 AI apps in active use, many granted through social logins, with wide-open access to sensitive data.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
Questions worth separating out
Q: How should security teams govern access across SaaS sprawl?
A: Security teams should govern SaaS sprawl with one inventory, one policy model, and one review process that covers both human and non-human access.
Q: Why do shadow AI tools create identity risk for IAM programmes?
A: Shadow AI creates identity risk because hidden tools often inherit access through secrets, service accounts, or delegated APIs without review.
Q: What do security teams get wrong about SaaS spend visibility?
A: They often mistake visibility for control.
Practitioner guidance
- Inventory SaaS and AI app connections continuously Build a current inventory of sanctioned and unsanctioned SaaS apps, OAuth grants, and AI tools connected by users.
- Classify OAuth grants as access events Treat third-party consent, app installation, and scope expansion as identity governance events that deserve review.
- Enrich alerts with identity and data context Route SaaS risk alerts with the user role, app trust status, permission set, and sensitivity of the targeted data.
What's in the full article
Torq's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step walkthrough of the Reco-to-Torq SaaS access response flow for detection, approval, and revocation.
- Demonstrated case handling logic for risky AI app connections and identity-enriched investigation.
- Operational examples of autonomous remediation decisions and audit logging across collaboration platforms.
- Role-based workflow handoff details showing how managers, analysts, and policy checks fit into the response path.
👉 Read torq's AMP'd Session on SaaS access risk and autonomous response →
SaaS access risk and shadow AI: what IAM teams need to change?
Explore further
02/08/2026 1:17 pm
SaaS access governance is now an identity problem before it is a SOC problem. The article shows that the important decision is not whether an alert exists, but whether a user or app connection should have been allowed to inherit that level of access in the first place. That means SaaS governance, OAuth oversight, and identity review are now the front line of control, not a follow-up step after detection.
A few things that frame the scale:
- Enterprises often have more than 2,000 AI apps in active use, many granted through social logins, with wide-open access to sensitive data, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an approved app exposes regulated data?
A: Accountability usually sits with the organisation that allowed the app, not the app store or the vendor alone. Security, mobility and compliance teams all share responsibility for verifying behaviour, documenting the basis for approval and enforcing policy when the app violates that basis. That audit trail is what regulators will examine.
👉 Read our full editorial: SaaS access risk shows why identity-driven SOC workflows matter
