Governing Azure Without Owning It

There's a conversation that happens early in almost every enterprise governance tool evaluation. It usually goes something like this: the vendor's setup guide asks you to create a service principal and assign it Owner on your subscription. Or Contributor. Or some other broad role that makes the integration "just work."

Most teams do it. They rationalize it as temporary, or tell themselves they'll lock it down later. Later rarely comes.

This is one of the most common ways governance tools — tools whose entire purpose is to improve your security posture — become a security liability themselves.

The credential problem with governance platforms

A governance platform needs access to your Azure environment to do anything useful. That's unavoidable. The question is what kind of access, and how it's held.

Most tools answer this by accumulating permissions. They need to read resources, so they get Reader. They need to remediate findings, so they get Contributor. Some findings require privileged operations, so they get Owner. Each expansion makes sense in isolation. The aggregate is a persistent, highly-privileged credential that exists continuously in your environment — a credential that, if compromised, hands an attacker the keys to your Azure estate.

The governance platform meant to protect you becomes the thing that needs protecting.

Least privilege as a design principle, not a checkbox

Stratoscope connects to your Azure environment using a service principal scoped to the minimum permissions required for discovery and assessment. Reading your resources, evaluating your posture, surfacing findings — none of that requires elevated access.

Remediation is where it gets interesting.

Most remediation operations — disabling public access on a storage account, updating a network security group rule, rotating a credential — can be executed with standard Contributor-level access. Stratoscope's service principal handles those.

Some operations genuinely require more. Role assignments, policy definitions, certain identity operations — Azure requires elevated permissions for these by design. Rather than holding those permissions persistently, Stratoscope does something different: it stops, surfaces the specific operation and exactly why it requires elevation, and asks for your approval to proceed using your identity.

Not the platform's identity. Yours.

The "borrow, don't own" model

When a remediation step requires elevated permissions, you see exactly what's being proposed: the specific Azure operation, the scope it targets, the permission it needs, and why. You can approve, deny, or modify. If you approve, the operation executes under your delegated identity — with your permissions, for that operation, at that moment.

The platform never holds persistent elevated credentials. It borrows your authority for a specific, approved action, then returns it. Every escalation is an explicit decision you made, logged with the operation, the scope, the outcome, and the timestamp.

This is separation of duties working as intended. The platform surfaces what needs to happen and proposes how. You decide whether it does.

Audit trails that mean something

Most Azure audit logs tell you that an operation happened. Stratoscope's logs tell you the full story: the governance finding that prompted it, the remediation plan that was proposed, the human who approved it, the identity under which it executed, and whether it resolved the finding.

That chain — from finding to approval to execution to outcome — is what compliance teams actually need. Not a list of API calls. A record of decisions.

When an auditor asks "why was this change made and who authorized it," the answer is in the log. Not reconstructed from scattered Azure activity logs, but recorded as a complete governance decision at the time it was made.

Why this matters for enterprise

The pattern of least-privilege-by-default with explicit escalation isn't just a security nicety. It's what makes it possible to deploy a governance platform in a regulated environment, or an environment with meaningful change control requirements, or any environment where "we gave the tool Owner and trusted it" is not an acceptable answer.

The goal of a governance platform isn't to replace human judgment about what changes are safe to make in your Azure environment. It's to make that judgment easier, faster, and better informed — while keeping the human in the loop on every decision that matters.

Governing Azure well doesn't require owning it. It requires knowing it deeply, proposing changes carefully, and acting only with explicit approval.

That's the model we're building toward.