Method for dynamically configuring artificial intelligence service permissions for one-person company

Abstract

The application discloses an artificial intelligence service permission dynamic configuration method for a one-person company, and relates to the technical field of access control. Heterogeneous service interfaces are converted into capability atoms, and a permission envelope is formed according to an immutable versioned task dependency graph; when task re-planning is performed, new and old permission envelopes are compared, an affected causal closure is determined based on downstream dependencies, resource read-write conflicts and credential lineage, external side effect calls in the closure are frozen, permissions are revoked and removed, in-transit calls are liquidated and a right withdrawal confirmation vector is aggregated; when the right withdrawal confirmation vector meets switching conditions, a permission transition barrier is generated, an atomic task graph version and the permission transition barrier are submitted, and temporary capability credentials bound to both are activated; otherwise, only a safe intersection permission set is opened, and the safe intersection permission set cannot be determined, and a failure shutdown is performed. The application also discloses corresponding electronic equipment and a computer program product.

Description

Technical Field

[0001] This invention relates to the field of computer security and access control technology, specifically to a method and apparatus for dynamically configuring artificial intelligence service permissions for one-person companies, electronic devices, and computer program products. Background Technology

[0002] Dynamic configuration of AI service permissions for a one-person company refers to a situation where a single operator calls various heterogeneous AI services, such as models, retrieval, document processing, message sending, and collaborative publishing, to complete complex tasks through a unified task entry point. Existing platforms generally restrict services, resources, operations, and parameters based on roles, attributes, task context, and access tokens, and perform permission verification before invocation.

[0003] Chinese patent document CN121456904A discloses a method for secure access and report generation of heterogeneous databases based on model context protocols and intelligent agents. This method receives a task request and task context, obtains synchronized capability declarations from adapters of multiple databases, and performs normalization operations to obtain a capability graph and corresponding capability version identifiers. It semantically maps access policies and data hierarchical constraints to the capability graph, obtaining policy inline rewriting rules and rewrite digest fingerprints, and issues a minimum-privilege access token based on these rules. After the intelligent agent generates a cross-source query, it forces a rewrite of the query at compile time and checks the consistency of the access token, rewrite digest fingerprint, and capability version identifier in a controlled execution environment. Then, under structured template constraints, it generates a report and writes the task request, capability version, access token, and report fingerprint to a chained audit log for easy reproduction of the execution process and verification of results.

[0004] The aforementioned existing technologies can query and constrain tokens for a given task context and capability version. However, in cases of target changes, branch cancellations, service replacements, or abnormal replanning during the execution of composite tasks, the revocation of old task permissions, the granting of new task permissions, and the confirmation of in-transit calls may be completed by different policy execution points. Furthermore, the revocation capabilities, state propagation latency, and acknowledgment mechanisms of each execution point may differ, leading to situations where old permissions can still be accepted while new permissions have already taken effect. Old version requests, asynchronous callbacks, and retry requests that have entered the queue or are being executed will continue to modify external resources. Relying solely on the natural expiration of tokens cannot confirm whether old calls have been accepted or whether in-transit calls have terminated. Suspending all services would interrupt read-only branches unrelated to task changes.

[0005] Therefore, it is necessary to address the issues of parallel execution of new and old permissions and the continued external side effects of calling old versions during the replanning of heterogeneous artificial intelligence services. Summary of the Invention

[0006] (a) Technical problems to be solved

[0007] To address the shortcomings of existing technologies, this invention provides a method and apparatus for dynamically configuring AI service permissions for one-person companies. It aims to solve the problem of overlapping permissions (i.e., old permissions being revoked, new permissions being granted, and in-transit call confirmations occurring at different policy execution points) when a single operator calls multiple heterogeneous AI services from the same task entry point to complete a composite task. This is particularly relevant when the task objective changes, execution branches are canceled, the called services need to be replaced, or abnormal situations require replanning. Furthermore, the old task graph version may have asynchronous callbacks, queued messages, or retry requests continuing to drive downstream nodes, thus altering external resources. Simultaneously, this invention resolves the issue of unnecessary blocking of read-only execution branches unrelated to task changes when using a global pause method to handle permission switching.

[0008] (II) Technical Solution

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A method for dynamically configuring AI service permissions for one-person companies, executed by a permission configuration server, includes: converting heterogeneous service interfaces into capability atoms and forming permission envelopes based on a versioned task dependency graph;

[0011] During task replanning, a new task graph version and permission envelope are generated. The old and new permission envelopes are compared to obtain the set of removed permissions, the set of added permissions, and the set of common permissions. The affected causal closure is determined according to the downstream dependencies of the changed nodes, resource read / write conflicts, and credential hierarchy. Subsequent external side effect calls within the closure are frozen, the set of removed permissions is revoked, in-transit calls are liquidated, and the revocation confirmation vector is aggregated.

[0012] When the revocation confirmation vector confirms the removal of permission isolation and the conflicting in-transit call has been terminated, a permission transition barrier is generated, a new task graph version and permission transition barrier are atomically submitted, and the corresponding added permission set is activated and the temporary capability credentials of the version and the barrier are bound; otherwise, the executable permissions are restricted to the safe intersection permission set obtained by subtracting the side effect capabilities of the affected causal closure from the public permission set. If the safe intersection permission set is uncertain, the execution fails and is closed.

[0013] Furthermore, the affected causal closure starts from a node that has undergone at least one of deletion, addition, replacement, and input failure, and obtains downstream nodes along the data dependencies, control dependencies, authorization dependencies, and compensation dependencies related to the change in the old and new task graph versions. It also merges conflicting nodes that access the same resource as the changed node and at least one of them has write behavior, as well as nodes that share at least one of upstream service credentials, execution pre-summary, and derived authorization chains. If the conflict state can be determined, it is processed according to the determined result; if it cannot be determined, it is processed as if a conflict exists.

[0014] Furthermore, the revocation confirmation vector is aggregated in a fixed order of service identifier and policy execution point identifier. Each service component includes the revocation processing result, the last accepted call sequence number, the in-transit call status, the service resource version, and the service adapter capability description version.

[0015] When the target service provides a native invocation sequence number, this sequence number is used. If it is not provided, the invocation execution gateway and service adapter of the permission configuration server establish a monotonic sequence number space based on the task identifier, service identifier, and temporary capability credential identifier, and increment it only when the invocation is accepted by the controlled execution point.

[0016] A device for dynamically configuring AI service permissions for one-person companies, including:

[0017] The module includes a service capability registration module for mutual communication, a versioned task graph compilation module, a permission envelope calculation module, a permission reconfiguration control module, a temporary credential issuance module, a call execution gateway and service adapter, and a permission status and evidence storage module.

[0018] The service capability registration module converts heterogeneous service interfaces into capability atoms, the versioned task graph compilation module generates an immutable versioned task dependency graph based on task input and capability atoms, and the permission envelope calculation module forms a permission envelope based on the versioned task dependency graph.

[0019] When the versioned task graph compilation module receives a task replanning event, it generates a new task graph version. The permission envelope calculation module forms a corresponding new permission envelope. The permission reconfiguration control module compares the old and new permission envelopes to obtain the set of removed permissions, the set of added permissions, and the set of common permissions. It then determines the affected causal closure based on the downstream dependencies of the changed nodes, resource read / write conflicts, and credential hierarchy.

[0020] The permission reconfiguration control module controls the call execution gateway and service adapter to freeze external side effect calls within the affected causal closure, revoke and remove permissions from the permission set, liquidate in-transit calls, and aggregate the revocation confirmation vector.

[0021] When the revocation confirmation vector meets the switching conditions, the permission status and evidence storage module atomically submits the new task graph version, permission transition barrier, and switching status. The temporary credential issuance module activates the corresponding temporary capability credential that adds a permission set and binds the new task graph version and permission transition barrier. The execution gateway and service adapter are then called to verify the call based on the new task graph version, permission transition barrier, and temporary capability credential. When the revocation confirmation vector does not meet the switching conditions, the permission reconfiguration control module restricts the executable permissions to the safe intersection permission set obtained by subtracting the affected causal closure's internal and external side effect capabilities from the public permission set. If the safe intersection permission set is uncertain, the module will close the execution if it fails.

[0022] An electronic device includes a processor, a memory, a communication bus, and a network interface. The processor, the memory, and the network interface are connected via the communication bus. The memory stores a computer program. When the computer program is executed by the processor, the electronic device receives task input, sends controlled calls, and receives service receipts through the network interface, and implements the aforementioned method for dynamically configuring artificial intelligence service permissions for one-person companies.

[0023] A computer program product includes a computer program that, when executed by a processor, enables an electronic device to implement the aforementioned method for dynamically configuring artificial intelligence service permissions for a one-person company.

[0024] (III) Beneficial Effects

[0025] The beneficial effects of this invention are as follows:

[0026] Heterogeneous AI service interfaces are converted into capability atoms, and a permission envelope is formed by a set of permission requirements, a set of permission limits, a set of service permissions, and a set of context constraints. This allows the operations, resources, and invocation conditions of different services to be compared within a unified boundary, avoiding permission expansion caused by authorization based on service name.

[0027] By using an immutable versioned task dependency graph to save the state before and after replanning, and combining permission envelope differential, downstream dependency, resource read / write conflict and credential hierarchy to form affected causal closure, freezing and revocation are concentrated on change-related nodes, reducing the blocking of irrelevant read-only branches.

[0028] First, freeze external side effect calls within the affected causal closure, then revoke the removal permission and liquidate in-transit calls. Aggregate the revocation result, the last accepted call sequence number, and the in-transit call status into a revocation confirmation vector, so that permission switching is based on the isolation facts of the old permission, reducing the risk of parallel execution of the old and new permissions.

[0029] By reconstructing the call normalization tuple through the execution gateway and service adapter, and verifying the task graph version, permission transition barrier, capability atom, resource selector, parameter digest, execution pre-digest, and call sequence number, unverified fields cannot expand the trusted call boundary.

[0030] When the authorization revocation confirmation is incomplete, it is limited to a safe intersection set of permissions. If this set cannot be determined, the execution fails and is shut down. At the same time, the asynchronous callback of the old version is isolated through the permission evidence chain, so that the degradation is controlled when communication is interrupted, receipts are lost, state storage is abnormal, and version drift occurs, and a basis is provided for verification and abnormal recovery. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the overall architecture for dynamic configuration of AI service permissions for one-person companies, provided in an embodiment of the present invention.

[0032] Figure 2 A flowchart illustrating the overall process of dynamically configuring permissions for artificial intelligence services provided in this embodiment of the invention;

[0033] Figure 3 This is a schematic diagram illustrating the formation of service capability descriptions, capability atoms, and permission envelopes provided in embodiments of the present invention.

[0034] Figure 4 The first version of the task dependency graph, the second version of the task dependency graph, and the schematic diagram of the formation of the affected causal closure are provided for embodiments of the present invention;

[0035] Figure 5 A timing diagram for the issuance and invocation boundary verification of temporary capability credentials provided in this embodiment of the invention;

[0036] Figure 6 This is a sequence diagram of permission switching during task replanning based on the principle of "cancel first, grant later" provided in an embodiment of the present invention.

[0037] Figure 7 This is a schematic diagram of the permission switching state machine and the security intersection permission set downgrade provided in an embodiment of the present invention;

[0038] Figure 8 This is a schematic diagram of the implementation architecture of the virtual device and electronic device provided in the embodiments of the present invention;

[0039] Figure 9 This is a schematic diagram illustrating the centralized and distributed revocation confirmation implementation methods provided in this embodiment of the invention;

[0040] Figure 10 This is a schematic diagram illustrating the permission evidence chain and the isolation of asynchronous callbacks in older versions, provided for embodiments of the present invention. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Please see Figures 1 to 10 This invention provides a method and apparatus for dynamically configuring artificial intelligence service permissions for one-person companies, and provides corresponding electronic devices and computer program products.

[0043] Existing AI service orchestration platforms typically use role-based access control, attribute-based access control, continuous access evaluation, or access tokens to define the scope of services that can be invoked, such as models, retrieval, documents, and external operations. While task-level authorization, parameter source constraints, and graph-based permission verification can narrow the boundaries of tools, resources, and parameters, they only address the issue of invocation permissions at a single point in time. When the goal of a complex task changes, a branch is canceled, a tool is replaced, or an anomaly occurs requiring replanning, the revocation of old permissions, the granting of new permissions, and the confirmation of in-transit calls are handled separately by different heterogeneous policy execution points. This time inconsistency in propagation can lead to the short-term coexistence of old and new permissions. Furthermore, asynchronous callbacks, queued messages, or retry requests from older versions may still alter external resources. Simply shortening the credential lease period cannot eliminate the problems remaining within the lease period, and a global pause will block irrelevant read-only branches.

[0044] This implementation aims to solve the following technical problem: when one operator calls multiple heterogeneous artificial intelligence services through a unified task entry to complete a composite task and the task is replanned, how to prevent the old permissions and new permissions within the affected scope from forming a permission overlap state that can be executed simultaneously, and how to prevent the old task graph version from continuing to drive downstream nodes or generate external side effects, under the conditions that the service's permission revocation capability, policy propagation delay, and in-transit call processing method are inconsistent.

[0045] Therefore, this implementation incorporates task execution status and permission status into the same version switching control domain. The permission configuration server 20 converts heterogeneous AI service interfaces into capability atoms and forms permission envelopes based on an immutable versioned task dependency graph. During task replanning, it calculates the removal permission set, addition permission set, and common permission set of the old and new permission envelopes, forming an affected causal closure. Subsequently, it freezes new external side-effect calls within the closure, first revoking removal permissions and clearing in-transit calls, then aggregating the revocation confirmation vector. Only after the switching conditions are met is a permission transition barrier generated and temporary capability credentials binding the new task graph version and the permission transition barrier activated. If the confirmation is incomplete, only the safe intersection permission set is opened or closed upon execution failure.

[0046] like Figure 1 As shown, the operator submits a composite task to the permission configuration server 20 through the terminal device 10. The permission configuration server 20 includes a task input and normalization module 100, a versioned task graph compilation module 200, a service capability registration module 300, a permission envelope calculation module 400, a permission reconfiguration control module 500, a temporary credential issuance module 600, a call execution gateway and service adapter 700, a permission status and evidence storage module 800, and a feedback and anomaly monitoring module 900. The task input and standardization module 100 provides standardized tasks to the versioned task graph compilation module 200; the service capability registration module 300 provides service capability descriptions and capability atoms to the versioned task graph compilation module 200 and the permission envelope calculation module 400; the permission envelope calculation module 400 provides permission envelopes to the permission reconfiguration control module 500 and the temporary credential issuance module 600; the permission reconfiguration control module 500 controls the call execution gateway and service adapter 700 to perform permission switching and exchanges switching status with the permission status and evidence storage module 800; the call execution gateway and service adapter 700 sends controlled calls to the knowledge data service 31, document service 32, email service 33 and collaborative publishing service 34 and receives service receipts, the service receipts and call status are written to the permission status and evidence storage module 800, and the feedback and anomaly monitoring module 900 feeds back the anomaly monitoring results to the permission reconfiguration control module 500 based on the evidence storage status.

[0047] Figures 1 to 10 The module names and numerical reference numerals in the figure all adopt the aforementioned standard names. Figure 2 S101 to S106 in the text are the method step numbers; Figure 4 The retrieval, reading, generation, writing, verification, email sending, and collaborative publishing functions are used as task node names. Figure 7 The states of stable, ready, silent, revoked, barrier ready, activated, new stable state, downgraded and rollback are the permission switching states. Figure 9The external services A to C and policy execution points A to C are shown as implementation objects and are not labeled with numbers. The arrows in each figure represent task input, controlled invocation, service receipt, status reading, access control, or status transition, respectively.

[0048] like Figure 1 and Figure 3 As shown, a one-person company AI service environment refers to a computing environment where a task is initiated by a single human operator and executed collaboratively by multiple software services, without being limited by the number of registered employees, organizational structure, approval levels, or fee rules. AI services include model services and tool services for performing retrieval, file reading and writing, message sending, content publishing, or code manipulation. Controlled call boundaries mean that external side-effect calls must pass through the call execution gateway and service adapter 700 or an equivalent policy execution point to complete task graph version, permission transition barriers, and parameter constraint verification; bypass credentials that bypass the execution point are not within the control scope of this implementation.

[0049] like Figure 3 As shown, the service capability description is a standardized data object maintained by the service capability registration module 300, recording the service identifier, interface version, operation type, resource scope, field scope, side effect category, revocation method, and invocation constraints. A capability atom is the smallest indivisible authorized unit, composed of a service identifier, operation identifier, resource selector, field mask, side effect category, maximum number of invocations, and execution preconditions. The resource selector limits the path, object, or value range; the field mask limits the fields that are allowed to be read or written; the resource audience limits the target service that the temporary capability credentials can be used for; the parameter digest is calculated from the invocation parameters after type unification, field sorting, and resource identifier normalization. When the operation boundary cannot be determined, the corresponding capability atom does not enter the issueable set.

[0050] like Figure 4 As shown, the versioned task dependency graph is a directed task representation generated by the versioned task graph compilation module 200. Data dependency edges are established when upstream output constitutes downstream input; control dependency edges are established when downstream activation depends on upstream completion, failure, or verification status; authorization dependency edges are established when temporary capability credential issuance depends on upstream authorization results or output digests; and compensation dependency edges are established when reverse processing steps have been registered. Figure 4 Solid lines, dashed-dot lines, and dotted lines are used to represent control dependencies, data dependencies, and resource or credential associations, respectively. Dashed-line closed boundaries represent affected causal closures. Authorization dependencies and compensation dependencies can also be recorded as edge types or node attributes. Each replanning generates an immutable new version. Node records include node identifier, executed service, input / output labels, resource read / write sets, side effect category, predecessor node, compensation node, and execution state, in order to reject asynchronous callbacks from the old version and cross-version calls.

[0051] like Figure 3 As shown, the set of maximum permissions is the maximum set of capabilities that can be granted pre-defined by the operator or security baseline; the set of permission requirements is the set of permissions required by the service derived from the valid nodes in the current versioned task dependency graph; the set of permitted services is the set of services declared by the service policy execution point or obtained through mapping via an adapter; and the set of context constraints consists of resource versions, node states, operator restrictions, and corresponding service states. The intersection of these sets is the permission envelope, which is the boundary of permissions that can be signed and executed under a specific task graph version.

[0052] like Figure 4 and Figure 6 As shown, the permission switching differential includes the removal permission set, the addition permission set, and the common permission set of the old and new permission envelopes. The affected causal closure starts from the changed node and merges the downstream nodes, resource read / write conflict nodes, and shared credential genealogy nodes in the old and new versioned task dependency graphs; the credential genealogy refers to the relationship where temporary capability credentials are derived from the same upstream authorization, execution pre-summary, or revocable service credentials. Figure 4 The dashed closed boundary in the diagram spans both the old version's checksum and email sending nodes and the new version's checksum and collaborative publishing nodes. It is only used to illustrate the scope of the changes, and the actual affected causal closure is still determined according to the above rules.

[0053] like Figure 6 and Figure 9 As shown, the revocation confirmation vector is a set of revocation facts aggregated by the permission reconfiguration control module 500 according to a fixed order of service identifier and policy execution point identifier. Its structure can be represented as:

[0054]

[0055] in, Represents the withdrawal confirmation vector; Indicates the number of service components or policy execution points within the affected causal closure that require confirmation of withdrawal, and is a positive integer; Indicates the first Service portions The value ranges from 1 to ; The status indicates the result of the revocation process, and its status includes at least revoked, isolated by the local policy enforcement point, failed, and unknown. This represents the last call sequence number accepted by the service, which is a monotonically non-decreasing non-negative integer; This indicates the status of a call in transit or a set of call identifiers in transit; Indicates the service resource version; This indicates the version of the service adapter capability description. When the service native interface does not provide the last accepted call sequence number, the call execution gateway and service adapter 700 establish an independent sequence number space based on the task identifier, service identifier, and temporary capability credential identifier, and increment the call sequence number only when the call is accepted by the controlled execution point.

[0056] The permission transition barrier is generated from the task identifier, the old task graph version, the new task graph version, the affected causal closure summary, the revocation confirmation vector summary, and the monotonic commit sequence number. Temporary capability credentials are bound to at least the task identifier, node identifier, task graph version, capability atom, resource audience, parameter constraints, maximum number of calls, execution pre-summary, and the current permission transition barrier. The execution pre-summary is calculated by normalizing the predecessor output, resource version, and necessary context states according to a fixed field order. The permission transition barrier binds the executability of the new permission to the fact that the old permission isolation has already been completed.

[0057] like Figure 5 As shown, the call normalization tuple is reconstructed by the call execution gateway and service adapter 700 according to the registered interface pattern, and includes service identifier, operation identifier, resource, parameter summary, data source summary, task node, task graph version, and call sequence number. During reconstruction, resource paths, parameter data types, time representations, multi-value field order, and default values ​​are standardized; unrecognized fields cause the call to remain rejected or pending. The AI ​​agent can only submit call requests and cannot independently declare trusted nodes, data sources, or permission transition barrier states.

[0058] like Figure 7 and Figure 10 As shown, the secure intersection permission set is based on the common permission set of the old and new permission envelopes, excluding external side effects capabilities within the affected causal closure; resource selectors, parameter digests, execution pre-digests, or resource versions are also excluded if they cannot be proven to be equivalent. External side effects are sending, publishing, modifying, deleting, or code commit operations that change the externally observable state of the service.

[0059] The permission evidence chain records the task graph version, authorization decision, temporary capability credential issuance, call interception, service receipt, permission revocation confirmation, and permission transition barrier switching in the order of events, and is used to replay the causal relationship of permission status changes.

[0060] The linearized commit point for permission transition is the point at which the permission state and evidence storage module 800 atomically compare and exchange, or equivalently commit, the current task graph version, permission transition barrier, and transition state simultaneously. A silent state is a transitional state where nodes within the affected causal closure stop accepting new external side-effect calls but continue performing state reads, in-transit call liquidation, and revocation. A failure close is when external side-effect calls are rejected because the current task graph version, permission transition barrier, or temporary capability credential state cannot be reliably obtained.

[0061] In the example of this implementation, This represents the normalized target recipient digest identifier. This represents the target collaborative workspace identifier; both are example resource identifiers and are not limited to a specific encoding format. Unless otherwise specified, the task graph version, call sequence number, commit sequence number, maximum number of calls, and number of iterations are all dimensionless integers; the unit for the temporary capability credential lease period and the upper limit of the revocation wait is seconds; sets, summaries, resource versions, and status enumerations do not have physical quantity units.

[0062] like Figure 1 As shown, this embodiment assumes one operator generates and delivers a weekly report. Terminal device 10 submits a task to read newly added data from a specified directory, generate the weekly report, save it to the output directory, and send it to a designated contact person after verification. Knowledge resource service 31 is responsible for retrieval and reading, document service 32 is responsible for writing and rereading, and email service 33 is responsible for sending. During task execution, the delivery path can be changed to collaborative publishing service 34. The permission configuration server 20 can be implemented by a single computing node or multiple processes, but the task graph version, permission version, and credential status must form the same serialized status view between the permission status and the evidence storage module 800. Terminal device 10 does not hold long-term service credentials for knowledge resource service 31, document service 32, email service 33, or collaborative publishing service 34.

[0063] like Figure 1 As shown, the task input and normalization module 100 includes: task access, field parsing, and deterministic constraint parsing logic. It accepts the task text, allowed resources, prohibited resources, receiving objects, time range, permission limit version, and external side effect permissions. After removing meaningless whitespace, all characters are uniformly encoded (e.g., resource paths and times), current directory entries and parent directory entries included in the path are removed, and multiple values ​​are sorted by field name. The receiving object, workspace, and document identifier are converted into stable identifiers or summaries. Then, the normalized task description and task root summary are output to the versioned task graph compilation module 200, and the original task summary, operator identity reference, and permission limit version are written to the permission status and evidence storage module 800. Receiving objects, output directories, or target services that are not unique are unsignable. Optionally, natural language is only used for candidate extraction, and finally, deterministic rules are used to solidify the boundaries.

[0064] like Figure 2As shown, step S101 is performed by the task input and normalization module 100. This module generates a task identifier, a normalized resource selector, explicit prohibitions, and a task root summary, and sends a compilation request to the versioned task graph compilation module 200. For example, reading resources is normalized to the / weekly report / source data directory and the current week's time window; writing resources is normalized to the / weekly report / output directory; and external receiving objects are converted into target receiving object summary identifiers. If the task text also includes a statement to send the weekly report to all relevant personnel without specifying verifiable recipients, then the sending action corresponding to that statement remains disabled. Therefore, subsequent task nodes do not need to rely on the model to infer resource boundaries again.

[0065] like Figure 3 As shown, the service capability registration module 300 can be composed of an interface directory, pattern parsing logic, and a versioned capability mapping table. This module receives interface versions, operation names, resource fields, parameter patterns, revocation methods, and receipt semantics from the knowledge resource service 31, document service 32, email service 33, and collaborative publishing service 34, and uniformly converts heterogeneous interfaces into capability atoms. In this embodiment, the first capability atom corresponds to the knowledge resource service 31 searching within the / weekly report / source data scope, executing a maximum of 3 times and requiring the return of a source summary; the second capability atom corresponds to reading the document identifier set returned by the first capability atom; the third capability atom corresponds to the model generating weekly report content without external tool call permissions; the fourth capability atom corresponds to the document service 32 writing to / weekly report / output / report_version 1; the fifth capability atom corresponds to reading back the file for verification; and the sixth capability atom corresponds to the email service 33 sending the summary identifier to the target recipient. Sending attachments requires the attachment digest to be equal to the output digest of the 4th capability atom, with a maximum of one call; the 7th capability atom corresponds to the collaboration publishing service 34, which identifies the target collaboration workspace. The maximum number of times the same document can be published in the report channel is one. The service capability registration module 300 marks operations as read-only, internal computation, internal write, or external side effects based on whether the operation changes the external observable state of the service; when the meaning of the interface field, resource scope, or revocation method cannot be identified, it is not presumed to be equivalent to a similar interface, and the corresponding external side effect capability is kept in an unsignable state.

[0066] like Figure 2 and Figure 4As shown, step S102 is executed by the versioned task graph compilation module 200. This module constructs the first versioned task dependency graph based on the normalized task and capability atoms, and sequentially sets up retrieval, reading, generation, writing, readback verification, and email sending nodes; it establishes data dependencies, control dependencies, authorization dependencies, and compensation dependencies based on field mapping, node activation conditions, temporary capability credential issuance conditions, and registered compensation operations. The email sending node is activated only when the verification passes and the attachment digest matches the write digest. This module allocates monotonically increasing task graph versions and writes the graph structure and node status to the permission status and evidence storage module 800.

[0067] like Figure 4 As shown, the retrieval nodes in the first versioned task dependency graph are initially in an executable state, while the remaining nodes are in a waiting state. The versioned task graph compilation module 200 executes dependency slicing forward from the target delivery node to obtain the set of nodes required to complete the current task graph version, and outputs the node capability requirements, resource read set, resource write set, and side effect category to the permission envelope calculation module 400. During compilation, undeclared loops are detected through topological sorting; for paginated retrieval or limited retries, the loop is expanded to the maximum number of iterations. Constrained bounded nodes, and Determined by task constraints or service pagination limits. In some embodiments, the versioned task structure may employ a bounded state machine, a workflow graph with compensating edges, or a Petri net capable of expressing node dependencies and versions, but it still needs to be able to determine changing nodes, downstream nodes, resource conflicts, and credential derivation relationships.

[0068] like Figure 2 and Figure 3 As shown, step S103 is executed collaboratively by the permission envelope calculation module 400 and the temporary credential issuance module 600. The permission envelope calculation module 400 forms the first version of the permission envelope based on the permission requirement set, operator permission limit set, service allowed set, and current context constraint set of the first version of the task dependency graph.

[0069] Its set relation can be expressed as:

[0070]

[0071] in, The task graph version number represents a monotonically increasing sequence number and is a positive integer. Indicates the first Versioned task dependency graph; Indicates the relationship with the first The permission envelope corresponding to the versioned task dependency graph; Indicates will The set of permission requirements is obtained by taking the union of the atomic sets of capabilities required for currently valid and reachable nodes. This represents the set of maximum operator permissions. This indicates the set of capabilities allowed by the current service interface version and the controlled policy enforcement point; This represents the set of context constraints formed by resource version, node state, operator explicit restrictions, and service state. All of these sets consist of capability atoms and do not have physical units. Intersection operations can be implemented using set indexing, policy rule matching, or bitmap intersection. If the resource selector cannot be resolved, the service adapter capability description version is inconsistent, or the node execution preconditions are not met, the corresponding capability atom will not be included in the current issueable subset.

[0072] Figure 3 The permission envelope calculation module 400 and the temporary credential issuance module 600 form a small permission envelope box that is an output data object, not a module with the same name. Capability atoms are normalized in a fixed order of service, operation, resource, field, side effect, number of calls, and preconditions; non-normalized capability atoms remain unsignable.

[0073] like Figure 5 As shown, the temporary credential issuance module 600 can be implemented as a signature credential generation process, or as a credential registration process that generates an unreadable reference identifier and stores the complete constraints in the permission status and evidence storage module 800. This module receives the current task graph version, node identifier, capability atom, resource audience, parameter digest, maximum number of calls, and execution precondition digest, generates a temporary capability credential, and registers its status. When the first version of the task dependency graph is first enabled, the execution preconditions for the retrieval node are already met; therefore, a knowledge retrieval temporary capability credential is issued only for that node. The lease period for the read-type temporary capability credential is denoted as... For example, it can be configured to be from 30 seconds to 300 seconds, with the specific value determined based on the service response time and the number of pagination iterations; the maximum number of calls is denoted as... External sending or publishing capabilities For example, it is set to 1 time. The lease period is only used to limit the long-term persistence of credentials and cannot replace task graph version, permission transition barrier and credential status verification, nor can it replace revocation.

[0074] like Figure 5 As shown, the temporary credential issuance module 600 reads the current task graph version, permission transition barrier, and node status from the permission status and evidence storage module 800, and registers the temporary capability credential and constraints with the call execution gateway and service adapter 700; the registration result is written to the permission status and evidence storage module 800 and a confirmation is returned. Optionally, the temporary credential issuance module 600 can register directly, but all registrations are based on the same serialized status record.

[0075] like Figure 2 and Figure 5As shown, step S104 is executed by the call execution gateway and service adapter 700. After the current task node execution process makes a request, this module reconstructs the call normalization tuple based on the interface pattern saved by the service capability registration module 300, and sequentially verifies the temporary capability credential status, task graph version, permission transition barrier, node status, capability atom, resource selector, field mask, parameter digest, execution pre-digest, maximum number of calls, and call sequence number. When the service does not provide a native call sequence number, a local monotonic sequence number space is established based on the task identifier, service identifier, and temporary capability credential identifier; rejected or pending requests are not included in the last accepted call sequence number. If all conditions are met, the target service is invoked; otherwise, it is rejected or waited for, and the reason and call digest are written.

[0076] Figure 2 The statement "Continue to execute the task" indicates that when the task graph version remains unchanged, each call will still execute step S104; "Continue to execute according to the new version" indicates that after step S106 is completed, subsequent calls will re-enter step S104 according to the new task graph version. Figure 5 Taking knowledge resource service 31 as an example, document service 32, email service 33 and collaborative publishing service 34 use the same call boundary verification order.

[0077] like Figure 5 As shown, after the knowledge service 31 completes the retrieval, it calls the execution gateway and service adapter 700 to return a set of document identifiers and a source summary. The permission status and evidence storage module 800 records the last accepted call number and result summary for this service, and the feedback and anomaly monitoring module 900 updates the retrieval node to a completed state and activates the reading node accordingly. The reading node can only read the set of document identifiers returned by the retrieval node; the generation node only accepts the output summary of the reading node as its data source; the document writing node writes the generated result to the specified path, and the document service 32 returns the resource version and file summary; the verification node reads back the same resource version and outputs the format and sensitive item verification results. Only when the verification result is passed will the temporary credential issuance module 600 activate the sixth capability atom of the email sending node. The temporary capability credential is bound to the target recipient's summary identifier. The system includes information such as attachment summary, task graph version, permission transition barrier summary, and call count. Therefore, if the received object or attachment is replaced, it will be rejected due to inconsistencies in the resource or parameter summary.

[0078] like Figure 2 and Figure 6 As shown, step S105 is executed by the feedback and anomaly monitoring module 900 and the versioned task graph compilation module 200. Assuming the verification node has been completed but the email sending node has not yet been executed, the operator modifies the task via terminal device 10 to not send emails, instead publishing it to the target collaborative workspace identifier. The report channel. The task input and normalization module 100 first normalizes the new delivery path. The feedback and anomaly monitoring module 900 detects changes in the target action and target service and sends a replanning event to the versioned task graph compilation module 200. The versioned task graph compilation module 200 generates a second versioned task dependency graph, replacing the email sending node with a collaborative release node, but not overwriting the first versioned task dependency graph. The permission envelope calculation module 400 forms the second version of the permission envelope based on this. The difference between the old and new permission envelopes is:

[0079]

[0080]

[0081]

[0082] in, This is the old version's permission envelope. This is the new permission envelope; This represents the set of removal permissions that must be isolated. This refers to the set of additional permissions that can only be activated after a permission transition barrier has been formed. This represents the set of common permissions shared by both the old and new versions. In this example, Includes email sending capability. Includes collaborative publishing capabilities. It includes retrieval, reading, generation, writing, and readback verification capabilities. This differential allows the permission reconfiguration control module 500 to limit the switching scope to the relevant capabilities without globally revoking all read-only capabilities.

[0083] like Figure 4 and Figure 6 As shown, the permission reconfiguration control module 500 further determines the affected causal closure. When the set of changed nodes is taken as input, its computational relationship can be expressed as:

[0084]

[0085] in, Indicates the causal closure affected by the causal relationship; This represents the set of changed nodes that have been deleted, added, replaced, or whose input has become invalid. and They represent from Departure, at and The downstream node closure is obtained from the data dependency, control dependency, authorization dependency, and change-related compensation dependency. Indicates and A set of conflicting nodes that access the same resource and at least one of them has write behavior; Indicates and A set of nodes that share upstream service credentials, execute pre-summaries, or derived authorization chains. These sets are all node-based and do not include physical units; they can be obtained using adjacency list traversal, incremental graph indexing, or pre-computed reverse indexing. External side-effect nodes whose conflict status cannot be confirmed are treated as having a conflict.

[0086] like Figure 6 As shown, step S106 is executed collaboratively by the permission reconfiguration control module 500, the temporary credential issuance module 600, and the call execution gateway and service adapter 700. The permission reconfiguration control module 500 first puts the email sending and collaborative publishing nodes in the affected causal closure into a silent state, and the call execution gateway and service adapter 700 rejects or waits for new external side-effect calls; then, it issues a revocation control for the removed permission set. When email service 33 supports native revocation, the service adapter submits a revocation request and collects confirmation; when only short-term credentials are supported, the status of the old temporary capability credential is changed to stop receiving and isolated according to the current task graph version; when only long-term service keys can be used, the key is stored in the call execution gateway and service adapter 700 and platform-referenced credentials are rejected locally. All three methods require recording the last accepted call sequence number.

[0087] Figure 6 The revocation control is forwarded via the call execution gateway and service adapter 700, and there is no bypass connection that bypasses the controlled call boundary.

[0088] like Figure 6 As shown, the upper limit for the withdrawal waiting period is denoted as The timeout period can be configured from 1 to 10 seconds, exemplarily depending on the service category. This embodiment uses 5 seconds as an illustrative configuration. The value is determined by the tolerance window required for the service's native revocation response, network propagation, and in-transit call termination, and does not represent a fixed optimal value. When each necessary service component in the revocation confirmation vector indicates that the removal permission has been revoked or deterministically isolated by a controlled execution point, the last accepted call sequence number has been fixed, there are no in-transit calls conflicting with the new permission or they have reached their final state, and there is no unexplained drift in the resource version and service adapter capability description version, the permission reconfiguration control module 500 transitions the state from the revocation state to the barrier ready state. The final state of an in-transit call includes at least successful, failed, canceled, and determined not to be accepted by the service; states that cannot be determined remain unknown. A permission transition barrier is then generated:

[0089]

[0090] in, This represents a summary of the permission transition barrier. This indicates a collision-resistant digest operation, which can be implemented using deterministic digest operation or keyed integrity operation; Indicates the task identifier; and These represent the old mission map version and the new mission map version, respectively. This represents the summary obtained after the affected causal closures are sorted by node identifiers and the fields are normalized. This represents the summary obtained after normalizing the withdrawal confirmation vector according to a fixed service order; Indicates the permission status and the monotonic submission sequence number assigned by the evidence storage module 800; The fields are concatenated in a predetermined order. Fields participating in the summary are first encoded into byte sequences according to a predefined data type and length. Set elements are sorted by identifier to avoid different permission transition barriers arising from different field orders for the same facts. The permission status and evidence storage module 800 updates the current task graph version, current permission transition barriers, and switching status simultaneously through atomic comparisons and exchanges, or transactions with equivalent serialization effects.

[0091] like Figure 5 and Figure 6 As shown, after the permission transition barrier is generated and the task graph version switch is successfully submitted, the temporary credential issuance module 600 generates a temporary capability credential for the 7th capability atom for the collaborative release node. This temporary capability credential is bound to the 2nd versioned task dependency graph and the permission transition barrier. Target Collaborative Workspace Identification The system retrieves the report channel, verified document summary, current resource version, and call count. When the call execution gateway and service adapter 700 receive a publish request, it rereads the current task graph version and current permission transition barrier. Only if the task graph version, permission transition barrier, node status, resource selector, execution pre-summary, and call sequence number in the temporary capability credential match the trusted status will the call be issued to the collaborative publishing service 34. Any mail sending request carrying the first task graph version or an older permission transition barrier, even if the access token has not expired naturally, is rejected.

[0092] Figure 6 The terms "Isolate old permissions," "Submit barrier," and "Activate new permissions" in the text refer to isolating old version permissions, submitting permission transition barriers, and activating new permissions, respectively, and do not constitute manual approval. Old email requests are still rejected by the call execution gateway and service adapter 700 based on the old task graph version or the old version permission transition barrier.

[0093] like Figure 7 As shown, when the descriptive withdrawal wait limit is reached. When the deadline expires and the status of the in-transit call of email service 33 is still unknown, the permission reconfiguration control module 500 will not activate the collaborative publishing permission and will enter a downgraded state.

[0094] The security intersection permission set can be represented as:

[0095]

[0096] in, Represents the set of security intersection permissions; A set of public permissions that represents the envelope of old and new permissions; It represents the set of capabilities within the affected causal closure that can cause changes in the externally observable state.

[0097] In this example, retrieved, read, and completed document results can be retained, but email sending and collaborative publishing are frozen. When public capability names are the same but resource versions, parameter summaries, execution pre-summaries, or resource audiences differ between the two versions, the results will also be affected. Excluded. Once the mail service 33 returns to the final state, or the execution gateway and service adapter 700 proves that the old request was not accepted, the permission reconfiguration control module 500 recalculates the revocation confirmation vector and continues to generate permission transition barriers.

[0098] like Figure 6 As shown, irreversible send, publish, delete, or code merge capabilities can be divided into a preparation phase and a commit phase. The preparation phase only generates a normalized request, preview, and digest, and does not hold external write permissions. The commit phase only issues temporary capability credentials after the request digest, resource version, execution pre-digest, and current permission transition barrier all match. If the acknowledgment is lost after commit, the capability remains in transit and the service's final state is queried; not receiving an acknowledgment should not be equated with not executing.

[0099] like Figure 1 , Figure 6 and Figure 10 As shown above, the permission status and evidence storage module 800 employs a versioned status table and append-only event logging. Task compilation, permission envelope generation, temporary capability credential issuance, call reception, service receipt, permission revocation confirmation, permission transition barrier generation, and task graph version switching all form evidence objects, recording the event type, task, node, task graph version, previous event summary, current event summary, processing summary, result, and monotonic sequence number. The current event summary overwrites the previous event summary to form a verifiable chain. External side-effect calls are frozen when evidence writing fails; execution fails and shutdown occurs when the current task graph version or permission transition barrier cannot be reliably read.

[0100] like Figure 1 , Figure 6 and Figure 9As shown on the left, in the first parallel embodiment, the permission configuration server 20 adopts a centralized permission switching architecture. The permission reconfiguration control module 500, the temporary credential issuance module 600, and the permission status and evidence storage module 800 are located in the same controlled computing domain. The permission status and evidence storage module 800 submits the current task graph version, the revocation confirmation vector digest, and the permission transition barrier in the same transaction. Each service adapter returns the revocation status, the last accepted call sequence number, the in-transit call status, the resource version, and the service adapter capability description version. The switching order is determined by a single commit sequence number, and multiple service clocks are not required to be synchronized.

[0101] like Figure 6 , Figure 7 and Figure 9 As shown on the right, in the second parallel embodiment, multiple policy execution points store local policy version numbers and stop accepting new external side-effect calls to older versions after receiving a freeze command. Each policy execution point returns its local policy version number, last accepted call number, revocation status, resource version, and in-transit call status. The necessary confirmation set must cover all active policy execution points and their valid copies that can accept any capability in the removal permission set or capabilities that conflict with the addition permission set; simple majority confirmation cannot be substituted. The new temporary capability credential is also bound to the new local policy version number, which is rejected by the old version policy execution point.

[0102] Figure 9 External services A through C summarize the registered services, with no limit on the number of services; policy execution points A through C represent different policy execution points or service replicas, without numerical appendix markers. Each policy execution point returns the local policy version number, the last accepted call number, and the revocation status; if the necessary confirmation set formed by this is incomplete, the newly added permission will not take effect.

[0103] like Figure 3 and Figure 4 As shown, in the third parallel embodiment, the service capability description can be formed into candidate capability atoms through interface pattern parsing, controlled call log summarization, or static code analysis. The service capability registration module 300 extracts the operation name, resource fields, parameter types, call points, and parameter sources, and then uses deterministic rules to label side effect categories, resource boundaries, and revocation methods, and establishes a credential genealogy index. When the meaning of a field, resource selector, or side effect category cannot be verified, the candidate capability atom remains prohibited or is limited by a narrower template. This embodiment changes the source of the capability description but does not change the comparability of capability atoms, the immutability of the task graph version, or the relationship between the new temporary capability credential binding permission transition barrier.

[0104] like Figure 4As shown, the versioned task dependency graph can also be represented by a bounded (finite) state machine: each state represents a completed node and an ability that can be activated, while the transition conditions between states represent the execution pre-summary, resource version, or service receipt; when a task changes, a new state machine version is obtained, and the affected causal closure consists of the successor states affected by the changes in the old state machine and the new state machine, the shared resource write set, and the shared credential genealogy state, so it is still possible to determine the removal, addition, public permissions, and security intersection permission set.

[0105] like Figure 1 and Figure 5 As shown, the invocation policy execution point can be a unified invocation gateway, a service mesh policy execution process, or a service-native policy execution point: the unified invocation gateway stores long-term service credentials; the service mesh policy execution process performs verification based on the task graph version, permission transition barriers, and invocation sequence number; the service-native policy execution point accepts authorization fields encoded by capability atomic constraints and returns a revocation confirmation. These three forms can be used in combination, but every external side-effect invocation path must be included in the unified verification domain.

[0106] like Figure 2 , Figure 6 and Figure 7 As shown, when a task is directly cancelled, the added permission set is empty. The permission reconfiguration control module freezes affected external side effect calls, revokes the removal of permissions, and liquidates in-transit calls; after the revocation confirmation vector meets the conditions, it submits the task cancellation status and terminates the permission transition barrier, and no longer issues new temporary capability credentials.

[0107] like Figures 4 to 6 As shown, when the read-only retrieval service is replaced and the two services do not share write resources or external side effect credentials, the affected causal closure only includes the replaced node and the downstream nodes that depend on its results, and does not freeze irrelevant read-only branches; after the old read-only temporary capability credentials are isolated and a permission transition barrier is formed, the new read-only temporary capability credentials are activated.

[0108] like Figure 1 , Figure 5 and Figure 10 As shown, in a parallel embodiment where the same operator executes multiple tasks in parallel, the first... The task identifier for each task is denoted as Each temporary capability credential, task graph version, permission transition barrier, execution pre-execution summary, and invocation sequence number space is associated with a corresponding... Binding. When the Execution Gateway and Service Adapter 700 detects that the task identifier, task node, or permission transition barrier in the temporary capability credentials is inconsistent with the task to which the current call belongs, the call is rejected, thereby preventing the use of credentials between different tasks due to the same resource path or similar parameters.

[0109] like Figure 7 As shown, the permission switching state machine includes stable, ready, silent, revocation, barrier ready, active, new version stable, downgrade, and rollback states. Upon detecting a change in the versioned task dependency graph, it enters the ready state and calculates the new versioned task dependency graph, permission switching differential, and affected causal closures; after the graph structure is valid, it enters the silent state; after freeze confirmation, it enters the revocation state; after the revocation confirmation vector meets the conditions, it enters the barrier ready state; after the task graph version and permission transition barrier are atomically committed, it enters the active state; after the newly added temporary capability credential is registered and confirmed, it enters the new version stable state. If the necessary conditions are not met, it enters the downgrade or rollback state.

[0110] Figure 7 In the context of service adapter capability descriptions, version drift or local policy version sequence number drift triggers re-entry into the preparation state; old version asynchronous callbacks are rejected and written to orphaned evidence, without causing a jump in the main state chain; when the permission state and evidence storage module encounters an 800 error or cannot determine the unique task graph version, it enters a rollback or replans the path. None of the above anomalies can directly advance to the stable state of the new version.

[0111] like Figure 6 and Figure 7 As shown, when communication is interrupted and the upper limit for revocation waiting has been reached, the feedback and anomaly monitoring module 900 will mark the corresponding service component as missing, and the permission reconfiguration control module 500 will keep the affected external side-effect nodes frozen, only opening the security intersection permission set. If the disconnected service cannot be isolated by the local controlled execution point, its shared resource or credential hierarchy capabilities will also be excluded. After communication is restored, it is necessary to return and verify the local policy version number, the last accepted call number, the in-transit call final state, and the resource version and service adapter capability description version before re-entering the revocation state.

[0112] like Figure 5 and Figure 7As shown, when a service receipt is lost, the call execution gateway and service adapter 700 will keep the call in transit and query the final state using the call sequence number, idempotency flag, and resource version; newly added conflicting permissions will remain frozen. The service receipt waiting window is jointly determined by the normal response limit of the target service, network propagation time, and retry strategy. Expiration of the window only triggers a final state query and does not directly presume call failure. When execution is confirmed, external side effects are recorded and the system enters a compensation or verification state. When execution is confirmed not to have occurred, this fact is written into the withdrawal confirmation vector. If the final state cannot be proven, the system remains downgraded, and the absence of a receipt is not presumed to mean the absence of external side effects.

[0113] like Figure 5 and Figure 10 As shown in the lower section, when an old version asynchronous callback carries an old task graph version, an old version permission transition barrier, or an old node identifier, the call execution gateway and service adapter 700 prevents it from changing the state of the new version node, and writes the old version asynchronous callback as isolated evidence into the permission state and evidence storage module 800. When an old external side effect has occurred, the feedback and anomaly monitoring module 900 triggers resource version verification or compensation, and does not treat the old version asynchronous callback as a precursor completion result of the new version node.

[0114] Figure 10 The prohibition on modifying the status of the new version node indicates that the call to the execution gateway and service adapter 700 isolates the asynchronous callback of the old version; the isolation of evidence records written to the permission status and evidence storage module 800 is only used for feedback, anomaly monitoring module 900 to check resource version or trigger compensation, and is not a prerequisite for the execution of the new version node.

[0115] like Figure 5 and Figure 7 As shown, when repeatedly starting up or replaying, the permission status and evidence storage module 800 verifies the task identifier, node identifier, temporary capability credential identifier, and call sequence number. Requests with existing final results return a recorded summary without being executed again; requests that have exhausted their usage count or have discontinuous sequence numbers are rejected. Repeated rescheduling requests identify the same switching transaction based on the old and new versions and the commit sequence number, returning the existing permission transition barrier or downgraded status.

[0116] like Figure 1 and Figure 7As shown, when the permission status and evidence storage module 800 is unavailable or the electronic device 1000 initializes abnormally, the call execution gateway and service adapter 700 cannot confirm the current task graph version, permission transition barrier, or temporary capability credential status, thus causing the execution of external side-effect calls to fail and close. Read-only calls continue only if a verifiable read-only state snapshot exists, and the task graph version, resource version, and resource selector in the snapshot are still consistent with the current verifiable state. After recovery, the last commit sequence number, permission transition barrier summary, and local policy version sequence number of each service are checked first, then the old version is restored, privilege eviction continues, or the versioned task dependency graph is recompiled.

[0117] like Figure 3 and Figure 7 As shown, when a service adapter capability description version drifts, temporary capability credentials referencing the old service adapter capability description version become invalid, and the affected nodes and permission switching differentials are recompiled. If the resource selector, field mask, side effect category, or revocation method of the new capability atom is not determined, it will not be included in the permission envelope. When the call parameters exceed the resource selector, field mask, parameter constraints, or maximum call count, the call execution gateway and service adapter will refuse the call with a 700 error and record the out-of-bounds field, without automatically expanding the permission boundaries.

[0118] like Figure 8 As shown, this embodiment also provides a device for dynamically configuring AI service permissions for one-person companies. This device is a virtual device formed by a computer program, with modules 100 to 900 corresponding to one or more processing actions in steps S101 to S106, respectively. Each module can be encapsulated as an independent process, service instance, function library, or different code segments within the same program. Module division represents data input, state boundaries, and calling relationships, and does not require a fixed physical form.

[0119] like Figure 8 As shown, the task input and normalization module 100 outputs normalized constraints; the versioned task graph compilation module 200 generates an immutable task graph version; the service capability registration module 300 forms capability atoms; the permission envelope calculation module 400 forms permission envelopes and permission switching differences; the permission reconfiguration control module 500 forms affected causal closures, revocation confirmation vectors, and permission transition barriers; the temporary credential issuance module 600 generates temporary capability credentials; the call execution gateway and service adapter 700 reconstructs and verifies the call normalized tuples; the permission status and evidence storage module 800 saves the serialized status and permission evidence chain; and the feedback and anomaly monitoring module 900 triggers status updates based on service receipts, timeouts, old version asynchronous callbacks, and service adapter capability description version drift. If the permission reconfiguration control module 500 or the permission status and evidence storage module 800 is unavailable, activation of newly added external side-effect permissions is stopped.

[0120] like Figure 8 As shown, the electronic device 1000 can be a server, workstation, virtualized computing node, or a computing system composed of multiple computing nodes. Internally, it includes a processor 1010, a memory 1020, a communication bus 1030, and a network interface 1040. The processor 1010 reads program instructions and status data via the communication bus 1030 and communicates with the terminal device 10, knowledge resource service 31, document service 32, email service 33, and collaborative publishing service 34 via the network interface 1040. It performs tasks such as task normalization, capability atom formation, versioned task dependency graph compilation, permission envelope calculation, call verification, replanning detection, affected causal closure calculation, permission revocation confirmation aggregation, permission transition barrier generation, new permission activation, and security intersection permission set downgrading. The memory 1020 stores the current task graph version, permission transition barriers, credential usage count, last accepted call sequence number, and permission evidence chain.

[0121] Figure 8 The dashed box in the diagram represents the logical module mapping formed when the processor 1010 executes the computer program. Modules 100 to 900 do not represent nine independent physical chips. The bidirectional arrows between the network interface 1040 and the terminal device 10, as well as the knowledge service 31, document service 32, email service 33, and collaborative publishing service 34, represent communication sending and receiving. Permission determination, task graph version comparison, and permission transition barrier verification are all completed by the processor 1010 executing the computer program.

[0122] like Figure 8 As shown, when electronic device 1000 consists of multiple computing nodes, processor 1010 represents a set of processors, and memory 1020 represents distributed storage using a consistent state protocol. The generation of permission transition barriers and the update of the current task graph version must still have a single, determinable commit order; if network partitioning results in the lack of necessary revocation confirmation, a secure intersection permission set is executed or the process fails to close.

[0123] like Figure 8 As shown, the computer-readable storage medium 1050 can be flash memory, read-only memory, erasable and rewritable memory, solid-state storage medium, magnetic storage medium, or runtime storage area. When the stored computer program is executed by the processor 1010, steps S101 to S106 and exception state transitions are implemented; when the program is loaded via the network interface 1040, the program version and the service adapter capability description version are verified before and after loading.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for dynamically configuring AI service permissions for one-person companies, characterized in that: Permission configuration server execution: Heterogeneous service interfaces are converted into capability atoms, and permission envelopes are formed based on versioned task dependency graphs. During task replanning, new task graph versions and permission envelopes are generated. The new and old permission envelopes are compared to obtain the set of removed permissions, the set of added permissions, and the set of common permissions. The affected causal closures are determined according to the downstream dependencies of changed nodes, resource read and write conflicts, and credential genealogy. Freeze subsequent external side effect calls within the closure, revoke the removal permission set, liquidate in-transit calls, and aggregate the revocation confirmation vector; When the vector confirms the removal of permission isolation and the conflicting in-transit call has been terminated, a permission transition barrier is generated, the task graph version and the barrier are atomically submitted, and the corresponding added permission set is activated and the temporary capability credentials of the version and the barrier are bound. Otherwise, executable permissions are limited to the safe intersection set of permissions obtained by subtracting the side effect capabilities of the closure from the public permission set. If the permission set is uncertain, execution will fail and the process will be closed.

2. The method for dynamically configuring AI service permissions for one-person companies according to claim 1, characterized in that: The affected causal closure starts from a node that has undergone at least one of deletion, addition, replacement, and input failure, and obtains downstream nodes along the data dependencies, control dependencies, authorization dependencies, and compensation dependencies related to the change in the old and new task graph versions. It also merges conflicting nodes that access the same resource as the changed node and at least one of them has write behavior, as well as nodes that share at least one of upstream service credentials, execution pre-summary, and derived authorization chain. If the conflict status can be determined, it should be handled according to the determined result; otherwise, it should be handled as if a conflict exists.

3. The method for dynamically configuring AI service permissions for one-person companies according to claim 2, characterized in that: The revocation confirmation vector is aggregated in a fixed order of service identifier and policy execution point identifier. Each service component includes the revocation processing result, the last accepted call sequence number, the in-transit call status, the service resource version, and the service adapter capability description version. When the target service provides a native invocation sequence number, this sequence number is used. If it is not provided, the invocation execution gateway and service adapter of the permission configuration server establish a monotonic sequence number space based on the task identifier, service identifier, and temporary capability credential identifier, and increment it only when the invocation is accepted by the controlled execution point.

4. The method for dynamically configuring AI service permissions for one-person companies according to claim 3, characterized in that: The permission configuration server has a permission status and evidence storage module; the permission transition barrier is generated by encoding the task identifier, the old and new task graph versions, the affected causal closure summary, the revocation confirmation vector summary, and the monotonic commit sequence number in a predetermined order. This module employs either an atomic compare-and-swap mechanism or a transaction with serializable commit effects, simultaneously committing a new task graph version, a permission transition barrier, and a state switch. Upon successful commit, it activates temporary capability credentials that add to the permission set, and upon failed commit, it keeps external side-effect calls within the affected causal closure frozen.

5. The method for dynamically configuring AI service permissions for one-person companies according to claim 1, characterized in that: The permission configuration server includes a call execution gateway and a service adapter. The call execution gateway and service adapter perform permission revocation according to the service revocation capability: if native revocation is supported, a revocation request is submitted and a revocation receipt is collected. For applications that only support short-term credentials, change the status of old temporary capability credentials to "stop receiving" and isolate old calls according to the current task graph version; for applications that only use long-term service keys, store the long-term service key in the call execution gateway and service adapter, and reject old platform reference credentials; for applications with unclear revocation capabilities, keep the corresponding external side effect capabilities unsignable.

6. The method for dynamically configuring AI service permissions for one-person companies according to claim 5, characterized in that: The capabilities of sending, publishing, deleting, and merging code are divided into a preparation phase and a commit phase; the preparation phase only generates normalized requests and digests, and does not grant external write permissions. During the submission phase, temporary capability credentials are activated if the request digest, resource version, execution pre-digest, and permission transition barrier all match; otherwise, they remain non-executable. If no receipt is received within the receipt waiting window after submission, the system remains in transit and queries the final state by call sequence number, idempotency flag, and resource version. If the final state is provable, the revocation confirmation vector is updated; otherwise, the set of added permissions is kept frozen.

7. The method for dynamically configuring AI service permissions for one-person companies according to claim 1, characterized in that: The permission configuration server uses at least one of the following as the controlled execution point: unified call gateway, service mesh policy execution process, and service native policy execution point; After each controlled execution point is frozen, it rejects calls to the old task graph version and returns the local policy version number, the last accepted call number, and the revocation status. Based on this, the permission configuration server forms the necessary confirmation set, covering the controlled execution points and valid copies that can still accept the removal of capabilities from the permission set or capabilities that conflict with the addition of permissions. When the set is complete, a permission transition barrier is generated; when the set is incomplete, the addition of permissions is not activated.

8. The method for dynamically configuring AI service permissions for one-person companies according to claim 7, characterized in that: Temporary capability credentials record task identifier, node identifier, task graph version, capability atom, resource audience, parameter summary, maximum number of calls, execution pre-suppression summary, and permission transition barrier summary; The permission configuration server's call execution gateway and service adapter reconstruct the call normalization tuple based on the service capability description. The call normalization tuple records the service identifier, operation identifier, resource, parameter summary, data source summary, task node, task graph version, and call sequence number, and compares the corresponding fields of the call normalization tuple with the temporary capability credentials item by item.

9. The method for dynamically configuring AI service permissions for one-person companies according to claim 8, characterized in that: The permission configuration server also includes a permission status and evidence storage module. The permission status and evidence storage module appends and records versioned task dependency graph compilation, permission envelope formation, temporary capability credential issuance, call reception, service receipt, permission revocation confirmation, permission transition barrier generation, and task graph version switching events in the order of event occurrence. Each event record includes event type, task identifier, node identifier, task graph version, previous event summary, current event summary, processing summary, processing result, and monotonic sequence number. The current event summary covers the previous event summary.

10. The method for dynamically configuring AI service permissions for a one-person company according to claim 9, characterized in that: Call the execution gateway and service adapter to respond to asynchronous callbacks carrying at least one of the old task graph version, old permission transition barrier and old node identifier, prohibit them from modifying the new version node status, and write the callback content, the reason for rejection and the existing task graph version, permission transition barrier and node identifier fields into the permission status and evidence storage module to form an isolated evidence record; The permission configuration server's feedback and anomaly monitoring module triggers resource version verification or compensation based on this record, and this record is not a prerequisite for the execution of a new version node.

11. A device for dynamically configuring AI service permissions for one-person companies, characterized in that: include: The module includes a service capability registration module for mutual communication, a versioned task graph compilation module, a permission envelope calculation module, a permission reconfiguration control module, a temporary credential issuance module, a call execution gateway and service adapter, and a permission status and evidence storage module. The service capability registration module converts heterogeneous service interfaces into capability atoms, the versioned task graph compilation module generates an immutable versioned task dependency graph based on task input and capability atoms, and the permission envelope calculation module forms a permission envelope based on the versioned task dependency graph. When the versioned task graph compilation module receives a task replanning event, it generates a new task graph version. The permission envelope calculation module forms a corresponding new permission envelope. The permission reconfiguration control module compares the old and new permission envelopes to obtain the set of removed permissions, the set of added permissions, and the set of common permissions. It then determines the affected causal closure based on the downstream dependencies of the changed nodes, resource read / write conflicts, and credential hierarchy. The permission reconfiguration control module controls the call execution gateway and service adapter to freeze external side effect calls within the affected causal closure, revoke and remove permissions from the permission set, liquidate in-transit calls, and aggregate the revocation confirmation vector. When the revocation confirmation vector meets the switching conditions, the permission status and evidence storage module atomically submits the new task graph version, permission transition barrier, and switching status. The temporary credential issuance module activates the corresponding temporary capability credential that adds a permission set and binds the new task graph version and permission transition barrier. The execution gateway and service adapter are then called to verify the call based on the new task graph version, permission transition barrier, and temporary capability credential. When the revocation confirmation vector does not meet the switching conditions, the permission reconfiguration control module restricts the executable permissions to the safe intersection permission set obtained by subtracting the affected causal closure's internal and external side effect capabilities from the public permission set. If the safe intersection permission set is uncertain, the module will close the execution if it fails.

12. An electronic device comprising a processor, a memory, a communication bus, and a network interface, wherein the processor, the memory, and the network interface are connected via the communication bus, and the memory stores a computer program, characterized in that... When the computer program is executed by the processor, the electronic device receives task input, sends controlled calls and receives service receipts through the network interface, and implements the dynamic configuration method for artificial intelligence service permissions for one-person companies as described in claim 1.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it enables the electronic device to implement the method for dynamically configuring artificial intelligence service permissions for a one-person company as described in claim 1.

Images