Assist Sg Update

This is the primary autofix skill in the s360-tenant-isolation plugin. It generates assisted pull requests to the 1P apps repo that correct Security Group ownership for first-party applications flagged by S360 tenant-isolation policy.

Scenarios Covered

Scenario 1 — 1P App with invalid security group

Violation title: "1P App with invalid security group"

What happened: A first-party application's Security Group Owner tenant is either "Unknown" or "Microsoft" (the Corp tenant). Neither is a valid production tenant, so the app has no production governance over its credential boundaries.

Why this is dangerous: Without a production-tenant SG owner the app's lifecycle is ungoverned — credentials may be accessible from non-production contexts, administrative rights are undefined, and the app falls outside SFI Tenant Isolation policy.

Typical underlying data signals:

Scenario 2 — 1P App Cert Tenant Mismatches Security Group Tenant (Option 1: Update SG)

Violation title: "1pApp certs Tenant mismatches the Tenant of the Security Group"

What happened: A first-party application's certificate lives in Production Tenant A, but its Security Group owner lives in Production Tenant B — both within the same cloud. The cert holder in Tenant A can obtain tokens for resources governed by Tenant B, creating a cross-tenant credential exposure.

Why this is dangerous: Cross-tenant credential exposure breaks the isolation boundary. An actor with access to the cert in Tenant A can impersonate the app in Tenant B's resource scope.

Typical underlying data signals:

This skill handles Option 1 only — updating the Security Group to the correct tenant. If the SG is already correct and the cert needs to move, redirect the user to the guide-cert-rehoming skill instead.

Alternative paths (from TSGs):

• Scenario 1 (invalid SG — aka.ms/entraQ9): Option 2 is updating the OneCert domain registration details to match the correct SG tenant.
• Scenario 2 (SG/cert mismatch — aka.ms/entraQ6): Option 2 is moving the certificate to the correct tenant via guide-cert-rehoming.

Skill Logic

Step 1 — Validate the Violation Is SG-Fixable

1. Confirm Title / ViolationTitle matches one of the two scenarios above.
2. These violation titles are already 1P-specific, so no separate AppType check is required at runtime.
3. For Scenario 2 — determine the correct fix direction:
   • If the user or repo context confirms the SG is wrong → proceed with this skill. ✓
   • If the user confirms the cert is wrong → redirect to guide-cert-rehoming. ✗
   • If the action item alone does not make the direction clear → ask the user to confirm before generating any change.

If the violation does not pass validation, stop and explain which condition failed and what alternative skill or manual process applies.

Step 2 — Extract Target State from Violation Data

Read the following fields from the normalized violation object produced by fetch-violations when available:

The MCP response does not include the exact Security Group object or target tenant name. Treat the SG identity and target tenant as user-confirmed inputs if they are not already known from repo context or the linked work item.

Step 3 — Check Prerequisites

Determine whether the application is enabled for 1P apps repo management.

• If yes → proceed to Step 4.
• If no → surface this as a blocker with the following guidance:

⚠️ Blocker — Repo Management Not Enabled

This application is not yet enabled for 1P apps repo management. SG ownership changes can only be submitted as PRs to the 1P apps repo once the app is migrated.

Action required: Enable repo management for this app first: https://aka.ms/migrate-1p-repo

Once migration is complete, re-run this skill to generate the autofix PR.

Do not proceed past this step until the prerequisite is met.

Step 4 — Identify the Correct Security Group

The action item provides app context but usually not the specific Security Group object.

1. If the 1P apps repo or first-party portal already identifies the owning SG, use that.
2. If multiple SGs are plausible → present the options and ask the user to confirm.
3. If the SG cannot be determined from the available context → ask the user to provide the correct SG display name and object ID.

⚠️ Always surface this caveat to the user:

"The action item indicates an SG ownership problem, but the exact Security Group must be confirmed before changing governance metadata. Please verify the correct SG name, object ID, and owning tenant before proceeding."

Never auto-select an SG without explicit user confirmation. This is a governance-critical change.

Step 5 — Generate the Assisted Autofix

Produce the 1P apps repo pull request content:

File to modify: The app's manifest file in the 1P apps repo (located by AppId).

Change: Update the Security Group owner field to the confirmed production SG in the target tenant.

PR content must include:

PR description must include:

• The violation title and S360 action item reference (ID / link)
• Current state (wrong SG tenant) → target state (correct SG tenant)
• Policy reference from the SFI-TI-overview policy table (see table below)
• Link to the relevant TSG documentation

Present the full PR content to the user for review before submission. Do not auto-submit.

Step 6 — Post-Fix Validation Guidance

After the PR is merged and Gradual Rollouts propagation completes, instruct the user to verify the fix:

1. The app's owning Security Group now matches the confirmed production SG.
2. The violation no longer appears in the PowerBI dashboard after the next S360 refresh.
3. The repo manifest / app registration reflects the intended governance owner.

ℹ️ S360 data refreshes every 24 hours. Allow up to one full refresh cycle before expecting dashboard updates.

Policy Reference — SG Owner → Expected Tenant Mapping

Use this table to validate the target tenant against the app's cloud setting and OneCert configuration.

Links

Important Notes

• Gradual Rollouts apply. The 1P apps repo uses Gradual Rollouts — even metadata-only changes (like SG ownership) go through staged review and propagation.
• Repo management must be enabled first. Apps that have not been migrated to repo management cannot have SG changes submitted via PR. Direct the user to aka.ms/migrate-1p-repo before attempting autofix.
• SG ownership = administrative rights. The Security Group controls who can manage the application's lifecycle, credentials, and data access. Incorrect SG assignment is a governance and security boundary violation.
• Always confirm the SG with the service owner. Never auto-select a Security Group. The service owner must verify the correct SG before the PR is submitted.
• Dashboard refresh lag. S360 data refreshes every 24 hours. Instruct users to wait at least one full cycle after PR merge before validating the fix on the dashboard.

SDP Requirements

⚠️ All production changes must follow SDP:

• Use Safe Deployment Orchestrators — Deploying Change Safely
• C+AI services: submit R2D request at aka.ms/R2Drequest
• Honor CCOA banners: aka.ms/ccoa
• Use Gradual Rollouts v2 for 1P apps repo changes. If not possible, use Gradual Rollouts (legacy).
• Livesite mitigations bypassing SDP require executive leader approval.