Entra-Application-Risk-Validator-v4.0.txt

Workflow version: Entra Application Risk Validator v4.0. Begin the response with exactly: WORKFLOW: ENTRA-APPLICATION-RISK-VALIDATOR-v4.0 Perform a manually initiated, read-only Microsoft Entra security validation of one application identity selected by the analyst. INPUTS
Application ID: <ApplicationId>
Service-principal object ID: <ServicePrincipalObjectId>
Audit and activity lookback period: <LookbackDays> days
PROMPTBOOK INPUT BINDING
The values enclosed in angle brackets are Security Copilot promptbook input placeholders. Preserve the exact placeholder names and angle brackets when creating or editing the promptbook. Do not replace the placeholders with literal values in the saved promptbook definition.
PARAMETER REQUIREMENTS
ApplicationId is required. It is the Microsoft Entra application/client ID represented by the appId property and is used to locate all matching application registrations and service principals.
ServicePrincipalObjectId is optional. It is the Microsoft Entra tenant-local service-principal directory object ID represented by the id property. Supply it when available. Enter Unknown when it is unavailable. The workflow must still run when this value is unavailable.
LookbackDays is required and must be a positive whole number.
INPUT NORMALIZATION AND VALIDATION
Trim leading and trailing whitespace from ApplicationId and ServicePrincipalObjectId before using either input. Treat the Application ID as required. Confirm that ApplicationId is a valid GUID before querying Microsoft Entra. If ApplicationId is empty, unavailable, a sentinel value, or not a valid GUID, state: INVALID APPLICATION ID — validation stopped. Do not continue the security assessment. Treat the service-principal object ID as unavailable when ServicePrincipalObjectId is empty, whitespace, null, or equals any of the following values using a case-insensitive comparison: Unknown, Not available, N/A, NA, None, Null. Do not attempt a directory-object lookup using an unavailable sentinel value. When ServicePrincipalObjectId is not an unavailable sentinel value, confirm that it is a valid GUID. If it is not a valid GUID, state: INVALID SERVICE-PRINCIPAL OBJECT ID — continuing with Application ID resolution only. Then resolve service principals using ApplicationId instead of stopping the workflow. Confirm that LookbackDays is a positive whole number. If it is missing, zero, negative, or not a whole number, state: INVALID LOOKBACK PERIOD — validation stopped. Do not continue the security assessment.
PURPOSE Determine whether the selected application identity presents: 1. No confirmed security deficiency; 2. A business-owner or governance validation requirement; 3. A confirmed cyber security deficiency requiring a DevOps remediation story; 4. A credible compromise indicator requiring immediate security investigation; or 5. Insufficient evidence to reach a dependable conclusion. This workflow must not modify Microsoft Entra, Azure, Microsoft 365, credentials, consent grants, permissions, ownership, role assignments, redirect URIs, or application configuration. Do not create a ticket, contact an owner, revoke access, disable an identity, or initiate remediation. IDENTITY RESOLUTION Use the normalized Application ID to retrieve all matching Microsoft Entra application registrations and all matching service principals using exact, case-insensitive appId equality. Complete all available pagination. The Application ID is the primary identity-resolution key. A missing service-principal object ID must not prevent resolution by Application ID. When a valid service-principal object ID is supplied, retrieve that exact service-principal object and confirm that its appId exactly matches the supplied Application ID using a case-insensitive comparison. If the exact service-principal object exists but its appId differs from the supplied Application ID, state: IDENTITY MISMATCH — validation stopped. Do not continue the security assessment after an identity mismatch. If the supplied service-principal object ID does not resolve to an object, state that the exact object was not found and continue with Application ID resolution. Do not interpret a failed exact-object lookup as proof that no local service principal exists. When no valid service-principal object ID is supplied, use the Application ID query results as follows: - If exactly one matching service principal is returned, use its id as the resolved service-principal object ID and continue the complete validation. - If no matching service principal is returned, state: No local service principal resolved by Application ID. Continue with application-registration evidence when available and mark service-principal-dependent assessment areas Partial, Unavailable, Unsupported, Permission denied, or Not applicable as appropriate. - If more than one matching service principal is returned, state: AMBIGUOUS SERVICE-PRINCIPAL RESOLUTION — multiple local service principals share the supplied Application ID. List every matching service-principal object ID and display name. Do not arbitrarily select one object. Assess shared application-level evidence and each resolved service principal separately where supported. Final confidence cannot be High until the intended service principal is disambiguated. Report the identity-resolution method as one of: Exact service-principal object ID, Application ID with one service-principal match, Application ID with no service-principal match, or Application ID with multiple service-principal matches. Identify: - Display name - Application ID - Application-registration object ID, when present - Service-principal object ID, when present - Application-registration creation timestamp - Service-principal creation timestamp - Sign-in audience - Publisher domain - Verified publisher information - Service-principal type - Account enabled state - Application-owner tenant or equivalent authoritative ownership information, when available - Whether the identity is an application, managed identity, workload identity, service identity, Microsoft first-party identity, externally owned application, or unknown - Supplied service-principal object ID value after normalization - Service-principal object ID input status: Valid, Unavailable sentinel, or Invalid - Resolved service-principal object ID or IDs - Identity-resolution method - Number of matching application registrations - Number of matching service principals Do not infer ownership or identity type only from the display name. If ownership or identity type cannot be established from authoritative evidence, report it as Unknown. A missing local application registration is not automatically a risk for an externally owned application, Microsoft first-party application, managed identity, or workload identity. OWNERSHIP AND PURPOSE Retrieve, when supported: - Application-registration owners - Service-principal owners - Owner account enabled or disabled status - Creator or initiating actor from Microsoft Entra audit data - Creation operation - Available project, resource, or platform association - Corresponding Azure resource for a managed identity, when available Distinguish: - No owner was returned by a successful owner query; - Owner information could not be queried; - Owner information is unsupported; - Owner exists but account status is unavailable. Do not interpret unavailable owner data as confirmation that no owner exists. Determine whether Organization ownership is: - Confirmed - Likely - External - Unknown Do not invent a business purpose. If the business purpose cannot be established from Entra data, state: "Business purpose requires owner validation." CREDENTIAL REVIEW Retrieve credential metadata when supported, including: - Credential type: secret, certificate, federated identity credential, or other - Credential display name or identifier - Creation or start date - Expiration date - Active, expired, or future validity state - Credential additions or removals within the previous LookbackDays days - Actor responsible for each recent credential change, when available - Number of active credentials - Whether the identity is a managed identity that normally should not require application secrets Never request, retrieve, display, or expose an actual secret value, private key, token, or reusable credential. Identify as security concerns only when supported by evidence: - Credential added by an unexpected or unidentified actor - Credential lifetime inconsistent with organizational policy - Multiple active credentials without an established need - Expired or obsolete credentials indicating lifecycle weakness - Secret-based authentication where an approved managed-identity design should be used - Credential remaining on an abandoned or unauthorized application If the organization credential-lifetime policy is unavailable, report the lifetime as an observation requiring policy comparison rather than declaring a violation. PERMISSIONS AND CONSENT REVIEW Retrieve permissions and authorization grants when supported. Distinguish among: - Delegated permissions - Application permissions - OAuth permission grants - App-role assignments - Tenant-wide admin consent - User consent - Requested permissions that have not been granted - Granted permissions - Permissions whose consent state cannot be determined For every granted permission, report: - Resource API - Exact permission name - Delegated or application permission - Consent type - Consenting principal or actor, when available - Consent timestamp, when available - Whether admin consent was granted - Available evidence - Business justification status: Confirmed, Unknown, or Not available Prioritize permissions capable of: - Reading or modifying directory objects - Managing Microsoft Entra roles - Managing applications or service principals - Reading or modifying mail - Sending mail - Reading or modifying files - Reading or modifying SharePoint sites - Reading audit logs - Accessing users, groups, devices, authentication methods, or identity configuration broadly - Impersonating users - Accessing broad organizational data without a signed-in user Do not call a permission excessive solely because it is powerful. A permission becomes a remediation candidate when: - It is granted; - It is not justified by the confirmed business purpose; - It exceeds the access required by the application; - It is unauthorized or unsupported by an approved owner; or - Other evidence establishes that the access is inappropriate. If permission or consent information cannot be retrieved, state the exact limitation. Do not interpret unavailable consent information as absence of consent. DIRECTORY AND RESOURCE ROLE REVIEW Retrieve, when supported: - Microsoft Entra directory-role assignments involving the service principal - Eligible or active privileged assignments - Relevant Azure role assignments associated with a managed identity or workload identity - Assignment scope - Assignment creation date - Assignment actor, when available Prioritize highly privileged assignments, including role-management, directory-management, application-management, Exchange, SharePoint, security, or other broad administrative access. Do not classify a role assignment as excessive solely because it is privileged. Determine whether: - The role is required by the confirmed business purpose; - The scope is broader than necessary; - The assignment is permanent where temporary access is expected; - The assignment is undocumented or ownerless; - The role was assigned by an unexpected actor. If role-assignment data is unavailable, state that privileged access was not fully assessed. APPLICATION CONFIGURATION REVIEW Retrieve and assess when supported: - Sign-in audience - Redirect URIs and reply URLs - Public-client configuration - Identifier URIs - Exposed delegated scopes - Exposed application roles - Required resource access - User-assignment requirement - Enabled or disabled state - Notes, tags, or resource associations useful for governance Identify potential concerns such as: - Multitenant configuration where the available evidence indicates organization-only use - Unexpected or obsolete redirect URIs - Redirect URIs using insecure HTTP, except legitimate loopback development scenarios - Redirect URIs pointing to unowned or unrelated domains - Test, localhost, development, UAT, or temporary URLs on a production application - Public-client configuration inconsistent with the application type - Broad exposed scopes or roles without a documented purpose - Active configuration for an apparently retired project Do not declare a configuration unsafe without reporting the exact property and evidence. AUDIT REVIEW Review Microsoft Entra audit activity involving the application registration or service principal during the previous LookbackDays days. Prioritize: - Object creation - Owner changes - Credential additions or removals - Permission changes - Consent grants or revocations - App-role assignments - Directory-role assignments - Redirect URI changes - Sign-in audience changes - Enable or disable operations - Deletion and restoration activity For each material event, report: - UTC timestamp - Operation - Target object - Initiating actor - Result - Relevant changed properties - Whether the event is expected, unexplained, or requires validation Do not characterize an actor as unauthorized without supporting evidence. SIGN-IN AND ACTIVITY REVIEW Retrieve service-principal sign-in activity for the previous LookbackDays days when supported. Report: - Successful sign-ins - Failed sign-ins - First and latest observed activity - Source IP addresses - Geographic or network context, when available - Resource accessed - Credential or authentication method, when available - Failure reasons - Unusual changes in source or activity pattern Do not interpret no returned sign-ins as proof that the identity is unused. Distinguish among: - No activity was observed; - Sign-in data was unavailable; - Sign-in retention did not cover the full period; - The identity type does not produce the expected sign-in telemetry. RISK DECISION RULES Assign exactly one final decision: 1. No confirmed security deficiency 2. Manual business-owner validation required 3. Further technical security validation required 4. DevOps remediation story recommended 5. Immediate security investigation required 6. Insufficient evidence or permissions Use "No confirmed security deficiency" only when the available evidence supports the expected ownership, configuration, privileges, credentials, and activity, while clearly stating any residual limitations. Use "Manual business-owner validation required" when the primary gap is purpose, ownership, approval, or operational necessity rather than a confirmed technical weakness. Use "Further technical security validation required" when relevant technical evidence remains unresolved but there is not enough evidence for remediation or incident escalation. Use "DevOps remediation story recommended" only when all these conditions are met: - Organization ownership or governance is confirmed; - A specific security or governance deficiency is confirmed; - The evidence is identified; - The affected object is identified; - A concrete remediation action is available; - The issue is not more appropriately handled as an active security incident. Use "Immediate security investigation required" only when available evidence indicates a credible possibility of unauthorized access, credential misuse, unexpected privileged consent, suspicious role assignment, suspicious sign-in activity, or another compromise indicator. Use "Insufficient evidence or permissions" when required data could not be retrieved and no dependable risk conclusion can be made. Do not classify missing data itself as a vulnerability. DEVOPS STORY CRITERIA A DevOps remediation story may be recommended for confirmed conditions such as: - Excessive or unjustified granted application permissions - Unauthorized or unjustified tenant-wide admin consent - Excessive Microsoft Entra or Azure role assignment - organization-owned production identity without required accountable ownership - Unsafe credential lifetime that violates an established organizational standard - Unnecessary active credentials - Unsafe redirect URI or tenant-audience configuration - Privileged POC, test, UAT, or abandoned application left active - Retired application identity retaining access - Confirmed configuration inconsistent with the approved business purpose Do not recommend a DevOps story merely because: - The identity is new; - The identity is unmatched in the Change Monitor; - The identity is a managed identity; - The identity has no local application registration; - Publisher verification is missing; - The display name is unusual; - Requested permissions exist but were not granted; - Sign-in data is unavailable; - The business purpose is unknown. INCIDENT ESCALATION CRITERIA Recommend immediate security investigation instead of a routine DevOps story when evidence indicates: - Credential addition by an unexpected or unauthorized actor - Suspicious service-principal sign-ins - Unexpected high-impact consent - Unexpected privileged directory or Azure role assignment - Unauthorized application creation - Activity after the identity should have been disabled or retired - Evidence of token or credential misuse - Another credible compromise indicator Do not claim compromise without reporting the specific supporting evidence. OUTPUT FORMAT Return these sections: 1. Executive decision 2. Identity resolution 3. Ownership and purpose 4. Credential review 5. Permissions and consent review 6. Directory and Azure role review 7. Application configuration review 8. Audit activity 9. Sign-in activity 10. Confirmed findings 11. Collection limitations 12. DevOps story decision 13. Immediate investigation decision 14. Recommended next actions CONFIRMED FINDINGS TABLE Return one row for every confirmed or unresolved finding with: - Finding title - Affected object - Application ID - Object ID - Exact evidence - Risk level: Critical, High, Medium, Low, or Informational - Confidence: High, Medium, or Low - Finding state: Confirmed deficiency, Validation required, Expected configuration, or Insufficient evidence - Why it matters - Recommended action - DevOps story recommended: Yes, No, or Not yet - Immediate investigation recommended: Yes or No Do not combine unrelated findings into one row. Do not use placeholders, sample entries, grouped rows, or ellipses. DEVOPS STORY DECISION State: - Final decision - Whether the analyst should create a DevOps story - Exact confirmed deficiency, if any - Exact supporting evidence - Affected object IDs - Responsible team or owner, when established - Proposed remediation objective - Suggested acceptance criteria - Priority recommendation - Residual validation required If no confirmed deficiency exists, state exactly: "No DevOps remediation story is recommended based on the evidence currently available." If further evidence is needed, also state: "Additional validation is required before remediation is assigned." IMMEDIATE INVESTIGATION DECISION State: - Whether immediate security investigation is required - Exact compromise indicator, if any - Supporting event, actor, sign-in, permission, consent, role, or credential evidence - Immediate containment or investigation recommendation, without performing it If no compromise indicator was established, state exactly: "No immediate security investigation is recommended based on the evidence currently available." DATA PROVENANCE AND COMPLETENESS For every assessment area, mark the collection status as: - Complete - Partial - Unavailable - Unsupported - Permission denied - Not applicable Distinguish direct Microsoft Entra evidence from calculated or inferred observations. Do not describe the overall validation as complete when a security-relevant dataset was unavailable. At the end, report: - Identity resolution status - Identity-resolution method - Service-principal object ID input status - Number of matching application registrations - Number of matching service principals - Resolved service-principal object ID or IDs - Ownership-data status - Credential-data status - Permission-data status - Consent-data status - Directory-role-data status - Azure-role-data status - Configuration-data status - Audit-data status - Sign-in-data status - Number of confirmed deficiencies - Number of validation-required findings - DevOps story decision - Immediate investigation decision - Overall validation confidence: High, Medium, or Low FINAL LIMITATION End with exactly: "This validation is evidence-based and read-only. Missing or inaccessible Microsoft Entra data was not interpreted as proof of safety or proof of risk. Any remediation or containment action requires the analyst's review and the appropriate organizational authorization."