Cloud Security Should Measure Authority Drift, Not Just Misconfiguration

Cloud security programs are very good at finding visibly wrong things: public storage, permissive firewall rules, unencrypted resources, disabled logging, or identities with administrator privileges. Those findings matter, but some of the most consequential cloud risks emerge even when no single configuration is obviously broken. The missing signal is often the relationship between otherwise valid configurations.

The deeper problem is authority drift. Over time, users, workloads, roles, policies, service accounts, trust relationships, and automation accumulate permissions that change what can reach what and who can act on which resource. Every individual change may be legitimate. The combined authority graph can still become far more powerful than anyone intended.

Cloud risk is relational.

A cloud resource does not carry all of its risk inside its own configuration. Its security depends on relationships. A storage bucket may be private but readable by a role that can be assumed from another account. A database may have no public endpoint but be reachable by a workload whose service identity can be impersonated. A serverless function may have a narrow purpose but hold permission to modify resources well outside that purpose.

This is why cloud posture cannot be understood by counting misconfigurations alone. Security teams need to know the effective paths created when identity, network access, resource policy, secrets, and workload permissions are combined. NIST’s August 2026 draft on multi-cloud architecture challenges makes this complexity explicit. It identifies identity and access management, telemetry, configuration and change management, data protection, and authorization as areas where security becomes harder across autonomous cloud environments. The useful lesson is that cloud control problems are often coordination problems between layers, not isolated mistakes in one console.

Permissions expand more easily than they contract.

Cloud access tends to get piled up as it is added as a solution to a current problem, and it is removed when it is no longer needed, but it caused another problem that still needs to be solved. A developer will be provided temporary access to the migration. Adds another action to support a deployment. A new service account would impede delivery, so this one is reused. A cross-account trust is an expanded trust during an incident and will never be reduced again.

All these decisions do not result in an alert. They cause authority debt: permissions which still exist when the original context has evolved. The key indicator is not just the number of identities that are overprivileged in a day, however. The extent to which effective control has moved away from the minimum necessary for the existing design.

Inherited authority is difficult to see in a single policy.

It is uncommon to have the authority to use the cloud expressed in one place. A user can receive group permissions and assume a role and receive conditions from an organization policy, interact with a resource policy, and call a workload with a service identity. Security reviews that look at individual policy documents may miss the path that can be created by them. The question of interest is whether action B (direct or delegated) can be achieved as a result of identity A on resource C.

That is a graph problem. A useful Cloud Security program should therefore model effective authority rather than merely enumerate attached permissions. It should identify indirect access, dormant trust relationships, cross-account paths, privilege escalation opportunities, and resources whose security depends on a surprisingly powerful intermediary.

Ephemeral infrastructure makes stale context dangerous.

Clouds are dynamic. Workloads scale, containers die, serverless functions redeploy, accounts reorganize, and services change. Identity/policy records may exceed the life of the resource or project for which they are created.

A role that is created for a temporary environment can continue to be assumed even after the environment is removed. The permissions are retained by the service identity when migrating the application. If a meaning has been altered, e.g. due to the other migration of the original workloads, then a network rule can still be open to a subnet.

Security context should thus have a temporal aspect. Teams should be aware of the date of creation for authority, when the authority was last used, which workload(s) are currently dependent on the authority, and whether the business purpose continues to exist. Unused permission is NOT just “untidy.” It is a path for an attack that will occur when a trusted relationship or credential is compromised.

Multi-cloud multiplies semantic differences

The challenge increases as organizations adopt multiple clouds. Identity, resource policy, networking, service accounts, and organizational boundaries are expressed differently on each platform. What is considered “read-only” in one control may not have a direct equivalent in another. One platform might assign permissions only to identities, while another might be more resource-oriented or service-specific based on roles. Central security teams can find themselves comparing apples and oranges – terms that are seemingly equal but have different impacts.

Hence, the importance of normalization. The security model should be able to map provider-specific permissions to higher-level capabilities: Read sensitive data, create credentials, alter network exposure, alter logging, assume another identity, alter recovery, deploy executable code. That abstraction lets people compare clouds without claiming they’re the same.

Security should watch authority-changing events.

Cloud monitoring focuses on changes in resources and on identifying threats in traditional cloud monitoring. Identity changes should be treated in the same manner, as they may add a new surface to attack, but it won’t be registered as a policy. High-value events include new trust relationships, grants of privileges, assumption of a role from a different source, changes to service identities, creation of long-lived keys, changes to organization-level policy, and permission changes on recovery or logging systems.

Discuss these events in the context of them. Raising privileges while deployment is probably to be expected. This is the same increase from an unknown administrative route – investigate.

The point is to identify changes in effective authority, not changes in configuration syntax. Those changes can be seen on the Authority telemetry. It also assists in differentiating from anticipated administration to secret privilege expansion.

Blast radius depends on authority chains.

Usually, the initial compromise of a single credential or workload sets the stage for cloud incident response. The big one is, what’s next for this identity? How fast the compromise spreads depends on the effectiveness of its authority.

Can it execute a different function / read secrets? Is it possible to alter a function, generate a new key, or stop logging? Is it able to change network policy or to access backups? The answers give a more precise indication of the blast radius than do the original vulnerability’s severity scores.

This implies a pragmatic review approach: select important identities and activities, assume compromise, and trace the maximum authority they might gain through permitted delegation. Compare this graph to the identity’s purpose. Even if each policy is technically sound, if the architecture is coupled by an authority from a billing automation account, or by an indirect trust path through a developer role to a recovery control, then it is considered to have authority coupling from a billing automation account and deserves attention.

Cloud security needs an authority baseline.

Configurations are already a baseline for organizations. They should also establish an authority baseline. Identify the resources that the critical workload should access, the actions that the critical workload should take, the identities that can administer the critical workload, and the acceptable delegation paths. Next, continually evaluate effective permissions against that desired model.

This setting is insecure; it may not be the most important discovery. This identity can now do something that it was never meant to do.” This is the meaning of Authority Drift. Adding cloud is not a risky endeavor because of a blatant error. It can be dangerous when changes are made year by year without much impact, but they lead to a configuration that conflicts with the architecture people think they have.

That drift gives security teams a more persistent way to think about cloud risk, since it is based on the concept of consequence: what or who can have authority over what, through what, and is that authority still justified? This baseline should only be changed if there is a change in business purpose. Drift then goes from anecdotal to measurable.