AI Pilot

Aether365's core is read-only Microsoft 365 security scanning: it scans your tenant, shows findings, and gives you remediation steps to run yourself. AI Pilot extends this with assisted remediation. After a scan, AI Pilot can propose specific fixes, let you review each one, and apply the changes you approve directly in your Microsoft 365 tenant through Microsoft Graph.

AI Pilot is opt-in and uses a separate Microsoft write-consent connection. Read-only scanning stays the default for every tenant, and nothing is written to your tenant unless you approve it.

How AI Pilot differs from read-only scanning

	Read-only scanning (default)	AI Pilot (opt-in)
What it does	Reads tenant configuration, runs scans, shows findings and remediation steps	Everything scanning does, plus applying the fixes you approve
Who applies fixes	You, by following the remediation steps	AI Pilot, after your per-item approval
Consent	Read-only Microsoft consent (granted when you connect a tenant)	A separate write-consent, granted only when you enable AI Pilot
Plans	All plans	Paid plans

Read-only scanning is always the default. AI Pilot never changes that posture on its own: it adds an optional, separate write-consent connection that you set up explicitly.

Availability

AI Pilot is available on paid plans. If your plan does not include it, the AI Pilot section prompts you to upgrade. Read-only scanning continues to work on every plan.

The AI Pilot flow

Using AI Pilot follows five steps:

1. Connect an AI Pilot tenant - grant the separate Microsoft write-consent for the tenant you want to enable.
2. Run an AI Pilot scan - Aether365 scans the tenant and identifies failed checks.
3. Review findings - AI Pilot generates a remediation plan that shows each proposed change, with the current value and the proposed new value side by side.
4. Approve fixes per item - you approve each fix individually. Nothing is applied until you do.
5. AI Pilot applies and verifies - approved fixes are applied through Microsoft Graph, and the new state is verified.

Enabling AI Pilot for a tenant

AI Pilot requires a separate Microsoft admin-consent that grants scoped write permissions in addition to the read permissions used for scanning. This is a one-time step per tenant, and it does not affect the read-only connection you already have.

Global Administrator required

The AI Pilot consent must be approved by a Global Administrator for the tenant you want to enable. The write permissions allow Aether365 to apply the fixes you approve in that tenant.

Steps:

1. Open the Connect Tenant page.
2. Find the AI Pilot Connection section.
3. Choose the connected tenant you want to enable AI Pilot on, then click Enable AI Pilot.
4. You are redirected to the Microsoft consent screen. Sign in with a Global Administrator account for that tenant.
5. Review the scoped write permissions shown on the consent screen, then click Accept.
6. Microsoft redirects you back to Aether365. The tenant now shows an AI Pilot badge, confirming write consent is active.

Your existing read-only connection for the same tenant is not affected. AI Pilot is connected as a separate, independent connection alongside it, not as an upgrade that replaces it. Scanning continues unchanged.

Read-only stays the default

Enabling AI Pilot on one tenant does not change anything for your other tenants. Each tenant stays read-only until you enable AI Pilot on it specifically.

Running an AI Pilot scan and reviewing the plan

Once a tenant has AI Pilot enabled, you can turn scan results into a remediation plan:

1. Run a scan for the tenant (manually or on its schedule), or use a completed scan.
2. In the AI Pilot area, generate a remediation plan from the scan. The plan lists the failed checks that have an automated fix.
3. The plan shows each proposed change as a row:
   • The check that failed
   • The current setting value
   • The proposed new value
   • The severity of the finding

Review every item before approving anything. Each row tells you exactly what will change.

Risk levels

Every automated fix carries a risk level that reflects how disruptive the change could be if it is not what you intended:

• Low - routine hardening with negligible disruption, such as blocking self-service email sign-ups or enabling a stronger authentication method.
• Medium - tighter restrictions that can affect day-to-day use if mis-scoped, such as restricting guest access or external sharing.
• High - changes that can lock users out if misconfigured, such as Conditional Access policies. High-risk changes are never applied automatically and always require your explicit approval.

The remediation plan badges each item with its risk level so you can prioritise your review. Auto-remediation (below) applies only low- and medium-risk fixes; high-risk changes always wait for you.

Approving fixes per item

AI Pilot applies fixes per item. Nothing is applied automatically, and there is no blanket "apply everything" action that bypasses your review.

1. In the remediation plan, click Approve on each item you want AI Pilot to apply.
2. Approved items are applied one at a time through Microsoft Graph.
3. After each change, Aether365 verifies the new state and marks the item as applied.
4. Items you do not approve are left unchanged. You can return to the plan later to approve more items.

Confirm with a fresh scan

After applying fixes, run a new scan to confirm the checks now pass. The scan reads the actual tenant state independently, so it is the authoritative check that a fix took effect.

Undoing a fix

If an applied fix has an unintended effect, you can reverse it. Each applied item in the AI Pilot activity view has a Revert action that restores the setting to its previous value and verifies the result, the same way the fix was applied.

Revert is guarded: it only runs when the setting still holds the value AI Pilot set. If something (or someone) changed that setting after the fix was applied, Revert refuses rather than overwrite the newer change, so your later edits are never clobbered.

Automated and manual fixes in a scan's detail

Not every failed check has an automated fix. When you open a scan's detail and look at a failed finding, AI Pilot tells you which kind it is:

• Findings with an automated fix show an AI Pilot checkbox. Tick it to have AI Pilot apply that fix for you.
• Findings with no automated fix show a Manual marker and the manual remediation steps to follow yourself. For a step-by-step approach to working through these, see Remediating Findings.

This split is the same whether you are reviewing a scan to approve fixes by hand or letting auto-remediation handle the fixable ones. The manual findings always remain yours to apply.

Auto-remediation on scan completion

Beyond reviewing fixes one at a time, AI Pilot can apply the fixable failed findings automatically as soon as an AI Pilot scan completes, then verify each change. This is convenient for tenants you trust AI Pilot to keep in shape without a manual review step after every scan.

Auto-remediation only runs when both of these are true:

• The tenant has an AI Pilot connection with write consent granted.
• Auto-remediation is enabled for your account. This is a separate switch from connecting AI Pilot, so simply having an AI Pilot connection does not start auto-applying fixes on its own.

When both conditions are met, a completed AI Pilot scan triggers the fixable failed findings to be applied and then verified, the same way a fix you approve by hand is applied and verified. Findings that have no automated fix are left for you to handle manually, exactly as in the scan detail described above.

Auto-remediation applies only low- and medium-risk fixes. High-risk changes - such as Conditional Access policies - are never auto-applied; they always wait for your explicit approval, regardless of whether auto-remediation is on.

Auto-remediation only ever runs on an AI Pilot scan you start yourself. Scheduled scans are always read-only: a schedule never runs AI Pilot and never applies a fix, even on a tenant that has auto-remediation enabled. Automation never writes to your tenant on its own.

You stay in control

Auto-remediation is off until you enable it. With it off, AI Pilot still does everything else - you just approve the fixes you want, when you want. With it on, the fixable findings are handled for you on each scan, and the manual findings are still yours to apply.

Break-glass accounts

Break-glass accounts are emergency-access accounts you keep so you are never locked out of your own tenant. You can designate them for an AI Pilot connection, and AI Pilot excludes them from high-impact changes - in particular, from any Conditional Access policy it creates.

Set them on the AI Pilot connection by user principal name or object ID. If no break-glass account is designated, AI Pilot warns you before you enforce a high-impact change, because enforcing one without an excluded emergency account risks locking everyone - including you - out of the tenant. Designating at least one is strongly recommended before you enforce Conditional Access.

Conditional Access

Conditional Access policies are among the highest-impact controls in Microsoft 365: they decide who can sign in and under what conditions. AI Pilot can create a small set of recommended Conditional Access policies for you, with hard guardrails:

• Block legacy authentication - blocks legacy protocols that cannot enforce MFA.
• Require MFA for admins - requires multifactor authentication for privileged directory roles.
• Require MFA for all users - requires multifactor authentication across all users and apps.

Because a misconfigured Conditional Access policy can lock everyone out, AI Pilot never enables one directly. It uses a deliberate two-step model:

1. Create in report-only. AI Pilot creates the policy in Microsoft's report-only mode, with your break-glass accounts excluded. Report-only neither blocks nor grants anything: it only records what would have happened, which you can review in your Entra sign-in logs under the Conditional Access tab.
2. Review the impact. Check the report-only results against real sign-ins to confirm the policy behaves as intended and does not catch anyone it should not.
3. Enforce. Only when you are satisfied do you explicitly Enforce the policy, which flips it from report-only to enabled. AI Pilot warns you at this moment if no break-glass account is excluded.

Conditional Access is never applied automatically and never enforced without your explicit action. AI Pilot only ever touches the policies it created - they carry an Aether365 - name prefix - and never modifies your existing Conditional Access policies.

Designate a break-glass account first

Before enforcing any Conditional Access policy, designate at least one break-glass account so you retain emergency access. AI Pilot excludes it from the policy automatically.

The safety model

AI Pilot is designed so that write access is deliberate and reviewable:

• Opt-in. AI Pilot is off by default. Read-only scanning is the default posture for every tenant.
• Separate consent. Write access uses its own Microsoft consent, distinct from the read-only scan consent. Granting it requires a Global Administrator.
• Per-item approval. Every fix is reviewed and approved individually before anything is written to your tenant. No fix is auto-applied blindly.
• Verified. After each fix is applied, the new state is verified, and you can confirm the result with an independent scan. This holds for auto-remediation too: each automatically applied fix is verified before it is marked done.
• Auto-remediation is opt-in. Applying fixes automatically on scan completion only happens when you turn it on, on top of an AI Pilot connection. It never applies fixes that have no automated remediation, and manual findings stay yours to handle.
• Risk-tiered. Each fix is classified low, medium, or high risk. Auto-remediation applies only low- and medium-risk fixes; high-risk changes always require explicit approval.
• Reversible. Applied fixes can be reverted to their previous value, guarded so a revert never overwrites a newer change made since.
• Break-glass aware. Emergency-access accounts you designate are excluded from high-impact changes and from any Conditional Access policy AI Pilot creates.
• Conditional Access is two-step. High-impact policies are created in report-only mode first and only enforced after your explicit review and action - never automatically.
• Scoped. The write permissions cover only the remediation areas Aether365 supports.

Revoking AI Pilot consent

To remove AI Pilot write access for a tenant:

1. In your Microsoft tenant, open the Entra admin center (portal.azure.com > Enterprise Applications > Aether365).
2. Remove the write permissions, or remove the enterprise application entry.

Your read-only connection in Aether365 keeps working for scanning after you revoke write consent. If you later want AI Pilot again, re-enable it from the AI Pilot Connection section on the Connect Tenant page.

Related

• AI Pilot Service Limitations - controls AI Pilot does not auto-remediate, and where to act on them
• Connect a Tenant - setting up the read-only connection and the AI Pilot Connection
• Remediating Findings - working through findings manually
• Threat Alerts - live identity risk and one-click breach response
• Policy Management - review and harden key tenant policies
• Reading Scan Results - understanding scan output
• Security Model - read-only default and optional write access
• Microsoft Permissions - permissions Aether365 requests