SaaS security now depends on customer-facing controls and APIs

At a glance

What this is: This is a shared-responsibility analysis of SaaS security capabilities, arguing that customer-facing APIs, logging, and documentation are now essential for access governance and incident response.

Why it matters: It matters because IAM, IGA, PAM, and security operations teams cannot govern SaaS access they cannot see, enumerate, or review, especially across large SaaS estates.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Valence Security's blog on SaaS security capabilities and shared responsibility

Context

SaaS security breaks down when customers are expected to govern access and investigate events without the telemetry, APIs, or account-level visibility needed to do either. In practice, that creates an identity governance gap: the platform may be secure internally, but the tenant remains opaque to the team responsible for access review, logging, and incident triage.

This is especially relevant for NHI governance because SaaS platforms increasingly expose service accounts, API access, and tenant-level permissions that security teams must control as identities, not just settings. If a vendor does not make those identities visible and reviewable, customers cannot apply basic lifecycle discipline or prove that least privilege is actually working.

Key questions

Q: What breaks when a SaaS platform does not expose account and configuration APIs?

A: Access governance becomes guesswork. Security teams cannot reliably enumerate accounts, review roles, or validate configuration at scale, so least privilege, recertification, and offboarding lose operational meaning. In practice, that means the customer can own the risk but not the evidence needed to control it.

Q: Why do missing SaaS logs create an identity governance problem?

A: Because access review and incident response both depend on evidence. If authentication events, admin actions, and permission changes are absent or incomplete, teams cannot reconstruct who accessed what, when, or how. That turns governance into assumption rather than verification.

Q: How should security teams evaluate a SaaS security vendor for enterprise use?

A: Security teams should evaluate whether the vendor fits existing governance workflows, produces audit-ready evidence, and enforces access controls that limit blast radius. Compliance credentials matter, but they should be treated as baseline proof, not a substitute for testing how the platform handles data segregation, admin privilege, and incident response in practice.

Q: What is the difference between SaaS configuration and SaaS governance?

A: SaaS configuration is the on or off state of a feature. SaaS governance is the policy, ownership, monitoring, and cleanup process that determines whether the feature can be used safely. A disabled setting may reduce exposure, but only governance ensures identities, content, and exceptions are managed over time.

Technical breakdown

Customer-facing APIs for SaaS identity and configuration

SaaS security capability is not just about internal platform hardening. It also depends on whether the customer can query accounts, permissions, and configuration through APIs without resorting to privileged admin access. In an identity context, those APIs become the control plane for visibility: they determine whether teams can inventory non-human identities, verify role assignment, and detect drift. If the API only exposes partial data, governance becomes approximation rather than control.

Practical implication: require API access that supports full account enumeration, permission review, and configuration validation before approving a SaaS platform.

Logging depth and event fidelity in SaaS environments

Logging determines whether a SaaS platform can support detection, investigation, and accountability. Security teams need events for authentication, permission changes, API activity, admin actions, and configuration changes, plus enough context to reconstruct who changed what and when. Missing event types are not a minor telemetry gap. They directly prevent access review, incident scoping, and evidence preservation. In SaaS, incomplete logs often mean incomplete governance because the identity actions that matter most are the ones that disappear first.

Practical implication: validate log coverage against the exact identity and admin actions your team relies on for monitoring and forensics.

Why documentation is a control surface, not a support artifact

Documentation is part of operational security because it determines whether teams can configure controls correctly and consistently. When security features are undocumented, hidden behind unsupported settings, or described in ways that confuse administrators, customers misconfigure access and monitoring. That problem is common in SaaS because the vendor controls the interface, but the customer owns the risk. Good documentation shortens time to secure adoption and reduces the chance that security features remain unused or partially deployed.

Practical implication: treat documentation quality as a procurement criterion alongside API and logging coverage.

Threat narrative

Attacker objective: The attacker wants to turn poor SaaS governance into account takeover, data access, or undetected abuse of tenant permissions.

1. Entry occurs through weak customer configuration or insufficiently exposed security controls, rather than through a software exploit in the platform itself.
2. Escalation follows when attackers exploit missing MFA adoption, over-permissioned admins, or unseen API access paths that the customer cannot enumerate.
3. Impact arrives as unauthorised access, tenant data exposure, or delayed detection because the platform does not provide enough reviewable evidence.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Customer visibility is now part of the control surface, not an optional integration. SaaS vendors often frame APIs and logs as convenience features, but the governance reality is harsher: without them, customers cannot enumerate identities, validate entitlements, or prove least privilege. That makes the platform’s exposed security surface a shared-responsibility requirement, not a usability preference. Security teams should treat missing tenant visibility as a control deficiency, not an implementation inconvenience.

Shared responsibility fails when the vendor controls the evidence and the customer owns the risk. This article describes a common SaaS governance mismatch: the vendor may secure its own service, but the customer still needs usable data to manage access and investigate abuse. When logs are incomplete or account inventories are hidden, auditability collapses before remediation even begins. The implication is straightforward: an identity programme cannot govern what it cannot observe.

Programmes that separate SaaS security from identity governance are already behind. SaaS access is increasingly identity infrastructure by another name because service accounts, API tokens, and administrative roles all behave like NHIs. That means procurement, onboarding, recertification, and offboarding must include platform-level requirements for visibility and revocation. Teams that still treat SaaS controls as an application-security side issue will keep missing the lifecycle risks that live inside the tenant.

Identity blast radius is the right named concept for SaaS governance. A platform with weak account enumeration, broad admin requirements, or missing audit logs expands the blast radius of every misconfiguration. The core issue is not merely exposure, but the inability to bound and verify that exposure across many apps and many tenants. Security teams should evaluate SaaS products by how narrowly they contain identity blast radius, not by how many features they advertise.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which shows how thin operational assurance remains.
• The NHI Lifecycle Management Guide helps teams connect visibility, rotation, and offboarding into one governed lifecycle model.

What this signals

SaaS procurement is becoming identity procurement. Security teams that cannot demand tenant-level visibility, event fidelity, and account enumeration will keep inheriting blind spots that no downstream control can fully recover from. The practical shift is to treat API exposure and audit logging as minimum viable governance, not optional integration polish.

Identity blast radius: this is the SaaS control problem that now matters most. When a platform hides identities or events, it increases the number of apps and workflows affected by a single misconfiguration, which makes vendor selection a governance decision as much as a technical one.

For teams building programme evidence, the right reference point is the NIST Cybersecurity Framework 2.0 paired with control-level validation through the NIST SP 800-53 Rev 5 Security and Privacy Controls. That combination gives procurement, operations, and audit a common language for evaluating SaaS visibility and logging.

For practitioners

• Require tenant-level account and permission visibility Make API access to accounts, roles, and security settings a procurement gate. If a SaaS product requires full administrator entitlements just to enumerate access, it is already weakening governance.
• Test log completeness before rollout Validate that the platform records authentication events, admin changes, permission updates, and API activity with enough context for incident response and access review.
• Map SaaS identities into lifecycle processes Include service accounts, tokens, and privileged tenant roles in joiner-mover-leaver and recertification workflows so they are reviewed like other non-human identities.
• Use documentation as a security acceptance criterion Reject SaaS platforms whose security features are poorly documented, hard to discover, or inconsistent across admin interfaces and APIs.

Key takeaways

• SaaS security becomes a governance failure when customers cannot see accounts, permissions, and events well enough to review them.
• Missing APIs and incomplete logs do not just reduce convenience, they block access certification, investigation, and accountability.
• The right vendor question is whether the platform exposes enough control surface for lifecycle management, not whether it has strong internal hardening.

Key terms

• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Tenant Visibility: Tenant visibility is the ability to inspect accounts, permissions, activity, and configuration inside a SaaS tenant without unsupported workarounds. It is a prerequisite for access review, incident response, and lifecycle governance because teams cannot certify what they cannot observe.
• SaaS Security Capability Framework: A shared control baseline for SaaS platforms that describes the minimum security capabilities customers should be able to verify. In practice, it gives procurement, security, and audit teams a common way to compare logging, permissions, APIs, and incident support across vendors.

What's in the full article

Valence Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Specific examples of SaaS platforms that fail to expose account inventories without elevated admin access
• The draft SaaS Security Capabilities Framework baseline capabilities and how vendors are expected to implement them
• Why missing logs break access review, investigation, and tenant-level accountability in practice

👉 Valence Security's full post covers the SaaS capability gaps, procurement implications, and control requirements in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.