| name | assist-sg-update |
| description | Generate assisted PRs to correct Security Group ownership for first-party apps flagged by S360 tenant-isolation policy (SFI-TI3.2.2) |
| lastReviewed | 2026-04-30T00:00:00.000Z |
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:
| Field | Value |
|---|
| SG owner tenant | "Unknown" or "Microsoft" |
| SG ownership state | Invalid / needs production owner |
| Expected tenant | The app's production tenant |
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:
| Field | Condition |
|---|
| SG tenant | Does not match the intended certificate/app tenant |
| Expected tenant | The production SG tenant |
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
- Confirm
Title / ViolationTitle matches one of the two scenarios above.
- These violation titles are already 1P-specific, so no separate
AppType check is
required at runtime.
- 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:
| Field | Purpose |
|---|
AppId | Application (client) ID being fixed |
AppDisplayName | Human-readable app name |
TargetId | S360 target ID for the action item |
cloudType | Cloud context (Public / Fairfax / Mooncake) |
ADOWorkItemHTMLUrl | Reference link for the underlying work item |
ActionOwnerAlias | Current action owner |
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.
- If the 1P apps repo or first-party portal already identifies the owning SG, use that.
- If multiple SGs are plausible → present the options and ask the user to confirm.
- 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:
| Section | Content |
|---|
| App ID | {AppId} |
| App display name | {AppDisplayName} |
| Current SG | Existing SG name / object ID if known |
| Target SG | The confirmed Security Group name and object ID |
| Target tenant | The confirmed production tenant |
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:
- The app's owning Security Group now matches the confirmed production SG.
- The violation no longer appears in the PowerBI dashboard after the next S360 refresh.
- 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.
| 1P App SG Owner Tenant | App Cloud Setting | OneCert Cloud / Environment / Tenant | OneCert Private Issuer | Allowed Vaults | Cert Can Exist on Corp Devices |
|---|
| AME | Public | Public + Prod + AME | AME | KV and dSMS | No |
| CME / AME / PME | Mooncake | MoonCake + Prod + CME | AME | KV and dSMS | No |
| GME | Public | Public + Prod + GME | AME | KV and dSMS | No |
| MPA | Public | Public + Prod + MPA | AME | KV and dSMS | No |
| PME | Public | Public + Prod + PME | AME | KV and dSMS | No |
| Torus | Public | Public + Prod + Torus | AME | KV and dSMS | No |
| Torus Gallatin / Torus | Mooncake | MoonCake + Prod + Torus Gallatin | AME | KV and dSMS | No |
| Torus ITAR / Torus | Fairfax | FairFax + Prod + Torus ITAR | AME | KV and dSMS | No |
| USME / AME / PME | Fairfax | FairFax + Prod + USME | AME | KV and dSMS | No |
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:
