Evidence-based exposure assessment, conditional attack path modeling, and protection orchestration system and methodology for verified digital assets and authorized network contexts.

Abstract

The invention relates to a computer-based system and method that links the verified digital assets of an individual or entity with an authorized abstract network context, within a common protective envelope containing principal, subject, tenant, scope, duration, and integrity fingerprints. Discovery, passive evidence, owner-attested control, isolated technical verification, and the results of enterprise network assurance engines are normalized to a common evidence graph that protects the source engine, canonical entity / context, provenance, evidence status, and scope completeness. A clean result is blocked if the expected engine result is missing or fails; the security score, evidence confidence, and control completeness are kept separate. Normalized evidence is transformed into conditional attack paths separated into observed fact, attacker intent, still necessary condition for the attack, potential impact, and chain-breaking control. Remediation, user-approved exposure removal, and monitoring processes are linked to the same authorization and evidence chain.The executive summary, technical ledger, and PDF are generated from the same canonical assessment; the language model cannot alter findings or scores.

Description

1 DEFINITION Evidence-based for verified digital assets and authorized network contexts. Exposure assessment, conditional attack path modeling, and protection orchestration. system and method Technical field The invention relates to computer and network security, digital identity and asset control verification, and personal and corporate processes. Attack surface management, security evidence normalization, isolated technical verification, network security status assessment, conditional attack path modeling, security audit This relates to prioritization, digital exposure de-exposure, and continuous security monitoring. More specifically, the invention combines results obtained from different sources and evaluation engines in the same way. principal, subject, tenant, scope of authority, verified entity, or authorized network context a protective envelope connecting them; the results of which are preserved in common evidence records of the source family tree. a transformative evidence graph; separating the completeness of the assessment scope from the safety outcome a scope agreement; a correlation layer that generates conditional attack paths from the evidence and a contract The subject is a system that manages protection, removal, and monitoring operations for roads that break through, all within the same database. It relates to the orchestration control plane. State of the art Known person search and digital footprint systems identify websites that match a name or contact information. It can list the results. Known identity protection systems can track data breach records, data You can send deletion requests to their brokers or report fake accounts. Known vulnerability. Scanner systems use a user-assigned domain, IP address, URI, or repository. Technical evaluation can be performed on it. Known attack-graph systems can identify vulnerabilities and It can generate attack paths and remediation suggestions from network topology data. Known security- Posture systems can calculate risk scores from control responses or telemetry. Known Monitoring systems can report changes between successive scans. When these systems are used separately, the following technical problems arise:  A source found through similarity of names can be assumed to belong to its owner;  Verification or consent record, subsequent scanning, reporting, removal and monitoring processes separable;  Results from different engines can be combined without a common provenance and scope model;  A failed or malfunctioning engine can be interpreted as a clean result;  A low confidence score can be presented as a high-confidence result despite the completeness of the evidence;  Public web applications and technical validation tools can operate within the same confidence level; 2  Raw configuration, credentials, packet capture, or vehicle output are unnecessarily sent to the central system. portable;  The observed reality, the potential value for the attacker, the amount required for the attack to occur, but The unobserved circumstance and the claim of a genuine compromise can become intertwined;  Remediation, removal, and monitoring processes revert to the evidence and authorization record that gave rise to them. It may not be able to connect; and  The executive narrative generated by generative AI is based on canonical findings and statistics. It may deviate. Known unified security graph systems can combine different security graphs; known network Scoring systems can generate scores from topology or behavior; well-known privacy systems can generate scores from personal data. It can automate deletion requests. However, a person's or organization's verified digital data... gathering their assets and the authorized abstract network context within a single protective envelope; each linking the assessment engine to the scope and time limit of this envelope; the scope of the engine Verifying the integrity of fail-closed data; personal exposure, technical asset findings, and network architecture. converting their controls into the same canonical evidence graph; conditional attack path, remediation, an integrated technique that manages removal and subsequent change tracking within the same provenance chain Architecture is needed. The purpose of the invention The purpose of the invention is to create a digital product belonging to a person or entity, but not limited to the commercial product called Paxvian. The goal is to unify conservation efforts under a single technical confidence limit and evidentiary model. The system is designed for this purpose:  Person or entity to be protected, principal performing the transaction, tenant, basis of authority, scope and expiry It binds its information in a protective envelope;  Verified or user-approved assets with candidate assets found from each other technically they separate;  Which engines are used on verified entities and authorized network contexts that it can work determined by the server policy;  Passive evidence, owner-attested verification, isolated technical verification, and abstract network assessment results 3 It converts it into a common evidence graph without losing provenance;  It calculates engine completeness, evidence confidence, and control completeness separately from the risk / score outcome;  The observed findings transform the conditional attack pathway, potential impact, and chain-breaking control into action;  Optionally automatic, user-driven, or operator-managed remediation / removal It initiates its actions only on valid authority and verified targets;  Identifies new, changed, and resolved evidence in optional sequential snapshots; and  It generates optional executive summary, technical ledger, and PDF report from the same canonical evidence. Explanation of the figures  Figure 1: Shows the components of the unified digital protection platform and the common data flow.  Figure 2: Consisting of principal, subject, tenant, authority, and verified entity / network context. protection He shows the envelope.  Figure 3: Discovery, passive protection, controlled technical verification, and network assurance engines. partner It shows how to connect it to the evidence graph.  Figure 4: Non-modifiable evaluation plan, tenant queue, one-time lease, and isolated This shows the worker life cycle.  Figure 5: Contextual control applicability, abstract topology, score, evidential confidence, and control. It shows the network assurance flow that produces integrity.  Figure 6: Shows the generation of conditional attack path and remediation control from normalized evidence.  Figure 7: Protection action, approved removal, monitoring snapshot, change alarm and canonical The report shows the life cycle. Reference numbers  100 Client system  110 Subject and identity analysis module  120 Control verification and authorization module  130 Protective envelopes  140 Canonical protection / evidence graphs 4  150 Discovery and passive evidence engines  160 Controlled technical verification plane  170 Enterprise network assurance engine  180 Evidence normalization and scope validation module  190 Conditional attack paths and risk engines  200 Protection and remediation orchestration module  210 Monitoring and change detection module  220 Approved exposure reduction modules  230 Canonical reporting and grounded narrative module  240 Tenant comprehensive audit module  250 Verified or approved asset records  260 Authorized abstract network context  270 Normalized evidence records  280 Scope and completeness record  290 Conditional attack path records  300 Remediation or protective actions  310 Monitoring snapshot  320 Removal authorization record  330 Irrevocable technical verification plan  340 Worker-bound disposable leases Detailed description of the invention 1. Common protective envelope The client system (100) checks and verifies an initiation request relating to the subject to be protected. It transmits to the authorization module (120). Subject: real person, manager, employee, corporate tenant or This could be a corporate network security context. The principal performing the transaction and the protected subject may be the same person; In corporate protection, the principal is the party who accepts the invitation or acts on behalf of the organization, and the subject is the party who is the principal. It can be based on a given valid role. Module (120) creates the protection envelope (130) which includes at least one part of the following fields:  Opaque principal, subject, and tenant identities;  Self-verified, delegated, owner-attested, or authorized-assessment authorization basis;  allowed discovery, validation, network-assurance, monitoring, removal and reporting scopes;  Creation, termination, and cancellation time;  Verification or accepted invitation ID;  canonical identities of verified entity records;  version ID of the authorized abstract network context; and  Integrity fingerprint derived from envelope contents. The envelope allows different product features to be worked on randomly or with different authorities regarding the same subject. The common technical limitation is that each downstream job carries its own envelope version and fingerprint. No work will be created or accepted as a result if there is a discrepancy in scope, expiry, tenant, or subject. The envelope contains opaque identifiers derived from the canonical target, instead of raw communication or account data. It can carry fingerprints. Thus, different principal, subject, tenant, target, time window, or Engine outputs from the policy version are prevented from being mixed into the same evaluation. 2. Identity analysis and entity status Subject and identity resolution module (110) normalizes the declared name of the subject; allowed Profiles, domains, repositories, news, documents, company links or from public / indexed sources. It can receive other digital footprint candidates. Each candidate URL is canonicalized. Platform login, directory, Search, group, and post URLs are rejected as profile entities. For each candidate found, the following are recorded: source, query, title, snippet, handle, cross-linking, organization, The city, website, or equivalent evidence is recorded. The system ranks candidates as confirmed or probable. It separates them into explainable cases such as ambiguous or excluded. Just name similarity, URL... Accessibility or estimated handle does not count as proof of asset ownership. A candidate has been verified following user approval or a technical challenge appropriate to the asset type. or can be converted to a verified entity record (250). Challenge; DNS TXT, HTTP, OAuth, profile bio The token could be a mailbox code or repository challenge. The record is a canonical entity, owner principal. The verification method, fingerprint, time, and expiry are recorded; the raw token is not stored. Candidate the asset in question, asset-specific technical verification, managed removal or monitoring It is not silently passed into the scope. 3. Canonical preservation and evidence chart. Canonical protection / evidence graph (140), heterogeneous data from different engines common, tenant It stores a comprehensive and source family tree in a protected data structure. In the graph, for example, subject, identity, asset, profile, domain, mailbox, repository, breach event, public mention, security control, network zone, trust link, evidence, attack condition, impact, remediation action, removal Case and snapshot nodes can be found. Each evidence edge requires at least the source engine, source ID, observation time, envelope fingerprint, The evidence carries the state, confidence class, and canonical asset / context identifier. It is the same URL or... Different spellings of the entity are unified with the canonical key. Tenant limits in graph queries. 6 This is applied as a mandatory filter. A node or edge belonging to one tenant may be filtered out by another tenant's results. cannot participate. 4. Engine orchestration and scope agreement When the protective envelope is in effect, the system generates an engine plan based on the scope and entity / context type. Engines can be classified into four main categories: 1. Discovery and public-evidence engines (150); 2. Passive or controlled technical verification engines on verified assets (160); 3. Enterprise network assurance engine (170); and 4. Owner-attested hardening or recovery control engines. Each plan includes the expected engine IDs, engine versions, input class, and time window. It includes resource budgets and which output states will be fully counted. Evidence normalization. and scope verification module (180), complete-with-findings, complete-without- for each engine findings, timeout, provider-failure, parser-failure, budget-exceeded, not-applicable, not- answered or equivalent discrete status. If the expected engine result is incomplete or shows an error, the system returns a clean / risk-free result. It cannot pass. The security score is separate from coverage, evidence confidence, and control completeness. This ensures that a high score is obtained from a small number of successful tests, thus providing complete and high security. It is not presented as an evaluation. The engine result is only with the planned engine ID and version, the same as above. observation with envelope fingerprint, the same canonical target fingerprint, and within the envelope time window. It is accepted if it matches the time. Unexpected engine, repetitive engine result, another target. Relevant evidence or duplicate canonical evidence within the same run is rejected as fail-closed. Zero The result will only be a clean result when all expected engines are fully completed. It can be marked. 5. Discovery and passive protection motors Discovery and passive evidence engines (150), permissioned search sources, official platform APIs, secure Sources such as HTTP transport, breach metadata service, DNS, TLS, and mail trust records. It can use the scheme, credential, and resolved target provided by the user in each redirect. Verified in terms of IP and private network range. Provider error generated by another provider. It is not transformed into a fake fallback candidate. Passive protection modules, for example:  For verified domains: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, TLS and lookalike- Domain proofs;  Name, date, and data classes of the breach event for the verified mailbox;  Impersonation surface, recovery hardening, and profile integrity for verified social profiles; 7 • Bounded header, TLS, and security configuration proofs for the verified web presence;  owner-attested MFA, recovery mailbox, recovery phone, session, connected-app and backup- code controls It can generate them. Raw credentials, breach passwords, or private message content are not graphed. 6. Controlled technical verification Controlled technical verification plane (160), verified asset registration (250) and protection envelope If scope is valid, it produces an unchangeable technical verification plan (330). The plan; canonical target, verification fingerprint, grant / scope ID, authorized motors, precise executable paths, fixed Argument vectors include time / output / finding budget, creation and termination time. User executable, template, command, environment variable, or free tool parameter It cannot provide. The plan tenant is written to the comprehensive queue and, separate from the public web process, is assigned to the worker for a limited time. It is issued with a one-time lease (340) that is linked to its identity. Only the hash of the lease token is checked. is stored in the plane. Worker non-root, read-only filesystem, dropped capability, no-new- Privileges, CPU / memory / PID limits, dedicated temporary workspace, and canonical target limitations. It can run under egress. Tools can run without a shell, with the exact executable / argument allowlist. It is started. The worker does not move the raw stdout / stderr or workspace to the central control plane; it normalizes. It sends a finding and limited error code. The server provides lease, worker, target, envelope fingerprint, and expected data. Re-verifies the motor scope. Timeout, parser failure, output limit, scope expiry, or missing scope. The engine's response results in the work being incomplete and it cannot produce a clean result. 7. Authorized corporate network context Enterprise network assurance engine (170), real IP / CIDR, credential, raw device config, packet capture, arbitrary command or exploit output is an abstract network context that runs without requesting output (260) It accepts. Context; pseudonymous zone identities, zone type, criticality, internet accessibility. It can consist of directional trust links with status and allowlist-based enforcement types. Organizational profile: internet-facing, DMZ, remote access, cloud, BGP, OT / IoT, number of sites, and network. It can include contextual flags such as the number of devices. The versioned control catalog lists each control as follows: weight, criticality, minimum perimeter size, applicability condition, and remediation It carries the contract. Unexecuted control is removed from the score. unknown answer control It reduces completeness and reliability of evidence without turning it into a failure. The engine can produce the following separate values:  Security score from the applicable controls answered;  control completeness, which is the response rate of applicable controls; 35 8  evidence confidence from the answered portion of the applicable risk weight;  Findings from critical no or unknown answers;  Remediation order based on potential score gain from partial or no controls; and  Absence of DMZ boundary on abstract topology, users-to-critical weak path, OT / IT bridge, Design insights such as management plane access or an internal zone directly connected to the internet. Topology insights and cross-signal interpretations may not change the numeric score. unknown No proven architectural findings are produced from the answers. Each evaluation is based on the catalogs used and... It connects to the context version. 8. Normalization of evidence Proof normalization and scope validation module (180) treats each engine output as untrusted data. It accepts and converts the evidence record (270) into a normalized evidence record. The record must contain at least the following: It may include:  canonical subject, asset, or network-context identifier;  Source engine and version;  Type, time, and state of observation;  observed value or redacted summary;  evidence confidence class;  envelope and scope fingerprint;  coverage / completeness record (280); and  Source reference or audit event ID. URL query secrets, raw credentials, unverified personal data, unauthorized non-repository paths, and Uncontrolled tool diagnostics are not normalized as evidence. Repeated instances of the same evidence are not included in the canonical key. They are combined; conflicting evidence is preserved with separate state and provenance instead of being dismissed. 9. Conditional attack path and combined score Conditional attack path and risk engine (190), normalized evidence in the graph with the same subject / tenant and Correlates within the valid scope. Each conditional attack path record (290) must contain at least the following fields: keep them separate: 1. observed evidence; 2. attacker value or objective; 3. A required condition that is still necessary for the actual attack but is not being observed; Potential impact if condition 4 occurs; 5. Remediation control that breaks the chain; 6. The execution state indicates that the attack / exploit is not running; and 9 Source evidence node IDs for path 7. For example, weak mail authentication, public executive identity, and breach on a verified domain. If the generated recovery mailbox metadata is associated with the same subject, the system will generate an impersonation / account. A takeover chain can be established; however, if mailbox access or platform recovery acceptance is not observed... It lists these as required conditions and does not claim compromise. If a combined safety score is used, each point contribution is named a positive / negative contribution. It is linked to canonical evidence or owner-attested verification. The scoring aspect is fixed; for example... A higher value indicates a safer situation. If coverage is low, the score alone indicates a strong posture. It is not presented in this way. 10. Conservation and remediation orchestration Protection and remediation orchestration module (200), remediation for each path or control vulnerability or constitutes a protective action (300). Actions:  can be implemented automatically by the system;  Guided step-by-step by the user;  Operator-managed due to an external platform or institution; or  remaining only at the level of evidence / suggestion They can be divided into classes. Each action involves source finding, owner, required authorization, target asset / context, and expected results. Technical impact includes the need for evidence, circumstances, and completion time. An action is not implemented. First, the envelope scope is re-validated. Success on external platforms is not guaranteed; completion It is recorded only according to the evidence received. 11. Approved digital exposure removal Approved exposure removal module (220) only if explicitly selected by the subject and envelope Public mentions, data-broker records, stale profiles, or equivalents included in the removal scope. Creates a removal authorization record (320) for exposure. The record has target registry, request type, identity. It may include data minimum, authorization timestamp, expiry, dispatch channel and lifecycle state. If a supported and operator-reviewed channel exists, the request must be bounded by the template or verified. Can be submitted via endpoint. CAPTCHA, free form, or legal assessment. The target requiring deletion is left in the assisted queue. The system only deletes the target after the target confirmation or This is confirmed by subsequent controlled re-observation. The result was actually deleted upon deletion request. It is not shown as the same state. 12. Monitoring and change detection Monitoring and change detection module (210), with the same protection envelope and versioned engine policy. It produces sequential monitoring snapshots (310). Snapshot canonical asset set, normalize findings, coverage, score contributions, breach / impersonation sentinels, and evaluation time It may include. 35 The system compares the previous and new snapshots with canonical keys to identify new, changed, resolved, and It still identifies clear evidence. Provider failure or coverage changes are not presented as new risks; It is reported as a separate incomplete / coverage event. The alert is only included in the entitlement and monitoring scope. If valid, it will be sent to the verified communication channel associated with the tenant. 13. Canonical reporting and grounded narrative Canonical reporting and grounded narrative module (230), executive summary, technical ledger, conditional attack pathways, score contributions, coverage / completeness, remediation plan, change trend, and service. It generates its boundaries from the same canonical data object. Free HTML sent by the client, It is not accepted as the source of the official PDF. When using a generative language model, only calculated and allowable canonical facts are fed to the model. Allow the model to generate findings, numbers, control status, asset ownership, or exploit results. It will not be given if the output is blank, excessively long, contains errors, or does not match canonical facts. The narrative reverts to a deterministic approach. The language model cannot change the numeric score or the finding state. 14. Audit, data minimization, and tenant limits. Tenant comprehensive audit module (240), authorization, verification, plan, lease, result acceptance, Tampering for remediation, removal, monitoring, and reporting events is linked to the previous event hash. It can hold things in an evident chain. In events, instead of clear name and contact information, opaque principal, subject, Tenant, grant, asset, job, and action identities are preferred. Raw challenge token, raw tool output, credential, breach secret, raw network config and unnecessary Personal data is not written to the permanent audit record. Tenant isolation data key, repository query, This is implemented at the queue claim, report retrieval, and monitoring schedule levels. (Deletion and retention) Operations are carried out according to the scope of the envelope / subject. 15. Example of combined personal protection. A user creates their own account and declares their name. Discovery engines public candidates. It finds; the user confirms what belongs to them and for social profile, mailbox or domain. The challenge is complete. The system binds verified assets to a protective envelope. Passive engines mail It gathers evidence of trust, breach, impersonation, and web-surface verification. Controlled technical validation is performed only. It operates with a verified target and a valid lease. The evidence graph separates signals into a conditional attack path. It converts; score and coverage are updated when owner recovery controls are added. User selects Provides removal scope for public mention. The next monitoring snapshot is the new lookalike domain. or reports the resolved DMARC finding as a separate change. 16. An example of combined corporate protection. An organization can have its invited managers and verified corporate domains in the same tenant. It binds to a protective envelope. The corporate network principal is the abstract environment profile. The system sends pseudonymous zones and trust links as authorized network contexts. 35 11 Identify evidence of person / brand impersonation, domain mail trust, and breach through corporate network controls. It is kept in the same tenant evidence graph but in different evidence classes. Network Assurance score, It produces confidence and completeness separately; topology design insights does not change the numeric score. The Attack-Path engine only traces paths based on shared subject / asset and permitted correlation rules. It creates a remediation plan, for example, DMARC enforcement, phishing-resistant MFA, DMZ. It links enforcement and monitoring actions to source evidence; the manager uses the PDF in the same canonical format. It is generated from the record. 17. Fail-closed operating principles The system has completed or cleared the evaluation in at least one of the following cases: does not show:  if the protection envelope, grant, verification, or invitation has expired or been cancelled;  If the principal, subject, tenant, scope, asset or context fingerprint do not match;  If the expected engine result is missing;  If there is a provider, parser, or worker failure;  If the worker lease is invalid, replayed, or belongs to a different worker;  If network control applicability or catalog version cannot be determined;  if the report does not match the canonical evidence version; or  If there is no explicit authorization for the removal / monitoring action. In these cases, the system generates a limited error / coverage log and informs the user of the unknown or incomplete error. It indicates the scope; it does not produce a clean result or a claim of successful protection. Industrial applicability The invention; personal digital identity protection, executive protection, family-office security, corporate attack protection. surface management, managed security service, vulnerability management, data-broker Removal, brand / impersonation protection, network security maturity assessment, security. It can be applied in reporting and continuous security monitoring systems.

Claims

12 REQUESTS 1. To assess the digital security exposure of an individual or organization and to implement protection measures. It is a computer-generated method for orchestration, characterized by: a) the process principal identity, protected subject identity, tenant identity, authorization basis, permitted transaction scopes, time limits, and at least one verified digital asset record or A protection that includes an authorized abstract network context ID and possesses an integrity fingerprint. a) the envelope is generated by the server; b) at least one discovery engine, passive security proof. engine, controlled technical verification engine, owner-attested verification engine, or corporate network the assurance engine's subject, tenant, scope, and entity / context type within the protection envelope. and selection by the server according to the time limit; c) the expected engine for each selected engine a scope that includes the ID, engine version, input class, resource budget, and complete result condition. d) the creation of the contract; canonical subject, entity or network context of engine outputs identity, source engine / version, observation status, observation time, reliability of evidence, protective envelope e) Converting evidence records into normalized evidence records including fingerprinting and coverage status. Normalized evidence records in tenant-wide canonical protection graph: subject, asset, with network-context, evidence, condition, impact, control and action nodes and provenance f) any of the expected engines being missing, failing or out of scope If it is outside of this, the evaluation in question is considered clean or complete. The separation of coverage, evidentiary reliability, and completeness of control from the consequences of blocking and security issues; g) observed by correlating normalized evidence connected with the same subject, tenant, and applicable scope evidence, attacker's intent / value, condition still necessary for the actual attack but not observed, potential impact, remediation control that breaks the chain, and information on the status where the attack was not executed. conditional attack path log and at least one technical protection check that intercepts that path It includes the steps involved in its production.

2. According to Claim 1, the method is self-verified, delegated, owner-attested, or the protective envelope is self-verified. one of the authorization bases for authorized-assessment; in the case of self-verified, the verification identity. and in the delegated case, it has been accepted by the invited principal, not cancelled and its term has expired. It includes an unfilled invitation ID.

3. The method is according to Claim 1, which is a DNS TXT challenge of a verified digital asset record, HTTP challenge, OAuth challenge, profile bio-token challenge, mailbox code challenge or repository It must be produced using at least one of the challenge methods; canonical asset value, owner principal, The verification method uses a fingerprint derived from proof of control instead of a raw token, and the duration is also a factor. It includes.

4. According to Claim 1, the method is that candidate entities found as a result of discovery are supported by demonstrable evidence. According to the classification, it is divided into one of the confirmed, probable, ambiguous, or excluded categories; only The candidate was not verified due to name similarity, URL accessibility, or predicted handle. 35 13 preventing entity counting and platform login, directory, search, group or post access. Their URLs are rejected as profile assets.

5. The method is as per Claim 1, and the source of each evidence edge in the canonical preservation graph is... engine, source ID, observation time, evidence state, confidence class, protective envelope It carries a fingerprint and canonical asset / context identity; conflicting evidence regarding provenance. They are protected and stored in separate containers.

6. The method is according to claim 1, and the passive security proof engine uses DNS for verified domains. SPF, DKIM, DMARC, MTA-STS, TLS-RPT, TLS, or lookalike domain; verified mailbox breach metadata; impersonation surface for verified profile; verified web presence bounded header or TLS for; MFA, recovery, session for owner-attested account or It must generate at least one of the connected-app controls.

7. The method according to Claim 1 is the canonical target for the controlled technical verification engine. verification fingerprint, grant / scope ID, authorized motors, precise executable paths, fixed an immutable set of argument vectors, time / output / finding budgets, and expiration time. The evaluation plan is created by the server.

8. The method is in accordance with Claim 7, and the tenant-wide assessment plan is an unchangeable work plan. kept in the queue; separate from the public application, the worker is tied to a worker ID, short-lived and Issued via a one-time lease; the lease token is in hash form at the control level. Lease, worker, target, envelope fingerprint and engine fingerprint before storage and acceptance of the result. It is a re-validation of its scope.

9. This method is based on request 7 or 8, where the worker is a non-root user, read-only root filesystem, Dropped capability, no new privileges, CPU / memory / PID limits, job-specific temporary work. Under egress limited by the area and canonical target; shell, user-assigned executable, without template, command, environment variable or free tool parameter The process involves running it to return a normalized finding or limited error code instead of the raw stdout / stderr.

10. The method according to claim 1 is the pseudonymous zone of the authorized abstract network context. The identities are categorized by zone type, criticality, internet accessibility, and allowlist-based enforcement types. It should include trust links; IP / CIDR, credentials, raw device configuration, packet capture, and free commands. or it rejects the exploit output as fail-closed.

11. The method is according to claim 10, and each method is based on the environmental profile of the enterprise network assurance engine. Determining the feasibility of the control; from the feasible and answered control weights Security score is the response rate of applicable controls, control completeness, and Separating the evidence confidence values ​​from the answered portion of the applicable risk weight. separate generation; unknown answer failed control without counting completeness and confidence It lowers their values. 35 14 12. A method according to claim 10 or 11, involving abstract topology or reported control vulnerabilities. The DMZ lacks boundaries, creating a weak path from the user zone to the critical zone, an OT / IT bridge, and user access. management plane access from the zone or internal / production zone directly open to the internet at least one of these situations is generated as a finding of deterministic design; unknown The answer is that no proven design flaw is generated from the responses.

13. The method is according to Claim 1, and the conditional attack path record contains the source evidence node IDs. carrying; unobserved credential compromise, session theft, recovery acceptance, recipient trust, network reachability, or equivalent attack prerequisites are required instead of observed evidence. It is recorded as a condition.

14. The method according to Claim 1, whereby the name of each positive or negative contribution to the combined security score is: the direction and point value being linked to canonical evidence or owner-attested control; coverage presenting a low score alone as a strong security case It is to prevent.

15. According to claim 1, the method is one in which the remediation or protection action is automated, user-controlled. categorized into one of the following classes: guided, operator-managed, or simply suggestion-based; completion the status is recorded only when verification evidence required by the action is received and the action Principal, subject, tenant, scope, fingerprint, and duration in the protection envelope before initiation. It is a re-verification of the information.

16. The method is as per Claim 1, whereby the digital exposure removal process is explicitly consented to by the subject. target registry, request type, minimum identity data, authorization timestamp, for the selected target Connecting to the removal authorization record containing expiry, dispatch channel, and lifecycle state; request The sending of the message and its deletion by the target are handled in different ways.

17. The method is according to Claim 1, and the monitoring snapshots are in the same protection envelope and versioned engine. It is produced in accordance with its policy; a new snapshot is created by using a canonical key between the previous and new snapshots. Identifying changing, resolved, and still open findings; new provider or coverage failures. The key is that it is not presented as a security finding and the coverage-failure situation is kept separate.

18. According to Claim 1, the method is that the managerial narrative is only considered in canonical evaluation. Deterministically based on the posture, score, coverage, findings, and remediation facts found. The generation of a numeric score or finding state of the model output when using a language model; The inability to change it and the return to a deterministic narrative in the event of model error.

19. The method according to Claim 1 is authorization, verification, plan, lease, result acceptance, Tampering for remediation, removal, monitoring, and reporting events based on the previous event hash. In the evident audit chain, opaque principal, subject, tenant, asset, job, and action identities. concealment; raw challenge token, credential, breach secret, raw tool output and raw network The problem is that the configuration file is not included in the audit log. 35 20. Computer-based digital protection structured to implement the method in Claim 1. the system includes principal, subject, tenant, scope of authority, time limit and verified target or Control verification that links the authorized network context under integrity fingerprinting, Authorization and Protection Envelope Module (120, 130), Target, Scope and Duration of the Envelope select a version assessment engine and engine scope agreement according to their areas The orchestration module accepts engine outputs from the source engine / version, canonical target, normalized by observation time, evidence status, confidence class, coverage status, and envelope fingerprint. evidence normalization module (180), normalize evidence tenant comprehensive canonical The graph module (140) storing the protection / evidence graph is missing the expected engine result, it failed. or scope that prevents the production of a clean or complete result when it is outside the scope. The verification module and the evidence linked in the same envelope reveal the attacker's objective. unobserved necessary condition, potential impact, situation where the attack is not executed, and the break in the chain. a risk and protection control module that generates a conditional attack path including technical control in separate areas It includes (190, 200).

21. When run by one or more processors, the requests of those processors range from 1 to... non-temporary commands that enable the execution of the method in any of the 19. It is computer-readable media.

Images