You miss the moment when an approved configuration becomes risky during live execution. Services can drift, identities can be misused, and data paths can widen after deployment. Scan-time posture is necessary, but it does not show whether an application is behaving safely under real workload conditions.
Why Scan-Time Posture Misses the Real Risk
Scan-time tools are good at answering a narrow question: what did the environment look like at the moment of assessment? That is useful, but it leaves a gap between approval and execution. In cloud and agentic systems, identities can be reused, secrets can remain valid too long, and workloads can change their behaviour after deployment. The risk is not only misconfiguration, but live drift and unintended privilege expansion.
That gap is visible in incident data. In The 2026 Infrastructure Identity Survey, 70% of organisations said they grant AI systems more access than they would give a human employee doing the same job. That matters because a posture scan may show a policy is approved while real-time execution is already exceeding the intended trust boundary. Current guidance in the NIST Cybersecurity Framework 2.0 points teams toward continuous risk management, not one-time certification.
In practice, many security teams discover the problem only after a workload has already used standing access to widen its blast radius.
How It Works in Practice
Closing this gap requires shifting from static posture checks to runtime identity and policy enforcement. For NHI and agentic workloads, that means treating the workload itself as the security subject, not just the host, container, or repository. A scan can still validate baseline settings, but live controls must decide whether a specific action should be allowed right now.
That usually combines several layers. First, workload identity should be explicit and cryptographically verifiable, so the system knows what is acting. Second, authorisation should be context-aware, using request time signals such as task, destination, data sensitivity, and time window. Third, credentials and secrets should be short-lived and issued just in time, so a previously approved path does not remain open indefinitely. This is especially important for agents, which can chain tools, retry actions, and pursue goals in ways that are hard to predict from a single scan.
- Use runtime policy checks to decide whether the action matches current intent, not just declared role.
- Issue ephemeral credentials for specific tasks instead of relying on long-lived static secrets.
- Bind access to workload identity and expected execution context.
- Log and alert on drift between approved posture and actual behaviour.
The mechanics are visible in real incidents such as the Codefinger AWS S3 ransomware attack and the Azure Key Vault privilege escalation exposure, where identity and secret handling failures mattered as much as the original configuration. These controls tend to break down when workloads are highly autonomous and share secrets across services because the effective trust boundary changes faster than scan cadence.
Common Variations and Edge Cases
Tighter runtime controls often increase operational overhead, requiring organisations to balance protection against latency, policy complexity, and incident response speed. There is no universal standard for every environment yet, especially where platform teams are still mapping how to apply intent-based authorisation to agents and event-driven services. Best practice is evolving, but the direction is clear: reduce standing privilege, shorten credential lifetime, and evaluate access at the moment of use.
Edge cases show up when teams rely on inherited permissions, third-party integrations, or opaque SaaS workflows. For example, a posture scan may confirm that a storage account or secret store is locked down, but an attached automation token can still be used later to exfiltrate data or widen access. That is why continuous monitoring must include identity events, not only network or configuration findings. The Snowflake breach and the 230M AWS environment compromise both reinforce a simple point: approved posture does not guarantee safe execution when credentials and access paths outlive their intended use.
Current guidance suggests pairing scan-time controls with runtime enforcement, but organisations with legacy IAM, shared service accounts, or long-lived API keys will need a staged rollout rather than a big-bang replacement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Long-lived secrets and standing access are the core failure mode here. |
| OWASP Agentic AI Top 10 | Agent behaviour can diverge after scan time, requiring runtime controls. | |
| NIST AI RMF | AI governance must cover behaviour during operation, not only approved design. |
Continuously assess AI risks across deployment, use, and monitoring rather than at launch only.
