Permission
Governance

Permission governance was a known friction point in the internal app-publishing pipeline. Reviewers struggled to keep pace with hundreds of requests and evolving API scopes. Developers lacked clear criteria for what constituted “safe” access, leading to back-and-forth cycles and inconsistent decisions.

/01Limited SME bandwidth: experts available only a few hours weekly.

/02Inconsistent documentation: fragmented across wikis and chats.

/03Early AI unreliability: hallucinations and misclassifications in prior prototypes.

/04Need for tiered risk clarity: balancing flexibility with data-protection rigor.

Approval cycleunder 10 business days from 20-30 days

SME workshops revealed the full set of workflow dependencies and failure points across the permission-evaluation process. From these sessions, I structured the domain into nested categories: Permission Risk Tiers, Role-Based Access Models, and Content Collections, so the Copilot could reason with consistent hierarchy.

I authored a scalable “General Instructions” prompt that defined how the agent should interpret confidence thresholds, trigger escalations, and provide contextual follow-up guidance.

We introduced a two-tier classification model separating Allowed (low-risk, pre-approved) permissions from Restricted ones requiring human review. Evaluation criteria were anchored in data sensitivity, tenant impact, and delegation scope, ensuring decisions aligned to established governance policies. To build user trust, the system included concise “why restricted” explanations that clarified the rationale behind each classification.

The prototype implemented an adaptive conversation flow: clarify, classify, recommend, that mirrored the steps SMEs take during real reviews.

Probabilistic reasoning was made legible through confidence statements such as “likely safe” or “requires review,” helping users understand reliability at each step.

The system was tested using anonymized historical requests, refined the logic to reduce unsupported queries, and presented the working prototype to Security, Privacy, and Architecture leads. Their feedback on tone, accuracy, and traceability informed the next-phase roadmap, including App ID lookup integration, threat-model validation, and expansion into additional governance scenarios.

The Copilot was designed to provide a structured, explainable pathway through complex permission decisions. Its conversational UX interprets developer intent, classifies requested permissions by risk, and recommends least-privilege alternatives. The information architecture links API scopes to risk tiers and RBAC guidance through a clear hierarchical schema, while the logic framework follows a consistent pattern of:classification → confidence → rationale → resourcesto maintain alignment across responses. Supporting artifacts including a prompt map, risk-model diagram, knowledge-base schema, and sample interactions for ensured internal coherence.

The overall system is grounded in three principles: transparency, traceability, and human-in-the-loop control.

The redesigned permission-evaluation system modeled a reduction in re-review rates from 32% to roughly 10%, potentially freeing over 100 SME hours per month.

By standardizing evaluation logic across teams, it brought consistency to a historically fragmented review process. The underlying framework proved scalable and was later adapted for additional internal Copilots supporting access governance and self-service scenarios. Most importantly, it contributed to a cultural shift: positioning AI not as a novelty, but as a trusted compliance partner in high-stakes decision-making.