Skip to content
Infralign Infralign Infralign docs

The agent

Safety model

Three gates between the platform and your production estate — read-only access, validation, and human approval — plus per-tenant isolation.

The platform makes zero production writes. 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.

The three gates Three gates in sequence. Gate one is read-only access: the service principal holds Cost Management Reader and Reader, and no write scope is granted. Gate two is validation: each change plan is reviewed by an expert against your architecture and policy. Gate three is human approval: you approve or reject each finding, and your own team merges the change through your own pipeline. Gate 1 Read-only access Cost Management Reader + Reader. No write scope. Gate 2 Validation Expert review against your architecture and policy. Gate 3 Human approval You approve or reject each finding. Your team merges.
Figure 1 — A change has to clear all three gates, in this order, and the last one is your team's decision.

Gate one: read-only access

Section titled “Gate one: read-only access”

All analysis — dashboards, reports, chatbot, audit — runs on read-only access:

  • 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; setup is in Entra app registration.
  • Ingestion is pull-based. No agents or extensions are installed on your VMs, and no standing production privilege exists.
  • Access is revocable at any time — delete the role assignments or the app registration and the data flow stops the same moment.

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, idle-days — so a recommendation 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, one tenant can never reach another’s data:

  • Per-tenant data isolation — each customer has a dedicated warehouse. There is no shared query path across tenants.
  • Chatbot safe-SQL — the chat agent can run only validated, read-only, single-SELECT queries against an allowlist of your own tenant’s tables. See how the chatbot stays safe.
  • Entra SSO with tenant binding — your users sign in with their existing Microsoft work account through the Infralign Portal app; 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”

The platform does the correlation and validation work that stalls lean teams, while every change that touches production carries your team’s sign-off. It is the same review-gated model used in the founding engagements.

Next: Permissions — the exact roles behind gate one, their scopes, and how to revoke them.