Agent interaction-oriented data ontology relationship progressive disclosure method and system

Abstract

The application discloses an agent interaction-oriented data ontology relationship progressive disclosure method and system, and the method comprises the following steps: obtaining an ontology relationship query request initiated by an agent; determining an ontology relationship disclosure authorization level based on a user identity, an agent role, a query intention and a historical inquiry path; generating a candidate ontology relationship path according to a target entity in a data ontology graph; performing reservation, hiding, desensitization or aggregation processing on entities, relationships and attributes in the candidate path based on the authorization level, a relationship sensitive label, an attribute sensitive label and a path hop limit to obtain a disclosable ontology segment; outputting entity, relationship, attribute and source information of different granularities in a layered manner according to a progressive disclosure state machine; reviewing the risk of unauthorized disclosure, sensitive combination, path accumulation and reasoning leakage of the to-be-output segment; and outputting the segment to the agent and generating an audit record after the review. According to the application, the risk of unauthorized disclosure and reasoning leakage of the agent when calling enterprise data ontology can be reduced.

Description

Technical Field

[0001] This application relates to the fields of intelligent agent interaction and data security technology, and more specifically, to a method and system for progressive disclosure of data ontology relationships for intelligent agent interaction. Background Technology

[0002] As enterprise AI systems evolve into intelligent agents capable of performing tasks, internal data access is shifting from traditional queries to agents autonomously retrieving, analyzing, and combining multi-source data based on user intent. In an enterprise data operating system (such as DataOS), unified semantic modeling is required for business objects such as customers, contracts, projects, work orders, personnel, knowledge, equipment, processes, and permissions to form a data ontology. This data ontology not only carries individual objects but also the semantic relationships between them, such as the contractual relationship between a customer and a contract, the handling relationship between a project and a work order, and the responsibility relationship between personnel and projects. When answering user queries, intelligent agents often need to traverse these relationship paths to generate a complete answer.

[0003] However, ontology relationship information is often more sensitive than a single field. Relationship paths can reveal customer tiers, contract amounts, personnel responsibilities, risk causes, supplier dependencies, organizational collaboration boundaries, and even internal business strategies. In multi-turn interactions between agents, users may gradually approach highly sensitive relationships through continuous questioning, and multiple low-sensitivity fragments, combined in context, may also infer highly sensitive information. Therefore, disclosing data ontology relationships to agents must have a hierarchical, layered, phased, and traceable control mechanism.

[0004] Existing enterprise data access controls primarily rely on role-based access control, attribute-based access control, interface authentication, database row and column permissions, or graph database access control. These methods, using static roles or fields as control objects, struggle to provide fine-grained control over ontology relationship paths. Current systems often return a large number of ontology relationships at once, lacking a progressive disclosure mechanism; they also fail to adequately consider the cumulative risks of multi-round query paths and lack verification of leaks from combinatorial reasoning. Audit logs are mostly limited to login, query, and download behaviors, failing to meet the security audit and compliance traceability requirements of the ontology relationship disclosure process.

[0005] Therefore, designing a progressive disclosure method for data ontology relationships oriented towards intelligent agent interaction to address the risks of unauthorized disclosure and reasoning leakage when intelligent agents call enterprise data ontology in existing technologies is an urgent technical problem to be solved. Summary of the Invention

[0006] The purpose of this application is to provide a progressive disclosure method and system for data ontology relationships in intelligent agent interaction, so as to solve the problems of unauthorized disclosure and reasoning leakage risks that exist when intelligent agents call enterprise data ontology in the prior art.

[0007] In a first aspect, embodiments of this application provide a progressive disclosure method for data ontology relationships in intelligent agent interaction, wherein a processor performs the following steps: Obtain an ontology relationship query request initiated by an intelligent agent, wherein the query request carries at least user identity information, intelligent agent role information, target entity information, query intent information, context task information, and historical query path information; Based on the user identity information, agent role information, query intent information, context task information, and historical query path information, determine the corresponding ontology relationship disclosure authorization level; Based on the target entity information, candidate ontology relationship paths are generated in a preset data ontology graph. The candidate ontology relationship paths include entity nodes, relationship edges, attribute fields, path hop count, relationship direction, and data source information. Based on the disclosure authorization level, preset relationship sensitive tags, preset attribute sensitive tags, and preset path hop limit, disclosable ontology fragments are selected from the candidate ontology relationship paths; wherein, the disclosable ontology fragments are fragments obtained by removing relationship edges that hit the relationship sensitive tags, removing attribute fields that hit the attribute sensitive tags, and trimming relationship paths that exceed the path hop limit from the candidate ontology relationship paths. The current processing state is determined, and the processing operation corresponding to the state is performed on the disclosable ontology fragment to generate the ontology fragment to be output. The processing operation includes at least layered output of the disclosable ontology fragment, with different layers corresponding to entity information, relationship information, attribute information and source information of different granularities. The ontology fragment to be output is subject to risk review, at least detecting risks of unauthorized disclosure, disclosure of sensitive relationship combinations, path accumulation, and leakage of reasoning. If the review passes, the ontology fragment is output to the intelligent agent, and a corresponding disclosure audit record is generated; if the review fails, downgraded disclosure, rejection of disclosure, or upgrade authorization is performed.

[0008] Preferably, the ontology relationship disclosure authorization level includes six levels from L0 to L5, where L0 corresponds to existence indication, L1 corresponds to entity type disclosure, L2 corresponds to relationship type disclosure, L3 corresponds to anonymization path disclosure, L4 corresponds to partial entity and non-sensitive attribute disclosure, and L5 corresponds to complete relationship and data lineage disclosure.

[0009] Preferably, the relationship-sensitive tags include at least one of personnel responsibility relationship tags, contract amount relationship tags, customer classification relationship tags, risk cause relationship tags, supplier cost relationship tags, and internal assessment relationship tags; the attribute-sensitive tags include at least one of amount, identity identifier, internal rating, cost, profit margin, and penalty records.

[0010] Preferably, determining the current processing state and performing processing operations corresponding to that state on the disclosable ontology fragment to generate the ontology fragment to be output includes: The processing flow transitions between request reception state, intent identification state, authorization level determination state, ontology path generation state, relation fragment filtering state, progressive disclosure state, risk review state, audit write-back state, and escalation authorization state. When entering the progressive disclosure state, the hierarchical output processing is performed on the disclosable ontology fragments to generate the ontology fragments to be output.

[0011] Preferably, the path accumulation risk is determined based on a combination of factors including the historical inquiry path, the number of consecutive follow-up inquiries, the target entity change trend, the relationship type change, and the number of times sensitive tags are hit; The reasoning leakage risk is used to determine whether combining multiple disclosed ontology fragments can lead to unauthorized entities, unauthorized relationships, unauthorized attributes, or unauthorized business conclusions.

[0012] Preferably, the downgraded disclosure includes replacing the ontology fragment to be output with a fragment containing only entity type, relationship type, or de-identified path; the upgrade authorization process includes triggering a manual approval process, requesting authorization from a high-privilege account, or generating a time-limited temporary authorization token.

[0013] Preferably, the disclosure audit record includes the request number, user hash value, agent role, authorization level, policy version, disclosure fragment summary, hidden relationship summary, review action, and call chain.

[0014] Preferably, determining the corresponding ontology relationship disclosure authorization level includes: The system obtains user roles, organizational levels, agent roles, data domain permissions, and task stages; calculates risk scores for historical inquiry paths; counts the number of times sensitive tags are hit; and, based on the approval status, jointly calculates the disclosure authorization level through a policy engine.

[0015] Preferably, the step of filtering disclosable ontology fragments from the candidate ontology relationship paths based on the disclosure authorization level, preset relationship sensitive tags, preset attribute sensitive tags, and preset path hop limit includes: setting an upper limit for the visible path hop count according to the authorization level, and pruning relationship paths that exceed the upper limit; and hiding, generalizing, or replacing edges and attributes that hit relationship sensitive tags or attribute sensitive tags according to the desensitization strategy corresponding to the authorization level.

[0016] Secondly, embodiments of this application provide a progressive disclosure system for data ontology relationships oriented towards intelligent agent interaction, including: The request parsing module is used to obtain the ontology relationship query request initiated by the intelligent agent. The query request carries at least user identity information, intelligent agent role information, target entity information, query intent information, context task information, and historical query path information. The authorization level determination module is used to determine the corresponding ontology relationship disclosure authorization level based on the user identity information, intelligent agent role information, query intent information, context task information, and historical query path information. The ontology path generation module is used to generate candidate ontology relationship paths in a preset data ontology graph based on the target entity information. The candidate ontology relationship paths include entity nodes, relationship edges, attribute fields, path hop count, relationship direction, and data source information. The relationship fragment filtering module is used to filter disclosable ontology fragments from the candidate ontology relationship paths based on the disclosure authorization level, preset relationship sensitive tags, preset attribute sensitive tags, and preset path hop count limits; wherein, the disclosable ontology fragments are fragments obtained by removing relationship edges that hit the relationship sensitive tags, removing attribute fields that hit the attribute sensitive tags, and trimming relationship paths that exceed the path hop count limits from the candidate ontology relationship paths; A state determination module is used to determine the current processing state and perform processing operations corresponding to the determined processing state on the disclosable ontology fragment to generate the ontology fragment to be output. The processing operations include at least layered output of the disclosable ontology fragment, with different layers corresponding to entity information, relationship information, attribute information and source information of different granularities. The risk review module is used to review the risk of the ontology fragment to be output, and at least detect the risk of unauthorized disclosure, risk of sensitive relationship combination disclosure, risk of path accumulation, and risk of reasoning leakage. The disclosure output module is used to output the ontology fragment to the intelligent agent if the review is passed, and to perform downgraded disclosure, rejection of disclosure, or upgrade authorization processing if the review is not passed. The audit write-back module is used to generate corresponding disclosure audit records if the review is approved.

[0017] Compared with the solutions of the prior art, the present invention has at least the following beneficial technical effects: (1) Breaking through the traditional static role and field-level control, the system incorporates multi-dimensional contextual information such as user identity, agent role, query intent, task stage, and historical query path into the authorization and level determination process. The strategy engine can dynamically calculate the disclosure authorization level for each query, achieving more precise and dynamic fine-grained control over access to ontology relation paths; (2) By defining multi-level authorization levels and corresponding hierarchical output granularity, and introducing a processing state machine to control the entire disclosure process, it is ensured that the agent can only obtain the minimum information fragment allowed by the current task context and authorization level at any given time. This effectively avoids the risk of exposing the entire relationship network at once by traditional methods, and limits the overexposure of information from a mechanistic perspective; (3) An isolation layer is established between the ontology path generation and the final output. The processor performs pruning, desensitization and fragmentation of the complete candidate relationship path according to the authorization level, path hop limit and sensitive tags. This makes the agent only able to see the securely processed relationship fragments and unable to directly traverse or deduce the complete relationship network beyond its authority, thus effectively protecting the core business relationships; (4) A mandatory risk review process is introduced before information output, integrating detection mechanisms such as unauthorized disclosure, sensitive relationship combination, path accumulation, and inference leakage. In particular, the path accumulation risk detection can proactively identify and block users from gradually approaching highly sensitive relationships through multiple rounds of follow-up questions and changing perspectives by analyzing historical inquiry paths; the inference leakage detection can prevent the deduction of high-value classified information after combining multiple low-sensitivity fragments. (5) The audit write-back mechanism fully records the entire process from request initiation to final disclosure, including authorization level, disclosure segment summary, hidden relationships, review actions, and risk reasons. This fine-grained audit record far exceeds traditional logs, and can clearly restore the decision-making process of each ontology relationship disclosure, providing a solid basis for data security compliance audit and post-event traceability; (6) Under the premise of ensuring security, information acquisition capabilities matching their roles and tasks are provided to users with different permissions, ensuring the availability of services. At the same time, by integrating and upgrading authorization processing, a secure and controlled high-level information acquisition channel is provided for high-privilege users or special scenarios, achieving a balance between security and efficiency. Attached Figure Description

[0018] Exemplary embodiments of the present invention can be more fully understood by referring to the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain the present invention and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0019] Figure 1 A flowchart illustrating the progressive disclosure method for data ontology relationships in intelligent agent interaction provided in this application embodiment; Figure 2 A schematic diagram of processing state transition provided for an exemplary embodiment of this application; Figure 3 A schematic diagram illustrating the correspondence between disclosure authorization levels and disclosure granularity provided for an exemplary embodiment of this application; Figure 4 A schematic diagram of the structure of a progressive disclosure system for data ontology relationships oriented towards intelligent agent interaction, provided as an exemplary embodiment of this application; Figure 5 A schematic diagram of an electronic device provided for an exemplary embodiment of this application; Figure 6 This is a schematic diagram of a computer-readable medium provided for an exemplary embodiment of this application. Detailed Implementation

[0020] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0021] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0022] Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other. It should be noted that the specific data objects, field names, and business relationships involved in the following embodiments are all represented by anonymized abstractions, which are intended to demonstrate the feasibility of the technical solution and do not constitute a limitation on real enterprise data.

[0023] Please refer to Figure 1 , Figure 1 This is a flowchart of a progressive disclosure method for data ontology relationships oriented towards intelligent agent interaction, as described in some embodiments of this application. The method in this embodiment is executed by a processor in the aforementioned system, and the method includes the following steps: S110, Obtain the ontology relationship query request initiated by the intelligent agent. The query request carries at least the user identity information, intelligent agent role information, target entity information, query intent information, context task information, and historical query path information. Specifically, the processor receives ontology relationship query requests initiated by various intelligent agents (such as data question-answering assistants, sales assistants, and auditing agents). These requests not only carry user identity information (such as hashed user identifiers) and agent role information (such as data question-answering agents and sales assistants), but also explicitly include target entity information, query intent information (such as "delivery anomaly analysis"), contextual task information, and historical query path information. The historical query path information records the sequence of questions asked by the user in the current session and the corresponding changes in the target entity, serving as a crucial basis for judging the accumulated risk of subsequent paths. This multi-dimensional information request structure enables the system to transition from single static authorization to dynamic authorization based on session context.

[0024] S120, determine the corresponding ontology relationship disclosure authorization level based on user identity information, agent role information, query intent information, context task information, and historical query path information; Specifically, the processor invokes the policy engine to jointly calculate the disclosure authorization level for this query based on the aforementioned multi-dimensional information. Specifically, a base level is first determined based on user role, organizational level, agent role, and data domain permissions. Then, it is dynamically adjusted by combining the current context task stage and calculating the risk score of historical query paths. For example, if the number of sensitive tag hits in a historical query path exceeds a threshold, or the path risk score exceeds a warning value, the base level will be downgraded. Simultaneously, the system will check for valid approval status; if so, the authorization level will be upgraded within the approved scope.

[0025] In one specific embodiment, such as Figure 3 As shown, the disclosure authorization levels are divided into six progressive levels, from L0 to L5. The disclosure granularity, path hop limit, and example information corresponding to each level are described in text below: Level 0: Disclosure granularity is an existence notification, with a path hop limit of 0. Example: "Related data exists, but current permissions are insufficient to view details." Level 1: Disclosure granularity is entity type disclosure, with a path hop limit of 0. Example: "There are customer entities, contract entities, and project entities." Level 2: Disclosure granularity is relationship type disclosure, with a path hop limit of 1. Example: "A contractual relationship exists between the customer and the contract." Level 3: Disclosure granularity is at the anonymized path level, with a path hop limit of 2. Example: "A certain customer has a delivery relationship with a certain project." Level 4: Disclosure granularity is limited to partial entity and non-sensitive attribute disclosures, with a path hop limit of 3. Example: "Customer A is associated with Project B, and the project status is 'In Progress'." Level L5: Disclosure granularity is complete relationship and data lineage disclosure, and the path hop count is limited to the entire path. Example: "Customer A — 'Signed' — Contract B — 'Corresponding' — Project C, data sourced from CRM and contract system, last update time is YYYY-MM-DD". S130, Based on the target entity information, generate candidate ontology relationship paths in the preset data ontology graph. The candidate ontology relationship paths include entity nodes, relationship edges, attribute fields, path hop count, relationship direction, and data source information. Starting with the target entity information in the query request, the processor performs a graph traversal operation within a pre-built enterprise data ontology graph. Following a preset maximum number of path hops (e.g., 3 or 4 hops), it generates all reachable candidate ontology relationship paths. Each candidate path is an ordered set of related data, specifically including entity nodes (e.g., customer A, contract B, project C), relationship edges (e.g., signing, corresponding, responsible), attribute fields, path hop count, relationship direction, and data source information.

[0026] In an alternative implementation, in addition to breadth-first traversal based on a fixed number of hops, the system can also employ a guided path expansion method based on semantic similarity. That is, based on the target relation type identified in the query intent, edges semantically related to the target relation type are expanded first, and irrelevant branches are pruned, thereby reducing the size of candidate paths while ensuring recall.

[0027] S140, based on the disclosure authorization level, preset relationship sensitive tags, preset attribute sensitive tags, and preset path hop limit, filter disclosable ontology fragments from candidate ontology relationship paths; wherein, the disclosable ontology fragments are fragments obtained by removing relationship edges that hit relationship sensitive tags, removing attribute fields that hit the attribute sensitive tags, and trimming relationship paths that exceed the path hop limit from candidate ontology relationship paths. Based on the determined disclosure authorization level, the processor performs security trimming and desensitization processing on the candidate ontology relationship paths generated in step S130 to generate disclosable ontology fragments. For ease of understanding, the specific meanings of the preset relationship-sensitive tags and preset attribute-sensitive tags involved in this step are explained below: (1) Relationship-sensitive tags include: personnel responsibility relationship (e.g., personnel-[responsible for]->project), contract amount relationship (e.g., contract-[amount]->specific amount), customer classification relationship (e.g., customer-[classified as]->first level), risk cause relationship (e.g., risk event-[cause]->internal operation), supplier cost relationship (e.g., supplier-[quote]->cost amount) and internal assessment relationship (e.g., personnel-[assessment result]->performance level); among them, the format "source entity-[relationship]->target entity" is used in the text to represent a directed ontology relationship instance in order to more clearly describe this ontology relationship.

[0028] (2) Attribute-sensitive labels include: amount (e.g., contract amount, payment received amount), identity identifier (e.g., employee ID), internal rating (e.g., customer credit score, supplier rating), cost (e.g., procurement cost, labor cost), profit margin (e.g., project profit margin, product gross profit margin) and penalty records (e.g., administrative penalties, internal disciplinary actions).

[0029] The specific filtering operations include: Path hop count pruning: Set an upper limit on the number of visible path hops based on the authorization level, and directly prune deeper relationship paths that exceed the limit. For example, level L3 may limit the number of path hops to 2 or less.

[0030] Sensitive Edge Handling: Check if there are any relationship edges in the candidate paths that match preset sensitive relationship tags. Sensitive relationship tags include at least personnel responsibility, contract amount, customer level, risk cause, and supplier cost. For edges that match tags, perform operations such as hiding (direct removal), generalization (e.g., generalizing "Personnel A - Responsible for - Project B" to "Personnel - Responsible for - Project"), or replacement according to their sensitivity level and current authorization level.

[0031] Sensitive attribute handling: Check if the attribute field matches the preset sensitive attribute tags, such as amount, identity identifier, internal rating, etc. For attributes that match the tags, perform desensitization, binning for display, or direct removal.

[0032] Data domain permission verification: Simultaneously adheres to data domain permission constraints, filtering out paths and fragments involving business domains that users are not authorized to access.

[0033] This step results in a set of disclosed ontology fragments that have been trimmed and desensitized, and that meet the current authorization level.

[0034] In a preferred embodiment, in addition to rule-based one-time filtering, the system can also employ a recursive filtering method based on a policy tree. This involves organizing constraints such as authorization level, sensitive labels, and data domain permissions into a decision tree structure. Each candidate path is recursively evaluated from the root node to the leaf nodes. At each level of the tree, path hop count constraints, relationship-sensitive filtering, attribute-sensitive filtering, data domain pruning, and desensitization replacement are applied sequentially. Paths or attributes blocked at any level are marked as hidden.

[0035] S150, determine the current processing state, and perform processing operations corresponding to the determined processing state on the disclosable ontology fragment to generate the ontology fragment to be output. The processing operations include at least layered output of the disclosable ontology fragment, with different layers corresponding to entity information, relationship information, attribute information and source information of different granularities. The processor internally maintains a state machine for a processing flow; in this embodiment, it is specifically a progressively disclosed state machine. For example... Figure 2 As shown, the processing states include, but are not limited to: S0 request reception state, S1 intent identification state, S2 authorization level determination state, S3 ontology path generation state, S4 relation fragment filtering state, S5 progressive disclosure state, S6 risk review state, S7 audit write-back state, and S8 upgraded authorization state. After executing step S140, the processor determines that the current state should transition to the S5 progressive disclosure state. In state S5, the processor, based on the authorization level determined in step S120, outputs the disclosable ontology fragments in layers according to the granularity corresponding to that level. Different layers correspond to different granularities of entity information, relation information, attribute information, and source information, and their correspondence is as follows: Figure 3 As shown.

[0036] S160, perform risk review on the ontology fragment to be output, at least detect the risk of unauthorized disclosure, risk of sensitive relationship combination disclosure, risk of path accumulation, and risk of reasoning leakage; Before the final output, the processing flow must transition from the S5 state to the S6 risk review state, forcibly executing a risk review. This is a critical security step in this method, encompassing at least the following four dimensions of detection: Unauthorized disclosure detection: Determines whether the content of the ontology fragment to be output is strictly within the scope allowed by the current authorization level.

[0037] Sensitive Relationship Combination Detection: This function determines whether combining the currently intended output fragment with other low-sensitivity fragments already output in the current session will lead to a conclusion that can deduce high-sensitivity information. For example, disclosing "Project Name" and "Number of Work Orders" individually may be L4-level disclosure content, but combining them can infer internal resource bottlenecks, triggering a downgrade process based on this information.

[0038] Path Accumulation Risk Detection: This feature calculates a path accumulation risk score for the current request by considering multiple factors, including historical query paths, number of consecutive follow-up queries, target entity change trends, relationship type changes, and the number of times historical sensitive tags have been hit. This score determines whether the user is exhibiting a pattern of gradually approaching highly sensitive relationships through multiple rounds of follow-up questions. When the score exceeds a preset threshold, an alert is triggered and the authorization level is downgraded.

[0039] Reasoning Leakage Detection: This function determines whether an agent, based on all obtained ontology fragments (including historical and current outputs), can logically deduce unauthorized entities, relationships, attributes, or unauthorized business conclusions. The system can perform relational transitive closure calculations on the disclosed fragments; if the closure contains unauthorized entities or relationships, a reasoning leakage risk is identified.

[0040] If any of the above tests is deemed high-risk, the review will fail.

[0041] S170, if the review passes, the ontology fragment is output to the intelligent agent, and a corresponding disclosure audit record is generated; if the review fails, downgraded disclosure, rejection of disclosure, or upgrade authorization processing is performed.

[0042] The processor executes branch operations based on the verification results of S106, specifically including: (1) If the review is successful, the processor executes the normal output process: outputting the ontology fragment to the intelligent agent and driving the process into the S7 audit write-back state, generating the corresponding disclosure audit record. The disclosure audit record contains the following information: The request number is used to uniquely identify an ontology relation query request. The user hash value is the value obtained by hashing the identity identifier of the user who initiated the request; The agent role refers to the business role of the agent that initiated the request. The authorization level refers to the final authorization level disclosed herein. Policy version: The version number of the policy engine used to generate the authorization level; The disclosure fragment summary is a text summary of the ontology relation fragments actually disclosed to the agent; Hidden relation summary, which is a summary of relation edges that have been hidden, generalized or replaced due to hitting sensitive tags; The review action refers to the result of a risk review, such as "approved," "downgraded disclosure," or "rejected." The call chain is the complete service call chain information from receiving a request to its final disclosure.

[0043] (2) If the review fails, the processor will perform a security alternative process: depending on the risk type, it will choose to perform a downgraded disclosure, refuse disclosure, or trigger an upgrade authorization process. Downgraded disclosure means replacing the intended output fragment with a less informative and secure version, such as replacing the specific responsibility relationship with an internal responsibility attribution that requires higher privileges to view. The upgrade authorization process may trigger manual approval, request secondary confirmation from a high-privilege account, or generate a time-limited temporary authorization token; once the authorization is completed, the process will return to the authorization level judgment state.

[0044] The method in this embodiment extends static field-level permission verification to dynamic relationship-path-level security control through a complete closed loop, including multi-dimensional information authorization level judgment, candidate path generation and screening, progressive disclosure state machine control, multi-risk review, and audit write-back. In particular, steps S140 and S160, by setting relationship-sensitive tags, attribute-sensitive tags, and detecting path accumulation risk and reasoning leakage risk, accurately solve the technical challenge of gradually approaching highly sensitive information through follow-up questions and combined reasoning in multi-round interactions. This significantly improves the security and controllability of data ontology disclosure while ensuring the availability of intelligent agent services.

[0045] Please refer to Figure 1 , 2 and Figure 4 This embodiment will further explain the above method in detail with a specific application scenario and system module.

[0046] Figure 4 This is a schematic diagram of the architecture of a progressive disclosure system for data ontology relationships oriented towards intelligent agent interaction, as described in some embodiments of this application. The system includes: a request parsing module 410, an authorization level determination module 420, an ontology path generation module 430, a relationship fragment filtering module 440, and a state determination module 450 (whose functions may correspond to...). Figure 2 The system includes a progressive disclosure state machine, a risk review module 460, a disclosure output module 470, and an audit write-back module 480. The system interacts with the enterprise's data ontology graph, permission center, sensitive tag library, combined rule library, and audit log library through interfaces.

[0047] In this embodiment, the business scenario involves a salesperson asking a sales assistant AI, "Why has the delivery schedule for a certain important customer slowed down recently?" The system execution flow is as follows: (1) First, the request parsing module 410 executes step S110. This module extracts information from the request forwarded by the agent: user hash value, agent role is "sales assistant", target entity is "important customer X" (for ease of description, the internal code of this customer will be referred to as CUST-X, where "CUST" is the abbreviation of Customer and "X" is the sequence number), query intent is "delivery anomaly (delay) analysis", task stage is "business query and analysis", and the historical query path of the current session is attached (for example, the previous round queried the overall sales of this customer).

[0048] (2) Next, the authorization level determination module 420 executes step S120. This module receives the parsed information, combines the user role and sales data domain permissions obtained from the permission center, and calculates the basic disclosure authorization level through the policy engine. Considering that the current task is a routine analysis and the risk score of the historical inquiry path is not high, the final disclosure authorization level is determined to be L3 (disclosure via de-identified path).

[0049] (3) Subsequently, the ontology path generation module 430 executes step S130. This module starts with "Important Customer X (coded as CUST-X)" and performs a traversal within the enterprise data ontology graph, generating the following candidate relationship paths. For ease of understanding, the abbreviations for each code are explained: CONTRACT-Y (Contract Y) represents a specific contract Y under the client's name; PROJECT-Z (Project Z) represents a specific project Z; WORK-ORDER-A (Work Order A) represents a work order A; EMPLOYEE-B (Employee B) represents employee B; RISK-EVENT-C (Risk Event C) represents a risk event C.

[0050] The following candidate relation paths were generated: Key Customer X (CUST-X) — [Signing] — Contract Y (CONTRACT-Y) — [Corresponding] — Project Z (PROJECT-Z) — [Generated] — Work Order A (WORK-ORDER-A); Project Z — [Responsible] — Employee B; Project Z — [Trigger] — Risk Event C (where Risk Event C includes the attribute "Risk Details"); These paths include all nodes, relationship edges (such as signing, responsibility, triggering), attribute fields, and the number of path hops (2 or 3 hops).

[0051] (4) Next, step S140 is executed by the relationship fragment filtering module 440. This module filters based on L3 level, sensitive tags loaded from the sensitive tag library, and path hop limit (set to 2 hops): Cut off all paths that have more than 2 hops (such as Project Z — [Generate] — Work Order A).

[0052] The relationship edge “[responsible]” was detected to be a sensitive label for the “personnel responsibility” relationship, so the entire path containing this edge was removed.

[0053] The "Name" attribute of the entity "Employee B (EMPLOYEE-B)" was detected to be a sensitive label of the "Identity" attribute, and it was marked as hidden.

[0054] The "Risk Details" attribute of "Risk Event C (RISK-EVENT-C)" was detected to potentially involve the sensitive "Risk Cause" label, and was therefore de-identified.

[0055] The final disclosable ontology fragment is: "The customer (CUST-X) is associated with the project (PROJECT-Z) through the contract (CONTRACT-Y); the project generates a backlog of work orders and triggers risk events related to external dependencies." (5) After that, the state determination module 450 drives step S150, and the processing flow enters the progressive disclosure state S5. According to the L3 authorization level, the module outputs the above fragments in layers as information suitable for L3 granularity, forming the ontology fragments to be output.

[0056] (6) Before output, step S160 is executed by the risk review module 460. The module performs checks based on the combined rule base: Unauthorized disclosure detection: The output content conforms to the L3 level range and passes.

[0057] Sensitive Relationship Combination Detection: Since personnel responsibility information has been removed, the combination of the current segment and the historical sales segment does not pose a risk of unauthorized access or leakage of inference.

[0058] Path cumulative risk detection: This is the first time a risk-related question has been asked, and the path cumulative score is within a safe range.

[0059] Leakage detection based on inference: The specific responsible party cannot be deduced based on the anonymized fragments, thus passing the test.

[0060] Based on the overall assessment, the review result is approved.

[0061] (7) Finally, the disclosure output module 470 and the audit write-back module 480 execute step S170. The disclosure output module 470 returns the fragment "The customer (CUST-X) is associated with the project (PROJECT-Z) through the contract (CONTRACT-Y); the project has generated a backlog of work orders and triggered risk events related to external dependencies." to the agent. At the same time, the audit write-back module 480 writes all the information of this operation, including the summary of the disclosed fragment, the hidden personnel responsible relationships and risk details attributes, the review and approval actions, etc., into the audit log library to form a complete audit record.

[0062] When the salesperson followed up with "which specific delivery manager caused the delay," the system restarted. The request parsing module 410 identified the target entity for this follow-up as the delivery manager, intending to investigate the personnel's responsibility. While the authorization level module 420 maintained Level 3, it detected an increase in the number of sensitive tags hit in the historical inquiry path, leading to a higher risk score.

[0063] The ontology path generation module 430 generates a path again containing "Employee B (EMPLOYEE-B)" and its "[responsible]" relationship. In the relationship fragment filtering module 440, because the personnel responsibility relationship is a highly sensitive label, this path is listed as an object to be hidden. When the fragment enters the risk review module 460, the path cumulative risk detection identifies that the user is approaching the highly sensitive relationship through continuous questioning, and the sensitive relationship combination detection also determines that there is a high risk. The review result is that it fails.

[0064] The system then performs a downgraded disclosure, returning a security response to the agent through the disclosure output module 470: "This issue involves internal attribution of responsibility and requires authorization from higher privileges or project management roles to view." At the same time, the audit write-back module 480 records in detail the interception behavior, the type of relationship intercepted, and the reason for the risk.

[0065] Subsequently, if the salesperson's supervisor intervenes and completes the approval, the system will trigger an upgrade authorization process, obtain the L5 authorization level, re-execute the authorization level judgment and subsequent steps, and finally disclose the complete responsibility relationship and lineage to the supervisor, thus meeting the compliance disclosure requirements under high authority.

[0066] This embodiment demonstrates that the system and method, through a closed-loop process of request parsing, authorization level determination, path generation, fragment filtering, progressive disclosure, risk review, and audit write-back, as well as a refined sensitive label and risk detection mechanism, achieve dynamic, secure, and controllable disclosure of data ontology relationships in intelligent agent interaction scenarios.

[0067] Please refer to Figure 5 This illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 5 As shown, the electronic device 50 includes: a processor 500, a memory 501, a bus 502, and a communication interface 503. The processor 500, the communication interface 503, and the memory 501 are connected via the bus 502. The memory 501 stores a computer program that can run on the processor 500. When the processor 500 runs the computer program, it executes the method described above in this application.

[0068] The memory 501 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 503 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0069] Bus 502 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 501 is used to store programs. After receiving an execution instruction, the processor 500 executes the program. The methods disclosed in any of the foregoing embodiments of this application can be applied to the processor 500, or implemented by the processor 500.

[0070] The processor 500 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 500 or by instructions in software form. The processor 500 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 501. The processor 500 reads the information in memory 501 and, in conjunction with its hardware, completes the steps of the above method.

[0071] The electronic device and the method provided in this application are based on the same inventive concept and have the same beneficial effects as the methods used, operated, or implemented therein. The electronic device may be a server, a data operation platform host, or a network device with computing capabilities.

[0072] This application also provides a computer-readable medium corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 6 The computer-readable storage medium shown is an optical disc 60, on which a computer program (i.e., a program product) is stored, which, when run by a processor, performs the aforementioned method.

[0073] The computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. In a specific application scenario, the computer-readable storage medium may be built into a conference terminal or mobile terminal as part of the firmware; or it may be a standalone software product.

[0074] The computer-readable storage medium provided in the above embodiments of this application and the method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0075] This embodiment also provides a computer program product, which includes a computer program. When executed by a processor, the computer program implements the methods described in any of the above embodiments.

[0076] The computer program product may include any combination of one or more program modules.

[0077] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0078] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0079] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0080] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application.

Claims

1. A progressive disclosure method for data ontology relationships in intelligent agent interaction, characterized in that, The processor performs the following steps: Obtain an ontology relationship query request initiated by an intelligent agent, wherein the query request carries at least user identity information, intelligent agent role information, target entity information, query intent information, context task information, and historical query path information; Based on the user identity information, agent role information, query intent information, context task information, and historical query path information, determine the corresponding ontology relationship disclosure authorization level; Based on the target entity information, candidate ontology relationship paths are generated in a preset data ontology graph. The candidate ontology relationship paths include entity nodes, relationship edges, attribute fields, path hop count, relationship direction, and data source information. Based on the disclosure authorization level, preset relationship sensitive tags, preset attribute sensitive tags, and preset path hop limit, disclosable ontology fragments are selected from the candidate ontology relationship paths; wherein, the disclosable ontology fragments are fragments obtained by removing relationship edges that hit the relationship sensitive tags, removing attribute fields that hit the attribute sensitive tags, and trimming relationship paths that exceed the path hop limit from the candidate ontology relationship paths. The current processing state is determined, and the processing operation corresponding to the state is performed on the disclosable ontology fragment to generate the ontology fragment to be output. The processing operation includes at least layered output of the disclosable ontology fragment, with different layers corresponding to entity information, relationship information, attribute information and source information of different granularities. The ontology fragment to be output is subject to risk review, at least detecting risks of unauthorized disclosure, disclosure of sensitive relationship combinations, path accumulation, and leakage of reasoning. If the review passes, the ontology fragment is output to the intelligent agent, and a corresponding disclosure audit record is generated; if the review fails, downgraded disclosure, rejection of disclosure, or upgrade authorization is performed. The ontology relationship disclosure authorization levels include six levels from L0 to L5, where L0 corresponds to existence indication, L1 corresponds to entity type disclosure, L2 corresponds to relationship type disclosure, L3 corresponds to desensitization path disclosure, L4 corresponds to partial entity and non-sensitive attribute disclosure, and L5 corresponds to complete relationship and data lineage disclosure. The relationship-sensitive labels include at least one of the following: personnel responsibility relationship labels, contract amount relationship labels, customer classification relationship labels, risk cause relationship labels, supplier cost relationship labels, and internal assessment relationship labels; the attribute-sensitive labels include at least one of the following: amount, identity identifier, internal rating, cost, profit margin, and penalty records.

2. The method according to claim 1, characterized in that, The step of determining the current processing state and, based on the determined processing state, performing processing operations corresponding to that state on the disclosable ontology fragment to generate the ontology fragment to be output includes: The processing flow transitions between request reception state, intent identification state, authorization level determination state, ontology path generation state, relation fragment filtering state, progressive disclosure state, risk review state, audit write-back state, and escalation authorization state. When entering the progressive disclosure state, the hierarchical output processing is performed on the disclosable ontology fragments to generate the ontology fragments to be output.

3. The method according to claim 1, characterized in that, The path accumulation risk is determined based on a combination of factors, including the historical inquiry path, the number of consecutive follow-up inquiries, the changing trend of the target entity, the change of the relationship type, and the number of times sensitive tags are hit. The reasoning leakage risk is used to determine whether combining multiple disclosed ontology fragments can lead to unauthorized entities, unauthorized relationships, unauthorized attributes, or unauthorized business conclusions.

4. The method according to claim 1, characterized in that, The downgraded disclosure includes replacing the ontology fragment to be output with a fragment that only contains entity type, relationship type, or desensitized path; the upgrade authorization process includes triggering a manual approval process, requesting authorization from a high-privilege account, or generating a time-limited temporary authorization token.

5. The method according to claim 1, characterized in that, The disclosure audit log includes the request number, user hash value, agent role, authorization level, policy version, disclosure fragment summary, hidden relationship summary, review action, and call chain.

6. The method according to any one of claims 1 to 5, characterized in that, The determination of the corresponding ontology relationship disclosure authorization level includes: The system obtains user roles, organizational levels, agent roles, data domain permissions, and task stages; calculates risk scores for historical inquiry paths; counts the number of times sensitive tags are hit; and, based on the approval status, jointly calculates the disclosure authorization level through a policy engine.

7. The method according to any one of claims 1 to 5, characterized in that, The step of filtering disclosable ontology fragments from the candidate ontology relationship paths based on the disclosure authorization level, preset relationship sensitive tags, preset attribute sensitive tags, and preset path hop limit includes: setting an upper limit for the visible path hop count according to the authorization level, and pruning relationship paths that exceed the upper limit; and hiding, generalizing, or replacing edges and attributes that hit relationship sensitive tags or attribute sensitive tags according to the desensitization strategy corresponding to the authorization level.

8. A progressive disclosure system for data ontology relationships for intelligent agent interaction, characterized in that, include: The request parsing module is used to obtain the ontology relationship query request initiated by the intelligent agent. The query request carries at least user identity information, intelligent agent role information, target entity information, query intent information, context task information, and historical query path information. The authorization level determination module is used to determine the corresponding ontology relationship disclosure authorization level based on the user identity information, intelligent agent role information, query intent information, context task information, and historical query path information. The ontology path generation module is used to generate candidate ontology relationship paths in a preset data ontology graph based on the target entity information. The candidate ontology relationship paths include entity nodes, relationship edges, attribute fields, path hop count, relationship direction, and data source information. The relationship fragment filtering module is used to filter disclosable ontology fragments from the candidate ontology relationship paths based on the disclosure authorization level, preset relationship sensitive tags, preset attribute sensitive tags, and preset path hop count limits; wherein, the disclosable ontology fragments are fragments obtained by removing relationship edges that hit the relationship sensitive tags, removing attribute fields that hit the attribute sensitive tags, and trimming relationship paths that exceed the path hop count limits from the candidate ontology relationship paths; A state determination module is used to determine the current processing state and perform processing operations corresponding to the determined processing state on the disclosable ontology fragment to generate the ontology fragment to be output. The processing operations include at least layered output of the disclosable ontology fragment, with different layers corresponding to entity information, relationship information, attribute information and source information of different granularities. The risk review module is used to review the risk of the ontology fragment to be output, and at least detect the risk of unauthorized disclosure, risk of sensitive relationship combination disclosure, risk of path accumulation, and risk of reasoning leakage. The disclosure output module is used to output the ontology fragment to the intelligent agent if the review is passed, and to perform downgraded disclosure, rejection of disclosure, or upgrade authorization processing if the review is not passed. The audit write-back module is used to generate corresponding disclosure audit records if the review is approved. The ontology relationship disclosure authorization levels include six levels from L0 to L5, where L0 corresponds to existence indication, L1 corresponds to entity type disclosure, L2 corresponds to relationship type disclosure, L3 corresponds to desensitization path disclosure, L4 corresponds to partial entity and non-sensitive attribute disclosure, and L5 corresponds to complete relationship and data lineage disclosure. The relationship-sensitive labels include at least one of the following: personnel responsibility relationship labels, contract amount relationship labels, customer classification relationship labels, risk cause relationship labels, supplier cost relationship labels, and internal assessment relationship labels; the attribute-sensitive labels include at least one of the following: amount, identity identifier, internal rating, cost, profit margin, and penalty records.

Images