Skip to content
Infralign Infralign Infralign docs

Fixes and safety

Safety model

Your own team performs the last write to your estate. This is what has to happen before they are asked to.

The platform issues no workload or resource-configuration writes to your Azure estate. Everything sits behind three gates, and only your team’s explicit approval moves a change across the last one. Figure 1 shows them in the order a change meets them.

Three gates in sequence, in two bands. The first band is Infralign's and holds gates one and two. Gate one is restricted collection access: the service principal holds Cost Management Reader and Reader, neither of which grants workload or resource-configuration writes. Gate two is validation, done by a person: each change plan is reviewed by an expert against your architecture and policy. The validated change plan then passes down to the second band, which is your team's, and holds gate three. Gate three is human approval: you approve or reject each finding, and your own team merges the change through your own pipeline. Three gates in sequence, in two bands. The first band is Infralign's and holds gates one and two. Gate one is restricted collection access: the service principal holds Cost Management Reader and Reader, neither of which grants workload or resource-configuration writes. Gate two is validation, done by a person: each change plan is reviewed by an expert against your architecture and policy. The validated change plan then passes down to the second band, which is your team's, and holds gate three. Gate three is human approval: you approve or reject each finding, and your own team merges the change through your own pipeline.
Figure 1: A change has to clear all three gates, in this order, and the last one is your team's decision.

Gate one: restricted collection access

Section titled “Gate one: restricted collection access”

Dashboards, reports, chatbot and audit all use roles without workload or resource-configuration write permissions:

  • The platform reads through a service principal in your own tenant, holding two roles by default: Cost Management Reader and Reader. A third, Storage Blob Data Reader on the export container, is added only if you opt into the FOCUS export lane. Scopes are in the permissions reference, and setup is in Entra app registration.
  • Ingestion is pull-based. No agents or extensions are installed on your VMs, and no standing workload or resource-configuration privilege exists.
  • Access is revocable without action from Infralign. Remove the role assignments, or delete the app registration. New collection stops once Azure applies the revocation or the credential can no longer authenticate.

The permissions reference lists every role action and a least-privilege custom role.

Gate two: validation

Section titled “Gate two: validation”

Before an approved fix becomes a change your team merges:

  1. Each change plan is checked against your architecture and policy constraints. A change that saves money by degrading reliability or security posture is reworked or dropped.
  2. Findings carry their utilisation evidence and confidence levels: 30-day p95 CPU, and idle-days. A finding is grounded in how the resource is actually used, not billing data alone.
  3. Blast radius, and any app code changes, are made explicit before review.

Gate three: human approval

Section titled “Gate three: human approval”

Nothing changes without a human decision. You approve or reject each finding in the app, and approved changes are merged by your own team through your own pipeline, under your own controls. The platform’s involvement ends at the approved change plan.

Isolation and access controls

Section titled “Isolation and access controls”

Beyond the three gates, the application is scoped to your own tenant:

  • Each customer has a dedicated warehouse, and no query path crosses tenants.
  • The safe-SQL chatbot runs only validated, read-only, single-SELECT queries, and only against an allowlist of your own tenant’s tables. See how the chatbot stays safe.
  • Your users sign in with their existing Microsoft work account through the Infralign sign-in application, and a per-tenant allowlist bound to your tenant ID controls who gets in. Passwords are never shared with Infralign. See Dashboard sign-in.

Why this shape

Section titled “Why this shape”

This is the same review-gated model used in the founding engagements, where it produced €750K a year of recurring saving with no production outage from an approved refactor.

Gate one is the two Azure roles. Permissions gives their exact scopes; ending the connection is how you take them back.