System for zero-trust cloud security with AI security analytics and cryptographic identity verification

Abstract

A system (100) for zero-trust cloud security with AI security analytics and cryptographic identity assurance, wherein the system (100) comprises: a policy enforcement module (1) configured to forward access requests to cloud resources; an identity assurance module (2) configured to establish the cryptographic identity of a user, device and / or workload; a policy decision module (3) configured to make an access decision based on one or more zero trust policies and contextual attributes; a telemetry acquisition module (4) configured to acquire security telemetry data from cloud resources and the policy enforcement module (1); a KL security analysis module (5) configured to analyze the collected telemetry data and generate a risk assessment and / or an anomaly indication; a cryptographic key management module (6) configured to generate, store, rotate, and use cryptographic keys for identity verification and session security; and an adaptive response orchestration module (7) configured to apply one or more risk-based control measures in the policy enforcement module (1), characterized in that the policy decision module (3) continuously updates the access decision during an active session using the risk assessment and / or anomaly indicator generated by the AI ​​security analysis module (5) and the cryptographic identity determined by the identity assurance module (2), thereby enabling continuous review and least privileged access in a cloud environment.

Description

INVENTION AREA

[0001] The present invention relates to cybersecurity for cloud computing environments, in particular a zero-trust security system that implements continuous monitoring, AI-based security analytics and cryptographic identity assurance for access control, threat detection and automated response in cloud infrastructures and cloud-native workloads. BACKGROUND OF THE INVENTION

[0002] The subject matter discussed in the "Background" section should not be considered prior art solely because it is mentioned in that section. Likewise, a problem mentioned in the "Background" section or related to the subject matter of the "Background" section should not be considered prior art. The subject matter in the "Background" section merely presents various approaches, which could themselves also be inventions.

[0003] Cloud computing has shifted enterprise IT from fixed, on-premises networks to highly distributed environments encompassing public clouds, private clouds, hybrid clouds, and multi-cloud deployments. In such environments, organizations run business-critical applications as a combination of virtual machines, containers, microservices, serverless functions, managed databases, object storage, API gateways, and SaaS platforms, often distributed across multiple regions and tenants. The number of identities involved has also increased dramatically—from purely human users to machines, devices, service accounts, workloads, and automated pipelines that continuously create, destroy, and modify resources. As a result, the cloud security boundary is no longer defined by a physical perimeter, but rather by identity, context, and policies.

[0004] Traditional perimeter-oriented security models were designed for static networks where most resources resided behind a controlled firewall and internal network traffic was implicitly considered trusted. In contrast, cloud architectures are dynamic: workloads scale automatically, services communicate across east-west traffic, remote access is the norm, and third-party integrations, APIs, and identity providers are deeply embedded. This creates a situation where "within the network" is not synonymous with trusted, and attackers frequently exploit valid credentials, stolen tokens, misconfigured access policies, exposed APIs, or compromised workloads to gain access and move laterally.Numerous security incidents arise not only from sophisticated malware, but also from common circumstances such as overprivileged roles, long-lasting access keys, token reuse, weak session control, misconfigured storage permissions, and insufficient segmentation.

[0005] Traditional access control approaches typically focus on a single authentication step at the beginning of a session (e.g., username / password, SSO, or MFA), after which the session can remain valid for extended periods even if the risk landscape changes. However, cloud threats evolve throughout a session's lifecycle: a user may initially authenticate legitimately but later exhibit anomalous behavior; a device may become non-compliant or compromised; a workload may deviate from its intended configuration; or tokens may be reused from a different location. Systems based on static authentication often fail to perform continuous verification (i.e., repeatedly reassessing trustworthiness throughout the session), a fundamental principle of zero-trust security.

[0006] Furthermore, cloud environments generate vast amounts of telemetry data, including control plane audit logs, API call logs, authentication events, network flows, container runtime events, endpoint signals, and application traces. While many organizations deploy SIEM or log aggregation tools, these tools often function more as afterthought monitoring systems than integrated, real-time decision engines. Common limitations include: (i) a lack of consistent normalization across heterogeneous telemetry sources, (ii) limited correlation between identity activity and workload behavior, (iii) delayed detection due to batch analysis or manual triage, and (iv) a lack of direct coupling between analysis results and enforcement mechanisms. Therefore, even when suspicious behavior is detected, manual intervention may still be required, increasing the dwell time and impact.

[0007] Another critical challenge is identity security and integrity in cloud access. Many access systems rely on bearer tokens or session cookies, which can be vulnerable to theft and reuse. Communication between services is often based on static secrets, and compromised keys can grant comprehensive access. Furthermore, even logs can be modified or selectively removed by attackers who gain access to privileged accounts, reducing the reliability of audit trails and complicating incident investigation. Therefore, there is a significant need for cryptographic identity security (including robust audits, device / workload attestation, and cryptographic binding of identity to sessions) and tamper-proof auditability to ensure the integrity and non-repudiation of security events.

[0008] Zero-trust security principles require that every access request be treated as untrusted by default and evaluated based on least privileges, explicit verification, and continuous risk assessment. Implementing such principles at cloud scale is difficult without an integrated architecture capable of (a) enforcing policies at access points, (b) evaluating contextual attributes and credentials, (c) continuously calculating risks through analytics, and (d) automatically applying adaptive response measures. Existing solutions may address some of these requirements—such as identity providers, endpoint compliance checks, security monitoring tools, or key management services—but they often remain fragmented and loosely coupled, leading to security gaps, inconsistent policy enforcement, and delayed containment.

[0009] Accordingly, there is a need for a unified system that integrates policy enforcement, policy-related decision-making, telemetry data collection, AI-driven security analytics, cryptographic identity assurance, key lifecycle management, and adaptive response orchestration into a continuous verification loop. Such a system should be able to update access decisions during active sessions based on changing risks, dynamically restrict permissions, isolate suspicious workloads through microsegmentation, revoke tokens and rotate keys when compromise is suspected, and create cryptographically sealed audit trails for compliance and forensic reliability.The present invention meets these requirements by providing a practical and implementable system for zero-trust cloud security with AI security analytics and cryptographic identity assurance.

[0010] The use of any examples or illustrative phrases (e.g., "such as") in relation to specific embodiments serves only to better illustrate the invention and does not constitute a limitation of the otherwise claimed scope of the invention. No wording in the description shall be construed as referring to an unclaimed element that is essential for carrying out the invention.

[0011] The information disclosed above in this "Background" section is provided solely for a better understanding of the background of the invention and may therefore contain information that is not part of the prior art already known to a person skilled in the art in this country. SUMMARY

[0012] Before describing the systems and methods presented here, it should be noted that this application is not limited to the specific systems and methods described, as there may be several possible embodiments not expressly presented in this disclosure. It should also be noted that the terminology used in the description serves only to describe the specific versions or embodiments and is not intended to limit the scope of this application.

[0013] In one embodiment, the present invention provides a system (100) comprising: a policy enforcement module (1) for mediating and enforcing access to cloud resources; an identity assurance module (2) for establishing the cryptographic identity of a user / device / workload; a policy decision module (3) for making access decisions based on zero-trust policies and contextual attributes; a telemetry data acquisition module (4) for acquiring and normalizing security telemetry data; an AI security analytics module (5) for generating risk assessments and anomaly indicators; a cryptographic key management module (6) for generating and managing keys used for identity assurance and session security; and an adaptive response orchestration module (7) for implementing automated risk-based control measures.

[0014] Characterized by the fact that access decisions during an active session are continuously updated based on AI-derived risk signals and cryptographic identity verification, enabling continuous review, minimum permissions, and automated responses in cloud environments. BRIEF DESCRIPTION OF THE DRAWING

[0015] To clarify various aspects of some embodiments of the present invention, a more detailed description of the invention is given with reference to specific embodiments shown in the accompanying drawing. It is understood that this drawing represents only illustrative embodiments of the invention and is therefore not to be considered a limitation of its scope. The invention is described and explained with additional specificity and detail using the accompanying drawing.

[0016] To make the advantages of the present invention easily understandable, a detailed description of the invention is given below in conjunction with the accompanying drawing, which, however, should not be regarded as limiting the scope of the invention to the accompanying drawing, in which: Fig. shows a block diagram of the system (100) for zero-trust cloud security with AI security analysis and cryptographic identity protection. DETAILED DESCRIPTION

[0017] The present invention relates to the system (100) for zero-trust cloud security with AI security analysis and cryptographic identity protection.

[0018] Fig. shows a detailed block diagram of the system (100) for zero-trust cloud security with AI security analysis and cryptographic identity protection.

[0019] Although the implementations of the invention have been described in language specifically relating to structural features and / or methods, it should be noted that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations of the invention.

[0020] The present invention provides a system (100) for implementing zero-trust cloud security by combining policy-driven access control, continuous verification, AI-based security analytics, and cryptographic identity assurance. The system (100) can be deployed as a centralized cloud security control layer and / or as a distributed set of enforcement components integrated into cloud gateways, service meshes, workload runtimes, endpoint agents, and identity providers. In operation, the system (100) treats each access request as untrusted by default and continuously assesses trustworthiness throughout the session based on real-time signals collected from cloud resources and entities, thereby preventing or limiting unauthorized access, lateral movement, and privilege abuse.

[0021] With reference to Fig.1 The system (100) includes a policy enforcement module (1), an identity assurance module (2), a policy decision module (3), a telemetry data collection module (4), a AI security analysis module (5), a cryptographic key management module (6), and an adaptive response orchestration module (7).These modules work together in a closed control loop, where the policy enforcement module (1) intercepts and forwards access requests, the identity assurance module (2) generates cryptographic identity trust and authentication status values, the policy decision module (3) evaluates access based on policies and context, the telemetry collection module (4) collects and normalizes security telemetry data, the AI ​​security analytics module (5) calculates risk assessments and anomaly indicators, the cryptographic key management module (6) supports cryptographic evidence and secure sessions, and the adaptive response orchestration module (7) applies adaptive actions based on risks and policies.

[0022] The policy enforcement module (1) is configured as one or more enforcement points located in the access path between an entity and a cloud resource. In various implementations, the policy enforcement module (1) is deployed as an API gateway plug-in, reverse proxy, service mesh sidecar, identity-aware proxy, cloud access security broker component, host-based agent, container ingress controller, or as a workload-to-workload enforcement control point.The policy enforcement module (1) is configured to intercept incoming requests, extract session metadata and context attributes, validate token formats and cryptographic assertions, request authorization decisions from the policy decision module (3), and enforce the resulting decision in real time, including allow / deny results and restriction-based results such as step-up authentication, throttling, session expiration, and micro-segmentation rules.

[0023] In a preferred embodiment, the policy enforcement module (1) maintains a session state for each access session, including session identifiers, token freshness values, the last timestamp of the policy evaluation, applied restrictions, and a dynamic session risk level. The policy enforcement module (1) periodically or event-drivenly checks session permissions by querying the policy decision module (3) during the session duration. Therefore, even after initial authentication, the system (100) can change access rights during the session, for example, from "Allow" to "Stepwise Authentication" or "Deny," if new telemetry data indicates an increased risk. This continuous review mechanism prevents long-lasting sessions from continuing to be considered trusted after compromise signals have been detected.

[0024] The identity assurance module (2) is configured to establish the cryptographic identity of at least one user, device, or workload. The identity assurance module (2) performs identity verification and cryptographically binds the identity to a session using challenge-response mechanisms, signed assertions, and cryptographic credentials. In one embodiment, the module (2) issues or validates a signed identity token that is bound to the device state and / or workload attestation, enabling repetition from a different device / workload context. The identity assurance module (2) outputs an identity assurance status, which includes a security score, a confidence level, and optionally an attestation validity indicator, to the policy decision module (3).

[0025] In one embodiment, the identity security module (2) supports multifactor authentication and dynamic step-up authentication. For example, a low-risk request might require a standard authentication factor, while a high-risk request might require additional factors such as cryptographic proof of possession, a device-bound factor, a biometric factor, or out-of-band confirmation. The identity security module (2) enables the adaptive response orchestration module (7) and / or the policy decision module (3) to trigger enhanced authentication, ensuring that stronger authentication is applied only when the risk justifies it, while maintaining usability for normal operation.

[0026] The identity assurance module (2) is further configured to verify the device state by evaluating compliance attributes such as operating system version, patch status, presence of endpoint protection, disk encryption status, secure boot status, jailbreak / root detection, configuration compliance, and the presence of unauthorized software. In a secure embodiment, the module (2) validates integrity evidence, which includes hardware-based or trusted measurements, such as TPM citations, secure enclave reports, or measured boot logs from the device, to ensure that the device has not been tampered with. Such device state and integrity signals can be used as contextual inputs to determine whether the cryptographic identity is trusted for the requested access.

[0027] For workloads such as containers, microservices, VMs, or serverless functions, the identity assurance module (2) is configured to verify workload identity by checking workload certificates, signed workload identity tokens, or service identities. Additionally, the module (2) verifies workload attestation by validating container image signatures, checking immutable deployment manifests, confirming runtime health signals, and optionally verifying enclave attestation or trusted execution credentials. This ensures that a workload requesting service-to-service access is not forged or unauthorized and operates within approved configurations.

[0028] The policy decision module (3) is configured to make access decisions based on zero-trust policies expressed as attribute-based rules, role-based conditions, and risk-based conditional logic. The policy decision module (3) uses the identity verification results received from module (2), the risk assessments and anomaly signals received from module (5), the telemetry context received from module (4), and static or dynamic attributes such as user role, resource sensitivity, time of day, geolocation, device state, workload identity, network zone classification, and historical behavior patterns. The policy decision module (3) outputs a decision that includes allow / deny results and, optionally, restriction instructions such as enhanced authentication requirements, reduced-scope token issuance, restricted API operations, or restricted data access.

[0029] Unlike conventional authorization modules that perform an evaluation only once at login, the policy decision module (3) continuously re-evaluates authorization during an active session based on updated telemetry and risk signals. In one embodiment, module (3) maintains a policy evaluation cache with a short decision time-to-live (TTL) and triggers a re-evaluation of the authorization when new anomalies occur, such as impossible journeys, abnormal API bursts, privilege escalation attempts, suspicious lateral movements, or indicators of data exfiltration. The updated decision is then transmitted to module (1) so that the policy enforcement module (1) can promptly enforce the updated access restrictions.

[0030] The telemetry collection module (4) is configured to collect, ingest, and normalize security telemetry data from multiple sources, including cloud control plane logs, audit logs, API call logs, authentication logs, network flows, service mesh traces, endpoint signals, container runtime events, and policy enforcement events generated by module (1). The telemetry collection module (4) standardizes event formats into normalized records, adds metadata tags such as identity ID, workload ID, resource ID, timestamp, region, tenant, and sensitivity tag, and correlates events across sessions. In one embodiment, module (4) assigns correlation identifiers to link access request records to subsequent resource operations, thereby enabling the traceability of session behavior.

[0031] In one embodiment, the telemetry acquisition module (4) transforms normalized telemetry data into AI-enabled features. For example, it calculates derived features such as API request rate, percentage of failed logins, indicator of new devices, geo-drift distance, number of unusual resource accesses, abnormal data transfer volume, privilege escalation frequency, and changes in the service-to-service diagram. These features are provided to the AI ​​security analysis module (5) to enable timely and accurate detection of suspicious behavior.

[0032] The AI ​​security analysis module (5) is configured to analyze telemetry data and generate a quantitative risk assessment and / or a qualitative anomaly indicator. In one embodiment, the module (5) maintains baseline behavior profiles per identity and per workload by learning normal activity patterns such as typical login periods, typical working hours, normal API call distributions, normal data access patterns, normal communication diagrams of services, and typical resource consumption behavior. When new telemetry data deviates from the baseline beyond predefined thresholds, the module (5) issues anomaly indicators, assigns a risk assessment, and optionally provides explanatory tags describing the reason for the increased risk.

[0033] In a preferred embodiment, the AI ​​security analysis module (5) performs a correlation between identity, device, workload, and resource activity using graph-based modeling. For example, identities can be linked to devices, workloads, and resources via edges representing access events. Suspicious patterns such as unusual new edges, strong fan-out behavior, repeated rejected attempts, token mismatch patterns, or abrupt changes in east-west communication can be detected. This correlation enables the detection of multi-stage attacks that are not visible through isolated rule checks.

[0034] In one embodiment, the AI ​​security analysis module (5) updates the baseline values ​​over time, applying drift controls to reduce the risk of attacker poisoning. The module (5) uses configurable thresholds for risk levels such as low, medium, high, and critical. Additionally, the module (5) outputs explainability indicators such as "new country registration," "suspected token retaking," "abnormal API bursts," "patterns of privilege escalation," or "unusual data access," thereby justifying downstream decisions and responses for compliance and investigation purposes.

[0035] The cryptographic key management module (6) is configured to generate, store, rotate, and use cryptographic keys that support identity assurance, token signing, mutual authentication, and telemetry sealing. In one embodiment, the module (6) provides keys per identity, keys per workload, and derived keys per session. The module (6) can be integrated into hardware-based security solutions such as HSMs, TPM-backed keystores, or trusted execution environments. The keys are rotated regularly and can also be rotated immediately following a risk escalation at the instruction of the adaptive response orchestration module (7).

[0036] In one embodiment, the cryptographic key management module (6) signs access tokens and workload identity tokens, enabling the policy enforcement module (1) to verify their authenticity and integrity. Furthermore, the module (6) facilitates mutual authentication, such as mutual TLS, between workloads by issuing and managing short-lived certificates. In another embodiment, tokens are bound to proofs of ownership, so that a stolen token cannot be successfully used without the corresponding private key, thereby reducing token replay and session hijacking attacks.

[0037] In one embodiment, the cryptographic key management module (6) supports the creation of tamper-proof audit trails by digitally signing telemetry batches and / or applying hash chaining to event sequences. This ensures that security protocols, access decisions, and response measures cannot be altered without detection. Such cryptographic sealing strengthens compliance readiness and provides reliable evidence for forensic investigations and non-repudiation.

[0038] The adaptive response orchestration module (7) is configured to automatically apply response measures based on risk assessments, anomaly indicators, and policy decisions. In one embodiment, the module (7) uses playbooks that define sequences of containment and escalation steps. For example, if the risk assessment exceeds a threshold, the module (7) triggers enhanced authentication via module (2), reduces privileges via module (3), and enforces isolation or throttling via module (1). In severe cases, the module (7) revokes tokens, terminates sessions, quarantines workloads, and triggers key rotation via module (6).

[0039] The adaptive response orchestration module (7) is integrated with the policy enforcement module (1) to propagate immediate enforcement updates, such as changes to micro-segmentation rules, rejection policies for specific identities, or API throttling restrictions. Module (7) is also integrated with the policy decision module (3) to update policy parameters, for example, to temporarily apply stricter policies to a workload group during an incident. Module (7) can also generate alerts and incident tickets for administrators, including risk statements received from module (5), enabling rapid triage and resolution.

[0040] A key inventive aspect of the system (100) is a closed-loop continuous review system in which the telemetry acquisition module (4) continuously acquires signals, the AI ​​security analysis module (5) continuously generates risk assessments, the policy decision module (3) continuously updates authorization decisions, and the policy enforcement module (1) enforces updated decisions in real time. Within this loop, the identity assurance module (2) and the cryptographic key management module (6) provide cryptographic evidence and secure session primitives, while the adaptive response orchestration module (7) applies automated containment measures, thereby reducing exposure windows and limiting the attacker's dwell time.

[0041] In an exemplary embodiment, the policy enforcement module (1) intercepts the request when a user attempts to access a sensitive cloud API and requests identity verification from module (2), which checks multi-factor authentication and device health. The telemetry data collection module (4) provides contextual information, including the current API usage history, while the AI ​​security analytics module (5) detects an unusual spike in API calls from a new location and generates a high-risk score. The policy decision module (3) returns a decision regarding enhanced authentication with restricted privileges. If enhanced authentication fails, the adaptive response orchestration module (7) revokes the session token and triggers key rotation via module (6), and the policy enforcement module (1) blocks further requests.

[0042] In another exemplary embodiment, a workload attempts to access an unrelated database service. The identity assurance module (2) evaluates the workload attestation and detects inconsistencies with the expected runtime integrity evidence. The AI ​​security analysis module (5) correlates new service-to-service communication edges that indicate lateral movement. The policy decision module (3) issues rejection and isolation instructions, and the adaptive response orchestration module (7) updates the microsegmentation rules enforced by the policy enforcement module (1) to isolate the workload from east-west traffic and thus prevent further propagation.

[0043] The system (100) can be implemented as software, firmware, hardware, or a combination thereof. Modules (1) to (7) can be centralized, distributed, containerized, and / or deployed as managed services. Policies can be configured via management interfaces and stored in policy repositories accessible to module (3). AI models can be regularly updated and adapted to the specific organization. The cryptographic functions can be implemented using standard algorithms and protocols and can be integrated into existing enterprise key management infrastructures without deviating from the scope of the invention.

Images