Workflow Permission Scanner for Security Risk Reduction

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing technologies face challenges in ensuring users are aware of and consent to the precise permissions required by workflows and applications, leading to potential security risks due to excessive or malicious permission requests.

Innovation Solution

A machine code executable scanner generates a permission summary from workflow or code definitions, which is presented to the user for review and consent, ensuring that only necessary permissions are granted and cached for future instances.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If authors manually declare scopes/permissions for a workflow or application, then the workflow can be deployed, but the user may consent to permissions not used by the workflow creating a security risk

Engineering Contradiction:
Improveease of workflow deploymentVSAvoidsecurity risk from excessive permissions
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The system performs preliminary scanning of the workflow definition and code to automatically generate an accurate permission summary before deployment. This preliminary action ensures that only the permissions actually required by the workflow are presented to the user for consent, eliminating the security risk of excessive permissions while maintaining ease of deployment.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The workflow automatically identifies and declares its own required permissions through self-scanning of its definition and code, without relying on manual author declaration. This self-service mechanism ensures accuracy of permission requests while simplifying the deployment process.

Inventive Principle:
Principle #25Self-service

2Loss of time

If authors request excessive permissions just in case for future features, then subsequent permission requests are avoided, but permissions granted are not aligned with permissions used creating a security risk

Engineering Contradiction:
Improvetime for permission requestsVSAvoidsecurity risk from misaligned permissions
Core Design Contradiction:
Loss of timeVSReliability

Solution Approach 1:

The system performs a comprehensive preliminary scan of the entire workflow definition and all associated code to accurately determine all permissions that will be required during execution. This thorough preliminary action eliminates the need for authors to request excessive permissions in advance, as the system can predict all future permission needs with precision.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system provides feedback to the user about the exact permissions that will be used by the workflow, based on actual code analysis. This feedback mechanism allows users to make informed consent decisions while ensuring that only necessary permissions are granted, preventing the security risk of misaligned permissions.

Inventive Principle:
Principle #23Feedback

3Ease of operation

If users are asked to provide credentials when a workflow is shared, then the workflow can access user resources, but users do not know what the workflow intends to do with their connections

Engineering Contradiction:
Improveease of workflow sharingVSAvoidinformation about intended credential usage
Core Design Contradiction:
Ease of operationVSLoss of information

Solution Approach 1:

The workflow automatically generates and presents its own permission summary to the user, providing clear information about what the workflow intends to do with their credentials. This self-service information provision maintains ease of workflow sharing while eliminating the information gap that prevents users from making informed decisions.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system provides comprehensive feedback to the user about the intended use of their credentials by the workflow, including a detailed permission summary generated from actual code analysis. This feedback enables users to understand exactly what their connections will be used for before granting access.

Inventive Principle:
Principle #23Feedback

4Adaptability or versatility

If an author requests permissions for features not included in current version but might be added, then future permission requests are avoided, but the permissions are excessive and create security risk

Engineering Contradiction:
Improveadaptability to future featuresVSAvoidsecurity risk from excessive permissions
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary analysis of the workflow definition and code to accurately identify only the permissions required for the current version of the workflow. This preliminary action with precise code analysis allows the system to adapt to future feature additions without currently requesting unnecessary permissions, maintaining security while preserving adaptability.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS12254069B2Identifying and consenting to permissions for workflow and code execution
Publication Date: 2025.03.18 MICROSOFT TECHNOLOGY LICENSING LLC
  • US12254069B2 patent drawing
  • US12254069B2 patent drawing
  • US12254069B2 patent drawing

AI summary

The present invention extends to methods, systems, and computer program products for identifying and consenting to permissions for workflow and code execution. Aspects of the invention can be used to automatically scan a workflow or code definition to identify (potentially all) the actions/triggers a workflow or program intends to perform on behalf of a user. The user is shown the actions/triggers the workflow or program intends to perform (e.g., at a user interface) before consent to perform the actions/triggers is granted. As such, a user is aware of intended actions/triggers of a workflow or program before granting consent. Further, since actions/triggers are identified from the workflow or code definition (and not formulated by an author), permission requests better align with permissions that workflow or program functionality actually uses during execution.