Should security teams prioritize central governance or local cloud team autonomy?

Why Central Governance Has to Lead

For agentic and cloud-native workloads, the real decision is not whether teams can move fast, but whether they can do so inside a shared privilege model. Central governance sets the non-negotiables: identity standards, approval workflows, credential lifecycles, logging, and revocation rules. Local autonomy then becomes an execution layer, not a separate policy regime. That distinction matters because autonomous systems do not stay within the neat boundaries designed for human operators.

When security teams let each cloud group define its own access pattern, the result is drift: different token lifetimes, inconsistent JIT practices, and weak audit trails. That is why NHI lifecycle controls in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs matter so much, and why governance language in the NIST Cybersecurity Framework 2.0 still maps cleanly to modern identity operations. The point is not centralising every deployment step; it is centralising the rules that keep privilege bounded. In practice, many security teams discover the lack of common controls only after an incident forces them to reconstruct who approved what, and when.

How It Works in Practice

The best operating model is centrally defined policy with locally delegated execution. Security leadership owns the control plane: RBAC guardrails, approval thresholds, secret handling standards, and review requirements. Cloud platform teams own the workflow: how those policies are enforced in AWS, Azure, GCP, Kubernetes, or an agent runtime. That split works because it preserves speed without letting each team invent a different trust model.

For autonomous workloads, static IAM usually fails because the system’s behaviour changes by task. Agents chain tools, call APIs in sequence, and adapt to new context, so authorisation needs to be evaluated at request time rather than assumed from a fixed role. Current guidance suggests moving toward intent-based authorisation, JIT credential issuance, and short-lived secrets that are revoked automatically when a task ends. The identity primitive should be workload identity, not a human-style account. That is the direction reinforced by the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, both of which emphasise governance, traceability, and risk-informed control selection.

A practical pattern looks like this:

• Central security defines which identities may request access, which secrets are eligible for JIT delivery, and which actions require human approval.
• Platform teams implement policy-as-code and enforce it through admission controls, OIDC federation, or SPIFFE-style workload identity.
• Every credential is scoped to a task, logged, and expired quickly instead of lingering as a reusable secret.
• Exception handling is time-bound and reviewed, rather than becoming a standing entitlement.

The need for this becomes obvious when the organisation’s NHI estate is already under pressure: in The State of Non-Human Identity Security, 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, and 85% lack full visibility into third-party OAuth-connected vendors. These controls tend to break down when autonomous agents are allowed to act across multiple clouds with shared secrets and no single policy decision point, because auditability disappears as soon as the credential is reused outside its intended task.

Where the Tradeoffs and Exceptions Actually Are

Tighter central control often increases operational overhead, requiring organisations to balance speed against consistency. That tradeoff is real, especially in teams that need to ship fast or support regulated production systems. The answer is not to eliminate local autonomy, but to constrain it with clear boundaries: approved identity providers, defined secret TTLs, mandatory logging, and a common review process for exceptions.

There is no universal standard for this yet, especially for fully autonomous agents. Best practice is evolving toward runtime policy evaluation, zero standing privilege, and continuous verification of what the workload is trying to do, not just what team owns it. That aligns with the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, both of which support governance that can adapt as agent behaviour changes.

Edge cases need special handling. A data science sandbox may tolerate broader local autonomy than a production remediation agent. A vendor-connected workflow may need stricter central approval than an internal automation job. And when organisations are building toward autonomous infrastructure changes, the risk is not just privilege breadth but invisibility: the The 2026 Infrastructure Identity Survey found that only 13% of organisations feel extremely prepared for agentic AI, while 53% expect AI to run major portions of infrastructure autonomously within three years. In those environments, local freedom without central policy usually becomes a control gap rather than a productivity gain.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams use IAST and RASP in NHI governance?
• How should security teams reduce the risk of cloud privilege abuse after a supply chain compromise?