Notifications
Clear all
Topic starter
25/08/2026 9:13 am
TL;DR: Security posture management now has to cover cloud, SaaS, identity, data, APIs, and AI agents because point-in-time audits miss a continuously changing attack surface, according to Salt’s analysis. The real shift is from checking configuration state to governing drift, ownership, and continuous monitoring across machine-speed interactions.
NHIMG editorial — based on content published by Salt: security posture management across cloud, identity, SaaS, data, and APIs
By the numbers:
- 40% of all data breaches involved data distributed across multiple environments, underscoring how difficult it is to govern a fragmented attack surface.
- 80% of data security breaches are caused by misconfigurations, according to Gartner.
- 87% of organizations use multicloud environments, and 72% operate in hybrid cloud configurations.
Questions worth separating out
Q: How should security teams govern posture across cloud, SaaS, identity, and API layers?
A: They should treat posture as one control system with multiple signals, not separate programmes.
Q: Why do point-in-time audits fail to protect modern identity programmes?
A: Because audits prove that evidence existed at one moment, not that the control remained effective after deployment changes.
Q: What breaks when API posture governance is missing in AI environments?
A: Visibility breaks first, then enforcement.
Practitioner guidance
- Unify posture inventory across identity and infrastructure Create a single view of cloud assets, SaaS applications, service accounts, machine identities, and exposed APIs so drift is assessed in context rather than by domain silos.
- Prioritise remediation by attack path, not alert volume Use correlated findings to rank the exposures most likely to be exploited across identity, configuration, and data layers, then assign owners for closure.
- Treat APIs as governed identity surfaces Inventory public, internal, partner, and shadow APIs, then review authentication, authorisation, and secret handling as part of your access governance process.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- A deeper breakdown of CSPM, SSPM, ISPM, DSPM, ASPM, and KSPM coverage boundaries
- The article’s explanation of how NIST CSF 2.0 and continuous monitoring map to posture programmes
- Salt’s examples of posture management across the API layer and AI-agent-connected workflows
- The source article’s discussion of why posture management is a practice rather than a product
👉 Read Salt’s analysis of security posture management across cloud, identity, and APIs →
API and AI agent posture gaps: is your security program keeping up?
Explore further
25/08/2026 9:14 am
Security posture management is no longer a cloud-only discipline. The article correctly shows that posture now spans identities, APIs, SaaS, data, and AI-connected workflows. That widens the operating model for IAM teams because access, configuration, and data exposure now move together. Practitioners should treat posture as a cross-domain governance layer, not a point solution category.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How can organisations tell whether posture analytics are actually working?
A: Look for shorter remediation cycles, fewer stale entitlements, lower rates of rubber-stamped reviews, and better evidence quality during audits. If dashboards are growing but decisions are not improving, posture analytics are only documenting risk instead of reducing it.
👉 Read our full editorial: Security posture management now extends into API and AI agent risk
