> ## Documentation Index > Fetch the complete documentation index at: https://docs.plerion.com/llms.txt > Use this file to discover all available pages before exploring further. # How GCP workload scanning works > The snapshot-to-scan mechanics, identity model, and cleanup guarantees behind GCP workload scanning Workload scanning is agentless: Plerion never installs anything on a workload you're scanning. Instead, it works from a **snapshot** of the workload's disk, scans that copy in a dedicated scanning project inside your own Google Cloud organization, and deletes everything it created once the scan finishes. This page covers the mechanics behind that: the flow, the identities involved, and what happens to encrypted disks. *** ## The scan flow Every step below runs as Plerion's existing tenant service account, using the same keyless [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) chain the GCP organization integration already uses for posture scanning. No new credential type or long-lived key is introduced. Plerion creates a snapshot of the VM's disk in place, in the same project and region the VM lives in. Since this is a snapshot, it doesn't pause, slow, or otherwise touch the running workload. It's a crash-consistent copy taken out of band from the running workload. Plerion creates a new disk from that snapshot inside the **scanning project**: the same region, a different project, still inside your organization. The disk is sized to match the source disk automatically. A short-lived scanner VM boots in the scanning project from a stock public Ubuntu LTS image, with the pinned scanning toolchain installed at boot. The scan disk is attached to it read-only. The scanner VM mounts the disk and runs the scan locally: vulnerabilities, SBOM, and (if enabled) sensitive data. Nothing about this step calls back to any GCP API. The scanner VM uploads scan results directly to Plerion over an authenticated, time-limited upload link. Only findings, never disk contents, leave your organization. Plerion deletes the scan disk, the scanner VM, and the original snapshot. A backstop sweeper checks for and removes anything left behind by an interrupted scan, so nothing Plerion created outlives its scan. A scan is bounded by a hard 120-minute timeout: if a scan hasn't finished by then, Plerion tears it down and marks it failed rather than leaving resources running indefinitely. *** ## Where everything lives Both the snapshot and the scan disk stay inside your Google Cloud organization at every step: same region as the source disk, different project. Nothing is copied to a Plerion-owned project or account. The scanning project itself is created once, during onboarding, and reused for every scan afterward. *** ## The identity model Two identities are involved, and they're deliberately unequal in what they can do: * **The tenant service account** drives every GCP API call in the flow above: snapshotting, creating the scan disk, booting and deleting the scanner VM. It's reached only through Plerion's existing per-tenant WIF chain, which you can revoke at any time by deleting the workload identity pool in your Plerion service project. * **The scanner VM** runs under its own dedicated service account that holds **no IAM roles at all**. The VM never calls a GCP API directly. Plerion hands it a mounted disk and a short-lived, single-purpose upload token at boot, and that token only authorizes uploading scan results. If a scanner VM were ever compromised, an attacker would get the contents of one scan disk and a token that can only upload results (nothing that reaches your broader GCP environment). Because the scanning project is yours, you can inspect a running scanner VM in your own console at any time. None of the compute Plerion runs there is hidden from you. *** ## Encrypted disks * **Customer-managed encryption keys (CMEK)**: the snapshot inherits the source disk's key, but the **scan disk created in the scanning project uses Google-managed encryption instead of your key**: Plerion doesn't need, and isn't granted, access to your CMEK key to create it. This is a deliberate trade: the disk is short-lived, stays inside your organization, and is deleted once the scan finishes, but its encryption during that window is Google-managed rather than customer-managed. This behavior is disclosed here and in the KMS access step of onboarding. * **CSEK (customer-supplied encryption keys)**: Plerion has no way to supply your key at snapshot or disk-creation time, so CSEK-encrypted disks can't be scanned. See [Coverage](/guides/integrations/gcp/workload-scanning/coverage) for how this and other gaps are surfaced. *** ## No-trace cleanup, backed by a sweeper Every resource Plerion creates for a scan (snapshot, scan disk, scanner VM) is named with a `plerion-scan-` prefix and labeled with the owning tenant, integration, and execution. Normal cleanup runs at the end of every scan; a separate, scheduled sweeper independently lists anything matching that naming and label pattern and removes it if it's older than expected, so an interrupted scan (a killed execution, a Plerion-side outage) never leaves orphaned resources behind indefinitely. Because everything lives in your own scanning project, you can also see and delete any leftover resource yourself at any time. *** ## Next steps * [Access and permissions](/guides/integrations/gcp/workload-scanning/access-and-permissions) * [Coverage](/guides/integrations/gcp/workload-scanning/coverage)