6. Worked Examples
The following examples illustrate how the framework is applied in practice. Each one scores a consent request at both layers, showing the raw score each factor contributes, its weighted impact on the composite score, and the resulting tier classification.
The two scenarios were chosen to bracket the model’s range: the first shows a well-governed internal app earning a low-friction outcome, while the second shows how application posture elevates a request that a permission-only evaluation would treat as routine. Together they demonstrate the framework’s central claim: the same permission can warrant very different handling depending on who is asking.
6.1 Example 1 — Internal HR app requesting basic read access
Section titled “6.1 Example 1 — Internal HR app requesting basic read access”Scenario: An internal HR dashboard registers a new app to pull basic profile data using User.Read. The app is owned by two full-time employees, uses certificate-based authentication with a managed identity, and has no secrets or wildcard URIs.
Application-level scoring
Section titled “Application-level scoring”| Factor | Raw Score | Weighted Score | Notes |
|---|---|---|---|
| Application Source | +0 | 0 | Internal |
| Tenant Breadth | +0 | 0 | Single-tenant |
| App Maturity | +0 | 0 | > 12 months |
| Redirect URI Method | +0 | 0 | Loopback |
| Redirect URI Ownership | +0 | 0 | Trusted HTTPS |
| User Assignment Enforcement | +0 | 0 | Restricted to HR group |
| Guest Access | +0 | 0 | Guests blocked |
| Publisher Verification | +0 | 0 | Internal (N/A) |
| M365 Certification | +0 | 0 | Not applicable |
| OAuth Client Class | +0 | 0 | Confidential |
| OAuth Flow Security | +0 | 0 | Authorization code + PKCE |
| Managed Identity Adoption | +0 | 0 | Used |
| Credential Strength | +0 | 0 | Certificate |
| Ownership Assignment | +0 | 0 | ≥ 2 full-time employee owners |
App Score (weighted composite): 0/100 → Low
All governance and hygiene signals are present: strong internal ownership, managed identity, and no external or user-facing exposure keep application risk at zero.
Permission-level scoring
Section titled “Permission-level scoring”| Factor | Raw Score | Weighted Score | Notes |
|---|---|---|---|
| Privilege Depth | +0 | 0 | None |
| Privilege Elevation | +0 | 0 | None |
| Impersonation Capability | +0 | 0 | None |
| App Role Bundles | +0 | 0 | None |
| Permission Type | +1 | 10 | Delegated |
| Permission Operation | +0 | 0 | Read |
| Permission Breadth | +0 | 0 | Self |
| Access Policy Modification | +0 | 0 | None |
| User Breadth | +0 | 0 | One user |
| Data Classification | +1 | 15 | Internal HR data |
| Exfiltration Potential | +0 | 0 | Read-only |
| Token Persistence | +0 | 0 | Short-lived |
| Legacy API Risk | +0 | 0 | Current Microsoft Graph scope |
Permission Score (weighted composite): 25/100 → Low
Delegated access to mildly sensitive HR data yields a low overall risk impact. Weighted permission scores scale more steeply than application scores: certain raw attributes such as tenant-wide write access or admin privileges can contribute up to 40–50 points each, but none are present here.
Outcome
Section titled “Outcome”Final Tier: Low. Fully governed internal app with minimal scope and low data exposure.
Under a permission-only model this request would also be rated low-risk — but so would the same scope requested by an ungoverned external app. Here, the low composite rating is earned by app posture, giving organizations a defensible basis for low-friction handling.
6.2 Example 2 — External verified app requesting Mail.Send
Section titled “6.2 Example 2 — External verified app requesting Mail.Send”Scenario: A third-party productivity assistant from a verified publisher requests Mail.Send (delegated) to send calendar invites and confirmations on behalf of users. The app operates across tenants and relies on user consent to function.
Application-level scoring
Section titled “Application-level scoring”| Factor | Raw Score | Weighted Score | Notes |
|---|---|---|---|
| Application Source | +2 | 15 | Verified ISV |
| Tenant Breadth | +2 | 15 | Multi-tenant |
| App Maturity | +0 | 0 | > 12 months |
| Redirect URI Method | +1 | 5 | Static web |
| Redirect URI Ownership | +1 | 5 | External HTTPS |
| User Assignment Enforcement | +2 | 10 | Visible to all users |
| Guest Access | +2 | 10 | Guests enabled |
| Publisher Verification | +0 | 0 | Verified |
| M365 Certification | +0 | 0 | Not certified |
| OAuth Client Class | +0 | 0 | Confidential |
| OAuth Flow Security | +0 | 0 | Authorization code |
| Managed Identity Adoption | +2 | 10 | Not applicable |
| Credential Strength | +0 | 0 | Certificate |
| Ownership Assignment | +0 | 0 | External publisher |
App Score (weighted composite): 70/100 → High
App-level risk is elevated by multi-tenant design, guest visibility, and the absence of internal governance anchors. Each factor’s raw score maps to a weighted contribution based on severity: multi-tenancy (+2 raw) contributes 15 points, while guest access (+2) adds 10.
Permission-level scoring
Section titled “Permission-level scoring”| Factor | Raw Score | Weighted Score | Notes |
|---|---|---|---|
| Privilege Depth | +0 | 0 | None |
| Privilege Elevation | +0 | 0 | None |
| Impersonation Capability | +2 | 15 | Send-as capability |
| App Role Bundles | +0 | 0 | None |
| Permission Type | +1 | 10 | Delegated |
| Permission Operation | +1 | 10 | Send |
| Permission Breadth | +0 | 0 | User only |
| Access Policy Modification | +0 | 0 | None |
| User Breadth | +0 | 0 | Per-user consent |
| Data Classification | +2 | 17 | Email content |
| Exfiltration Potential | +0 | 0 | Usage-limited |
| Token Persistence | +0 | 0 | Short-lived |
| Legacy API Risk | +0 | 0 | Current Microsoft Graph scope |
Permission Score (weighted composite): 52/100 → Medium
Even without admin-level access, the ability to send messages as a user elevates the composite score into the Medium tier.
Outcome
Section titled “Outcome”Final Tier: High. This is the case the dual-layer model exists for.
A permission-only model would rate Mail.Send as Medium, blind to the app container. Here, the app’s multi-tenant reach, guest exposure, and lack of governance drive the composite rating to High, signaling that this request warrants elevated scrutiny regardless of how routine the permission appears.
OARS §6 is derived from the Graph Consent Risk Framework by Khurram Chaudhary. Licensed CC BY 4.0.
OARS — Open App Risk Standard is derived from the Graph Consent Risk Framework by Khurram Chaudhary.
Specification and dataset licensedCC BY 4.0; tooling and site licensed MIT. © 2026 Khurram Chaudhary and the Citadel Project contributors.
A Citadel Project standard ·GitHub ·Cite this standard