Cloud security, CNAPP, AI-SPM, compliance, and connector questions answered

Cyscale is a CNAPP platform for cloud security posture, cloud vulnerability management, identity and entitlement context, Kubernetes security, compliance automation, data security, and AI Security Posture Management. The platform connects cloud assets, users, workloads, code, containers, findings, controls, and ownership in the Security Knowledge Graph so teams can prioritize the risks that matter.

A standalone CSPM usually focuses on misconfigurations and compliance checks. Cyscale includes CSPM, but also correlates those findings with vulnerabilities, identities, Kubernetes workloads, data exposure, AI assets, ownership, and remediation workflow. That broader context helps teams fix attack paths instead of only closing isolated checks.

No. Cyscale is designed to become the cloud security operating layer for posture, exposure, compliance, and remediation. It complements SIEM, EDR, ticketing, runtime protection, and source control tools by adding cloud context, ownership, prioritization, and evidence that those tools usually do not maintain on their own.

Cyscale supports AWS, Microsoft Azure, Google Cloud, Alibaba Cloud, Kubernetes, Microsoft Entra ID, Google Workspace, Okta, GitHub, and GitLab workflows. Coverage keeps expanding as cloud and AI services evolve, especially around provider-native AI assets and Kubernetes-hosted AI workloads.

The Security Knowledge Graph is the relationship model behind Cyscale. It connects assets, identities, permissions, findings, vulnerabilities, data stores, compliance controls, alerts, AI services, and owners. This lets Cyscale answer practical questions such as which exposed asset can reach sensitive data, which role can access a model endpoint, or which vulnerability affects a production workload.

Yes. Cyscale is built around ownership-ready findings, alert assignment, triage state, remediation guidance, and reporting. Security, cloud, engineering, compliance, and AI teams can use the same evidence while continuing to work through their established operational process.

AI-SPM means AI Security Posture Management. In Cyscale it focuses on discovering AI services and workloads, building AI inventory and AI BOM context, mapping models, agents, endpoints, datasets, vector stores, identities, and public paths, then prioritizing AI risks such as public endpoints, broad model access, weak guardrails, leaked keys, and excessive tool permissions.

Shadow AI is AI usage that security or governance teams do not yet control. It can be a managed AI service, model endpoint, AI SDK, notebook, SaaS AI feature, browser extension, Kubernetes workload, or internal agent that processes business data without the expected approval, ownership, monitoring, or data handling controls.

AI Discovery & Inventory answers where AI exists, who owns it, which provider or workload hosts it, and whether it is approved. AI BOM answers what the AI system is made of: models, frameworks, packages, datasets, vector stores, prompts, tools, agents, endpoints, and runtime dependencies. Inventory finds the AI estate; AI BOM explains its components and security impact.

Cyscale is adding cloud AI coverage across AWS, Azure, Google Cloud, and Kubernetes. Examples include Amazon Bedrock, SageMaker, Lambda AI workloads, Vertex AI, Azure Machine Learning, Azure OpenAI, Microsoft Foundry-related Azure AI resources, AI Search, AI services, model endpoints, feature stores, vector stores, agent-like workloads, and Kubernetes pods or services that run AI frameworks, model servers, or inference APIs.

Yes, some AI coverage needs provider permissions that older connectors did not request. Cyscale surfaces an update-permissions notice when an account should update AWS IAM policies, Azure roles or app registrations, or Google Cloud roles such as Vertex AI viewer permissions. The goal is to make the extra access explicit and auditable.

No. Runtime guardrails inspect prompt, output, model behavior, and abuse patterns. Cyscale AI-SPM provides the posture layer: what AI exists, how it is configured, what it can access, which identities and tools it uses, which data paths are exposed, and which findings should be remediated first.

Yes. AI Security is designed as an enabled module that can be controlled by account or plan. When it is disabled, the AI Security UI, AI connector permission notice, AI-specific billing module display, and AI-only sync behavior should not be exposed to that account.

Cyscale prioritizes vulnerabilities by combining CVSS and exploit signals with real cloud context: internet exposure, reachable identities, affected workloads, asset criticality, sensitive data access, compliance impact, and whether the asset is part of a production path.

Yes. Kubernetes coverage uses the Cyscale Kubernetes agent to inventory cluster resources, workloads, container images, packages, and contextual relationships. This helps teams understand whether a vulnerable image is actually running, exposed, privileged, or connected to sensitive services.

Yes. Cyscale can use provider-native signals such as AWS Inspector, ECR scanning, Google Artifact Analysis, cloud workload metadata, and Kubernetes SBOM or package data. The value comes from correlating these findings with the rest of the cloud graph rather than treating scanner output as a flat list.

Code-to-cloud visibility connects repositories, dependencies, images, workloads, cloud assets, identities, and findings. It helps teams determine whether a vulnerable library or misconfiguration in code affects a live asset and who should own the fix.

Yes. Cyscale supports workflows around leaked secrets, outdated and end-of-life software, dependency risk, container image findings, and the cloud or runtime assets affected by those issues.

Most cloud onboarding is agentless and uses secure provider APIs. AWS, Azure, Google Cloud, Alibaba Cloud, identity providers, and source control integrations can be connected without deploying workload agents. Kubernetes visibility uses a Kubernetes agent because cluster-level runtime inventory and package context require in-cluster collection.

Cyscale requests read-oriented permissions for inventory, posture, identity, vulnerability, compliance, data, and AI Security coverage. For AI Security, additional provider-specific read permissions may be needed for services such as Bedrock, SageMaker, Vertex AI, Azure AI services, Azure OpenAI, AI Search, and Azure Machine Learning.

Yes. Cyscale supports organization-style onboarding where available, such as AWS Organizations and Google Cloud organization or folder structures. This helps teams avoid one-off account onboarding and keeps multi-account visibility easier to operate.

Yes. Scoping can be controlled by connector, cloud account, organization unit, project, subscription, region, provider, asset type, and application context depending on the environment and connector type. This helps large teams align Cyscale visibility with ownership and data boundaries.

When permissions are updated, Cyscale can resync the connector so new asset types, services, and relationships are discovered. The UI can guide users through permission updates, show provider-specific instructions, and trigger a sync after the user confirms the cloud-side changes.

Cyscale stores the installed Kubernetes agent version and can compare it with the latest available chart or image version. This helps teams know when cluster agents should be upgraded without making the UI fetch external version metadata on every page load.

Cyscale maps cloud and security controls to frameworks such as ISO 27001, SOC 2, PCI DSS, NIST, CIS Benchmarks, NIS 2, DORA, and cloud-provider best practices. The catalogue also supports newer policy coverage such as AI Best Practices for AI Security programs.

Yes. Cyscale supports custom policies and controls through query-based logic and configuration workflows. Teams can write controls that reflect their own cloud standards, security rules, and governance requirements instead of relying only on built-in frameworks.

AI Security controls cover issues such as public AI endpoints, broad model access, unencrypted training data, weak guardrail configuration, unrestricted agent tool permissions, risky data paths, missing ownership, and unsupported or vulnerable AI runtime components. These can be mapped to the AI Best Practices framework.

Yes. Exemptions are part of governance workflows when a finding is accepted, temporarily tolerated, or not applicable. Good exemption handling should preserve who approved it, why it exists, when it expires, and which control or asset it affects.

Yes. Cyscale continuously collects evidence from connected environments and maps it to controls, policies, and frameworks. This reduces manual evidence collection and helps compliance teams explain current posture with live cloud context.

Billable asset logic depends on the configured plan and the modules enabled for the account. Cyscale tracks configured connectors, users, sync activity, frameworks, policies, and resource usage so customers can understand what the account is using.

Enabled modules are product capabilities attached to an account or plan, such as Data Security, AI Security, and future Code Security expansion. This lets Cyscale show only the features a customer has purchased or that are intentionally enabled for evaluation.

Cyscale supports marketplace-led onboarding workflows such as Azure Marketplace subscription data and plan mapping. The long-term model is to connect plan codes, enabled modules, usage, and billing automation cleanly.

Cyscale primarily reads cloud configuration, metadata, asset relationships, identity information, security findings, package metadata, and compliance-relevant evidence. It does not need to read customer application data or object contents to provide posture and exposure analysis in normal operation.

Customers can use Cyscale documentation, in-product guidance, support channels, and demo or security review sessions. For account-specific permissions, billing, marketplace, or compliance questions, support can help validate the safest path before changes are applied.