At some point in every regulated cloud delivery, someone proposes granting the deployment pipeline Owner on the subscription. It is always proposed for good reasons: the deadline is real, the access chain has already cost a week, and Owner makes the problem disappear immediately.
It also makes a standing, subscription-wide, fully-privileged identity that lives in your CI system for the rest of the platform's life. Here is what we did instead.
Three decisions, none of them exotic
Deploy with a managed identity and workload identity federation. No client secret, no certificate, nothing to rotate and nothing to leak. The pipeline proves who it is against the identity provider and receives a short-lived token. The most common credential-related incident is a long-lived secret sitting somewhere it should not be, and this removes the category rather than managing it.
Scope the identity to the resource group, not the subscription. The deployment needs to create and change resources in one resource group. That is the scope. This is what produces the provider-registration gate discussed in the previous article — a subscription-scoped operation that a resource-group-scoped identity structurally cannot perform. That gate is the control working, not the control failing.
Keep the role assignments in the infrastructure code. Every temptation runs the other way here, because doing it once by hand in the portal takes ninety seconds and getting it right in Bicep takes an afternoon. Do it in code anyway. Manual grants are invisible to review, unreproducible across environments, and impossible to evidence later — which matters a great deal for the proof pack.
The role that lets a pipeline assign roles
The application needed data-plane role assignments — the search service reading from storage, the app calling the AI service. Something has to create those. If it is the pipeline, the pipeline needs the ability to assign roles, which is exactly the capability you were trying not to hand out.
The reflex is User Access Administrator. It works, and it also means the pipeline identity can assign any role, including privileged ones, including to itself. You have removed the standing Owner grant and replaced it with a standing path to Owner.
Role Based Access Control Administrator is the better answer. It permits role assignment while being constrained from granting privileged roles. Combined with resource-group scope, the pipeline can give the application exactly the data-plane access it needs and cannot escalate beyond that.
This is a small distinction that takes ten minutes to get right and closes a genuine escalation path. It is the single most portable thing in this article.
The super-agent problem, and why this matters more now
Everything above is ordinary platform hygiene. It becomes considerably more consequential once AI agents are the thing being deployed — and this is where the emerging governance literature and our delivery experience meet.
Writing in ITWeb in August 2026, Eugene Perumal of Valutivity (Deploying AI agents safely) names the failure mode precisely: super-agency and over-privilege. Agents that can reach any system they happen to have a path to, holding access rights far beyond what their task requires. His description is the one that will stay with you — it is "the AI equivalent of giving every new employee master keys to every room in the building and assuming they will only open the doors they need."
The reason this compounds is that an agent is not a new employee. It does not hesitate, it does not ask whether it should, and it operates at machine speed across every door it can reach. The same over-permissioning that is a latent risk with a deployment pipeline becomes an active one with an agent that reasons its way to an action nobody anticipated.
Perumal reports that 60% of leading enterprises now restrict agent access to sensitive data without human oversight, and that 75% identify security, compliance and auditability as their most critical agent requirements. That is the market arriving at the conclusion this article is arguing from the delivery side.
Classify before you permission
The practical antidote Perumal proposes is to classify an agent before designing its permissions, on two axes: how much damage it could do, and how much latitude it needs.
The value of the quadrant is that it stops the default. Without it, every agent in an organisation tends to inherit the same broad access, because permissioning gets decided once by whoever set up the first one. With it, a knowledge-base retrieval agent gets ordinary software governance and an agent touching payments or regulatory submissions gets ephemeral access, dynamic controls and a mandatory human checkpoint — and nobody has to argue about it case by case.
It is the same instinct as resource-group scoping, applied one layer up. Decide what this thing actually needs, encode it, and make the broad grant the exception that requires justification.
The POPIA point
For South African organisations there is a compliance argument that sits underneath the security one, and it is stronger than most technical teams realise.
Perumal puts it directly: "the principle of least privilege in agent design is, at its core, a POPIA architecture requirement." POPIA requires that automated processing of personal information be purposeful, proportionate and accountable. An agent — or a pipeline identity — with access materially beyond its task fails the proportionality test whether or not it ever uses that access. The exposure is the grant, not the usage.
That reframing matters for how these conversations go internally. Least-privilege stops being a thing the security team wants and becomes a thing the regulation requires, which changes who has to be convinced and how quickly. For anyone in financial services, the equivalent applies via SARB and FSB expectations: an agent influencing credit decisions, payments or regulatory submissions is held to the same accountability and explainability standard as a person doing the same job.
The compounding benefit
There is a payoff that is easy to miss while you are in the friction of it. A properly scoped, code-defined access model produces a comprehensive audit trail as a by-product — what was triggered, what data was reached, what was changed, by which identity, from which commit.
Perumal is right that this is what "differentiates deployable systems from proof-of-concepts." You cannot retrofit it. An environment permissioned by hand over eight months cannot produce that record, because the record was never created. An environment permissioned in code can produce it on demand, for any point in its history, which is precisely what an audit asks for.
How CloudNala can help
The work here is rarely difficult and is almost always deferred, because the shortcut is available at every step and the cost of taking it arrives months later. Where we tend to be useful is in setting the access model up correctly in the first sprint — federated identity, resource-group scoping, constrained role assignment, all of it in the IaC — and in running the risk-capability classification with clients before agents get built rather than after they are live and quietly over-permissioned.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za