Changelog - Plerion, Simplify Cloud Security

Lambda Web Functions are now in your inventory: Plerion collects AWS Lambda Web Functions, the new Lambda type that runs an HTTP server behind an HTTPS endpoint. Each web function shows its endpoints with their authentication type and domain name, the revisions those endpoints send traffic to, the execution role of each revision, its resource policy and its tags. See the supported AWS resources →

Global CBPR mapping refreshed: Plerion refreshed the mapping for the Global Cross-Border Privacy Rules (CBPR) System Program Requirements, September 2025 edition, so its 7 mapped requirements draw on more checks across AWS, Azure, GCP, and Kubernetes, such as backups, encryption, public and external exposure, audit logging, vulnerabilities, secrets, and alerting. Checks that can’t fail or don’t match a requirement were removed, and the requirement on safeguards scaled to the sensitivity of the information now uses only data discovery and classification checks. The framework is off by default; if you’ve turned it on, expect posture for these requirements to change on the next scan. Learn more →
Send findings and audit logs to Sumo Logic: A new Sumo Logic integration posts to a Sumo Logic HTTP Source. Add it as an action on a workflow to send the findings it selects each night as they open, change and resolve, with every open finding resent once a week. Tick Send tenant audit logs to send the tenant’s audit logs as they happen, and use Sync now on the integration to send changes straight away. Learn more in the platform docs →

APEC Cross-Border Privacy Rules requirements are now available: Plerion now maps your cloud posture to the APEC Cross-Border Privacy Rules (CBPR) System Program Requirements, updated as of November 2019, a separate framework from the Global CBPR requirements. Six of its 73 requirements, covering security and information-system safeguards, safeguards scaled to the sensitivity of the information, detecting and responding to attacks, and testing that safeguards work, map to detections across AWS, Azure, GCP, and Kubernetes; the other 67 are privacy and governance practices, such as notices, consent, and access requests, which show as not applicable. The framework is off by default, so turn it on from Compliance under Manage frameworks. Learn more →

Agent Registry check follows Agent Registry to its new home: AWS moved Agent Registry out of Bedrock AgentCore into a service of its own, with new registries, and shuts the old API down on 30 October 2026. Plerion now collects registries from the new service, and the check for registries that publish new records without review reads them. A registry fails when its auto-approval rules include APPROVE_ALL, and the fix step in the check description now says to remove that rule. Registries created in AgentCore before 6 August are no longer checked, and their open findings resolve. Plerion reads the new registries once your Plerion stack has the agent-registry read permissions, which the latest stack version adds.

[PLERION-AWS-1110] Agent registry publishes new records without review (now runs on registries in the new Agent Registry service; was AgentCore registry publishes new records without review)

Clearer wording on three AgentCore checks: The titles and finding messages for AgentCore harnesses, browsers and code interpreters now say the resource runs outside a VPC and has direct internet access, matching the AgentCore runtime check. The checks themselves are unchanged, so your findings stay the same.

[PLERION-AWS-1082] AgentCore harness runs outside a VPC and has direct internet access
[PLERION-AWS-1090] AgentCore browser runs outside a VPC and has direct internet access
[PLERION-AWS-1091] AgentCore code interpreter runs outside a VPC and has direct internet access

Route 53 failover that can actually fail over: A new check finds hosted zones whose failover records have no health check. Route 53 treats such a record as always healthy, so a primary without one keeps receiving traffic when its endpoint is down. Each finding names the records to fix, and an alias failover record with Evaluate target health turned on passes, because it takes its health from its target. Zones without failover routing are not evaluated.

[PLERION-AWS-1242] Route 53 hosted zone has a failover record without a health check (new, Medium)

It answers REL 11 in the Reliability pillar of Well-Architected workloads.

Room to grow, checked before you run out: A new check finds AWS service quotas that are 80% or more used in a region, so you can raise them before a scale-out or a failover hits the limit. It covers four quotas to start: EC2 On-Demand Standard vCPUs, Elastic IPs, VPCs per Region and Lambda concurrent executions. Usage is the 24-hour peak of the quota’s CloudWatch usage metric, and for Elastic IPs the number of addresses allocated. Plerion now also collects these service quotas as assets. Reading the usage metrics adds less than $0.001 of CloudWatch charges to each AWS account per scan.

[PLERION-AWS-1243] AWS service quota usage is at or above 80% (new, Medium)

It answers REL 1 in the Reliability pillar of Well-Architected workloads.

More Multi-AZ checks on live resources: One check that only ran on your infrastructure-as-code templates now also runs against your AWS accounts, and two new checks join it. PLERION-AWS-220 finds Auto Scaling groups behind a load balancer that ignore the load balancer’s health checks, so an instance the load balancer has marked unhealthy keeps its place in the group. The new checks find EKS managed node groups whose subnets all sit in one Availability Zone, and OpenSearch domains with zone awareness turned off. In both, a single zone outage takes out every node. Expect new findings on the first scan from all three.

[PLERION-AWS-220] Auto Scaling group behind a load balancer does not use load balancer health checks (now also runs on live Auto Scaling groups; groups with no load balancer or target group attached are skipped)
[PLERION-AWS-1244] EKS managed node group uses subnets in a single Availability Zone (new, Low)
[PLERION-AWS-1245] OpenSearch domain does not have zone awareness enabled (new, Low)

PLERION-AWS-220 answers REL 7, REL 10 and REL 11, and the two new checks answer REL 10, in the Reliability pillar of Well-Architected workloads.

S3 replication, checked on live buckets: PLERION-AWS-611 only ran on your infrastructure-as-code templates and now also runs against your AWS accounts, at Low severity. A bucket passes when an enabled replication rule sends objects to a bucket in another region; same-region replication fails, and a destination bucket in another account passes. Expect new findings on the first scan: most buckets replicate nowhere, so most will fail.

[PLERION-AWS-611] S3 bucket does not replicate to another region (now also runs on live buckets; severity Medium to Low)

It answers REL 9 and REL 10 in the Reliability pillar of Well-Architected workloads.

Sharper Reliability answers in Well-Architected workloads: If you use AutoFill, your Reliability pillar answers will change. We took out 33 retired checks and 15 security checks with no bearing on reliability, such as IMDSv2 on Auto Scaling groups. We added 39 live checks where they answer a Reliability question: backups for RDS, Aurora, DocumentDB, Neptune, ElastiCache, OpenSearch and Redshift, snapshot encryption and sharing, RDS Multi-AZ, DynamoDB global tables, CloudFront origin failover, VPN tunnel redundancy and SQS dead-letter queues. Eight of the 13 Reliability questions now have checks behind them, and AutoFill picks up the change on its next daily run. Learn more →
Deletion protection, checked on live resources: Two checks that only ran on your infrastructure-as-code templates now also run against your AWS accounts, and two new checks join them. Each one finds a resource that a single delete or terminate call can remove for good. Expect new findings on the first scan: across Plerion today, about 37% of RDS clusters and 82% of load balancers have no deletion protection.

[PLERION-AWS-311] RDS cluster does not have deletion protection enabled (now also runs on live clusters)
[PLERION-AWS-614] Load balancer does not have deletion protection enabled (now also runs on live Application, Network and Gateway Load Balancers)
[PLERION-AWS-1197] RDS DB instance does not have deletion protection enabled (new; instances in a cluster are covered by the cluster check)
[PLERION-AWS-1198] EC2 instance does not have termination protection enabled (new; Spot instances and instances in Auto Scaling groups are skipped)

All four answer REL 9 or REL 11 in the Reliability pillar of Well-Architected workloads.

Multi-AZ resilience, checked on live resources: Three checks that only ran on your infrastructure-as-code templates now also run against your AWS accounts, and two new checks join them. Each one finds a resource that a single Availability Zone outage can take down or overload. Two titles change to name the right load balancer: PLERION-AWS-280 now covers Network and Gateway Load Balancers, and PLERION-AWS-607 covers Classic Load Balancers. Plerion now also collects ElastiCache replication groups and NAT gateways. Expect new findings on the first scan: across Plerion today, about 61% of Network and Gateway Load Balancers, 27% of Classic Load Balancers and 51% of Auto Scaling groups would fail.

[PLERION-AWS-744] ElastiCache replication group does not have Multi-AZ with automatic failover enabled (now also runs on live replication groups)
[PLERION-AWS-280] Network or Gateway Load Balancer does not have cross-zone load balancing enabled (now also runs on live load balancers; Application Load Balancers are skipped)
[PLERION-AWS-607] Classic Load Balancer does not have cross-zone load balancing enabled (now also runs on live load balancers)
[PLERION-AWS-1199] Auto Scaling group uses a single Availability Zone (new; the Auto Scaling groups of Plerion’s own scanning appliance are skipped)
[PLERION-AWS-1200] VPC routes a subnet through a NAT gateway in another Availability Zone (new; regional NAT gateways pass, and VPCs without a NAT gateway are skipped)

All five answer REL 10 in the Reliability pillar of Well-Architected workloads, and PLERION-AWS-744 also answers REL 11.

Code interpreters and browsers that hold AWS credentials: Two new checks flag Amazon Bedrock AgentCore code interpreters and browsers that run with an IAM execution role. Any code an interpreter runs can get that role’s credentials, so a code injection flaw in your agent or its SDK, like those fixed in version 1.18.1 of the bedrock-agentcore Python SDK’s install_packages() helper, gives an attacker AWS access with that role’s permissions. A browser with a role carries the same risk through a forged request or a malicious page. Expect a Low finding for each custom interpreter or browser that has a role.

[PLERION-AWS-1201] AgentCore code interpreter runs with an IAM execution role (new; the AWS-provided interpreter is skipped)
[PLERION-AWS-1202] AgentCore browser runs with an IAM execution role (new; the AWS-provided browser is skipped)

AgentCore resources inherit their execution role’s risk: Your AgentCore runtimes, gateways, harnesses, code interpreters, browsers, memories, online evaluation configurations, payment managers and consent portals now get the same role checks as Lambda functions and EC2 instances. A finding on the resource says when its execution role has admin privileges, has overly permissive privileges, or can add an inline policy to itself. The asset carries the matching flag, so you can filter AgentCore assets by admin privileges, overly permissive privileges and privilege escalation. Code interpreters, browsers, online evaluation configurations, payment managers and consent portals also gain a Permissions tab that shows the role. Runtime, harness and code interpreter roles are rated Medium for admin. Memory, online evaluation, payment manager and consent portal findings are informational.

View all 27 checks

[PLERION-AWS-1211] AgentCore runtime execution role has admin privileges (new, Medium)
[PLERION-AWS-1212] AgentCore runtime execution role has overly permissive privileges (new, Low)
[PLERION-AWS-1213] AgentCore gateway execution role has admin privileges (new, Low)
[PLERION-AWS-1214] AgentCore gateway execution role has overly permissive privileges (new, Informational)
[PLERION-AWS-1215] AgentCore harness execution role has admin privileges (new, Medium)
[PLERION-AWS-1216] AgentCore harness execution role has overly permissive privileges (new, Low)
[PLERION-AWS-1217] AgentCore code interpreter execution role has admin privileges (new, Medium)
[PLERION-AWS-1218] AgentCore code interpreter execution role has overly permissive privileges (new, Low)
[PLERION-AWS-1219] AgentCore browser execution role has admin privileges (new, Low)
[PLERION-AWS-1220] AgentCore browser execution role has overly permissive privileges (new, Informational)
[PLERION-AWS-1221] AgentCore memory execution role has admin privileges (new, Informational)
[PLERION-AWS-1222] AgentCore memory execution role has overly permissive privileges (new, Informational)
[PLERION-AWS-1223] AgentCore online evaluation configuration execution role has admin privileges (new, Informational)
[PLERION-AWS-1224] AgentCore online evaluation configuration execution role has overly permissive privileges (new, Informational)
[PLERION-AWS-1225] AgentCore payment manager execution role has admin privileges (new, Informational)
[PLERION-AWS-1226] AgentCore payment manager execution role has overly permissive privileges (new, Informational)
[PLERION-AWS-1227] AgentCore consent portal execution role has admin privileges (new, Informational)
[PLERION-AWS-1228] AgentCore consent portal execution role has overly permissive privileges (new, Informational)
[PLERION-AWS-1229] AgentCore runtime execution role can escalate its own privileges (new, Medium)
[PLERION-AWS-1230] AgentCore gateway execution role can escalate its own privileges (new, Low)
[PLERION-AWS-1231] AgentCore harness execution role can escalate its own privileges (new, Medium)
[PLERION-AWS-1232] AgentCore code interpreter execution role can escalate its own privileges (new, Medium)
[PLERION-AWS-1233] AgentCore browser execution role can escalate its own privileges (new, Low)
[PLERION-AWS-1234] AgentCore memory execution role can escalate its own privileges (new, Informational)
[PLERION-AWS-1235] AgentCore online evaluation configuration execution role can escalate its own privileges (new, Informational)
[PLERION-AWS-1236] AgentCore payment manager execution role can escalate its own privileges (new, Informational)
[PLERION-AWS-1237] AgentCore consent portal execution role can escalate its own privileges (new, Informational)

A trail record of who used your agents: Four new checks find AgentCore runtimes, gateways, code interpreters and memories that no CloudTrail trail logs data events for. The calls that invoke an agent, send it tool requests, run its code and read or write its memory are data events, which a trail records only when an advanced event selector asks for them. A resource passes when a trail of the same account, either multi-region or homed in the resource’s region, selects data events for its type, and any resources.ARN filter on that selector includes the resource. Organization trails managed from another account are not counted. Expect a Low finding for each of these resources that no trail logs.

[PLERION-AWS-1238] CloudTrail does not log data events for AgentCore runtimes (new; a selector for runtime endpoints alone does not count)
[PLERION-AWS-1239] CloudTrail does not log data events for AgentCore gateways (new)
[PLERION-AWS-1240] CloudTrail does not log data events for AgentCore code interpreters (new; the AWS-provided interpreter is skipped)
[PLERION-AWS-1241] CloudTrail does not log data events for AgentCore memories (new)

Global Cross-Border Privacy Rules requirements are now available: Plerion now maps your cloud posture to the Global Cross-Border Privacy Rules (CBPR) System Program Requirements, in the edition the Global CBPR Forum updated in September 2025, which applies to certifications and recertifications from April 1, 2027. Seven of its 80 requirements, covering security safeguards, protections for sensitive personal information, preventing and responding to attacks, and testing that safeguards work, map to detections across AWS, Azure, GCP, and Kubernetes; the other 73 are privacy and governance practices, such as notices, consent, and access requests, which show as not applicable. The framework is off by default, so turn it on from Compliance under Manage frameworks when you start preparing. Learn more →
Clearer wording on an AgentCore runtime check: The title and finding message now say the runtime runs outside a VPC and has direct internet access. The check itself is unchanged, so your findings stay the same.

[PLERION-AWS-1084] AgentCore runtime runs outside a VPC and has direct internet access

Backups and disaster recovery, checked on live resources: One check that only ran on your infrastructure-as-code templates now also runs against your AWS accounts, and four new checks join it. Each one finds data with a single copy, a short restore window, or backups that anyone with delete permission can remove. Plerion now also collects AWS Backup plans. Expect new findings on the first scan: across Plerion today, about 78% of RDS clusters are not in an AWS Backup plan, 37% of RDS clusters and 25% of standalone RDS instances keep automated backups for fewer than 7 days, and 84% of Backup vaults that hold recovery points have no Vault Lock.

[PLERION-AWS-720] RDS cluster is not in an AWS Backup plan (now also runs on live clusters; a cluster passes once AWS Backup has completed a backup of it)
[PLERION-AWS-1203] RDS DB instance keeps automated backups for fewer than 7 days (new; instances in a cluster and read replicas are skipped)
[PLERION-AWS-1204] RDS cluster keeps automated backups for fewer than 7 days (new)
[PLERION-AWS-1205] AWS Backup plan does not copy recovery points to another region (new; AWS-managed plans are skipped)
[PLERION-AWS-1206] AWS Backup vault holding recovery points does not have Vault Lock enabled (new; empty vaults and AWS-managed vaults are skipped)

All five answer REL 9 in the Reliability pillar of Well-Architected workloads, and PLERION-AWS-1205 also answers REL 10.

Auckland joins the map: Plerion now supports the Asia Pacific (New Zealand) region, ap-southeast-6. Once you enable the region in your AWS account, Plerion scans its workloads and you can launch your Plerion stacks there. See supported regions →

Seventeen SageMaker privilege escalation checks are removed: Each of these checks looked for one thing: a SageMaker resource whose execution role can use iam:PutRolePolicy to write a policy onto itself. [PLERION-AWS-1013] already reports that permission on the IAM role, along with the other ways a role can escalate its own access, so these checks added a second finding for the same role. They no longer run, and they are no longer listed in the AWS Generative AI Lens, ISO/IEC 42001, NIST AI RMF, OWASP LLM and Agentic Top 10 and AWS MSP Validation Checklist frameworks. Each of those framework controls still maps to its other checks.

View all 17 checks

[PLERION-AWS-996] SageMaker pipeline allows privilege escalation
[PLERION-AWS-997] SageMaker algorithm allows privilege escalation
[PLERION-AWS-998] SageMaker AutoML job allows privilege escalation
[PLERION-AWS-999] SageMaker cluster allows privilege escalation
[PLERION-AWS-1000] SageMaker domain allows privilege escalation
[PLERION-AWS-1001] SageMaker earth observation job allows privilege escalation
[PLERION-AWS-1002] SageMaker endpoint config allows privilege escalation
[PLERION-AWS-1003] SageMaker hyperparameter tuning job allows privilege escalation
[PLERION-AWS-1004] SageMaker image allows privilege escalation
[PLERION-AWS-1005] SageMaker MLflow tracking server allows privilege escalation
[PLERION-AWS-1006] SageMaker model package allows privilege escalation
[PLERION-AWS-1007] SageMaker model allows privilege escalation
[PLERION-AWS-1008] SageMaker notebook instance allows privilege escalation
[PLERION-AWS-1009] SageMaker processing job allows privilege escalation
[PLERION-AWS-1010] SageMaker training job allows privilege escalation
[PLERION-AWS-1011] SageMaker user profile allows privilege escalation
[PLERION-AWS-1012] SageMaker vector enrichment job allows privilege escalation

Follow your AI agents to everything they touch: Agent security is a new inventory of the AI agents in your AWS accounts, covering Amazon Bedrock AgentCore runtimes and harnesses and Amazon Bedrock Agents Classic agents. Start at an agent and click through to its gateways, tools, memory and guardrails, and the IAM role it runs as. Plerion scans the container images and code your AgentCore runtimes run, so you can see how an agent could be compromised: vulnerabilities attackers can exploit and secrets left in the image. It also raises findings for risky configuration, such as a gateway anyone can call without credentials or a memory open to any AWS account. This is the very first version, and it will get a lot better. Learn more →
See what your KMS keys hide from Plerion: When a customer managed KMS key stops Plerion reading part of an Amazon Bedrock or AgentCore resource, the asset page now says so and names the key. You choose whether to let Plerion read it. Learn more →

Preferences and dashboards over the API: Set a user’s or a user group’s home dashboard and sidebar navigation, set the tenant default home dashboard, and list custom dashboards with an API key. Learn more →

Know which vulnerabilities are likely to be exploited: Vulnerabilities now carry their Exploit Prediction Scoring System (EPSS) score, the chance of exploitation in the next 30 days, published daily by FIRST. See it as a percentage on the Vulnerabilities dashboard and code security issues, filter and sort by it, use it in workflow and exemption rule conditions, and find it in alerts, tickets, CSV downloads, the customer API and the CLI. A vulnerability gets its score at its asset’s next scan. Learn more in the platform docs →
AgentCore memory findings are rated by what a stranger can reach: [PLERION-AWS-1195] AgentCore memory is publicly accessible now checks every read action an open policy allows. A finding is High when anyone can read the stored text with the memory’s ARN alone, Medium when they also need a record or session ID, and Low when only user and session IDs are open. Some existing findings will drop from High to Medium or Low on the next scan.

Say hello to a new AgentCore check: [PLERION-AWS-1195] AgentCore memory is publicly accessible. A Bedrock AgentCore memory holds what an agent remembers between sessions. A resource policy that lets any AWS account call it can let a stranger read it, add events the agent later trusts, or delete records. Plerion checks each such memory live from an unrelated AWS account, using requests that are always denied and so never touch your data, and raises the finding only when that check proves a stranger gets through the policy. A policy closed by a condition or a deny statement passes, and so does one the live check cannot settle. Findings are High severity.

Threat mapping covers AI: Pick the new MITRE ATLAS AI Framework next to the ATT&CK Cloud and Containers matrices. On an asset, the Mitre attack tab is now Threat mapping and has the same matrix picker.
Fill in any Jira field: A workflow’s Jira action can now set almost any field on your project’s create screen, including Priority, Labels, Components, Assignee, custom selects and the Jira Service Management Organizations field, from a Plerion field or a fixed value. Map each severity to a Jira priority, send extra fields as custom JSON, and click Send test issue to see the result in Jira before you save. Learn more in the platform docs →
More of your identity setup in the inventory: Plerion now collects Amazon Cognito user pools and identity pools, IAM Identity Center instances, permission sets, users and groups, IAM OIDC and SAML identity providers, IAM Roles Anywhere trust anchors and profiles, Amazon Verified Permissions policy stores and AWS Directory Service directories. Cognito user pools carry their app clients, identity providers, domains, MFA settings and Lambda triggers; identity pools show whether guests get credentials and which roles they receive; permission sets carry their policies and the accounts they are assigned in. IAM users now list their SSH public keys, signing certificates and MFA devices, and KMS keys list their grants. Identity Center is read in your management or delegated administrator account. Everything shows up in the inventory after your next scan.
Choose whether to scan AgentCore runtimes: Amazon Bedrock AgentCore Runtime is now its own workload type next to AWS Lambda, in onboarding and in integration and service account settings. Existing integrations start with it set the same as their Lambda setting.

AgentCore runtimes get workload scanning: Amazon Bedrock AgentCore runtimes that run a container image are now scanned for vulnerabilities, sensitive data and an SBOM, with the results on the runtime’s asset page. Runtimes are scanned whenever Lambda scanning is on for the integration.
Say hello to ten new AWS checks for the image an AgentCore runtime runs:

[PLERION-AWS-1185] AgentCore runtime image has low severity vulnerabilities
[PLERION-AWS-1186] AgentCore runtime image has medium severity vulnerabilities
[PLERION-AWS-1187] AgentCore runtime image has high severity vulnerabilities
[PLERION-AWS-1188] AgentCore runtime image has critical severity vulnerabilities
[PLERION-AWS-1189] AgentCore runtime image exposes low severity secrets
[PLERION-AWS-1190] AgentCore runtime image exposes medium severity secrets
[PLERION-AWS-1191] AgentCore runtime image exposes high severity secrets
[PLERION-AWS-1192] AgentCore runtime image exposes critical severity secrets
[PLERION-AWS-1193] AgentCore runtime image has exploitable vulnerabilities
[PLERION-AWS-1194] AgentCore runtime image has known exploited vulnerabilities

AgentCore runtimes deployed from a code zip can be scanned too: turn on Bucket ABAC for the bucket that holds the zip and tag it PlerionAccess: Granted, and Plerion scans the code like a Lambda function. Plerion reads no bucket you have not shared. Until the bucket is shared, the runtime’s page says it was not scanned and names the bucket. See how to share a code bucket →

Azure workload scanning covers every workload family: Vulnerability, sensitive data and SBOM scanning now reaches App Service web apps, Virtual Machine Scale Sets, Container Apps, Container Instances and Batch pools, alongside the virtual machines and functions it already scanned; Service Fabric node types are covered through their scale sets. Scale sets are sampled by image, one member per distinct image, including Uniform-orchestration sets. Turn each type on under the subscription’s workload scanning settings; a publicly exposed workload with high or critical vulnerabilities also gets an attack path finding ([PLERION-AZURE-446]). Container images in your Azure Container Registries are pulled with the appliance identity, which the install script now grants AcrPull. AKS and Azure Red Hat OpenShift clusters are covered by the Kubernetes integration, and OpenShift, Service Fabric and Batch resources now appear in the inventory. See what is scanned and how →
Say hello to eight new Azure checks: exploitable and known-exploited vulnerabilities in the images your container workloads and Batch pools run, and in the application packages your Batch accounts hold.

[PLERION-AZURE-452] Container App has exploitable vulnerabilities
[PLERION-AZURE-453] Container App has known exploited vulnerabilities
[PLERION-AZURE-454] Container Instance has exploitable vulnerabilities
[PLERION-AZURE-455] Container Instance has known exploited vulnerabilities
[PLERION-AZURE-459] Batch pool image has exploitable vulnerabilities
[PLERION-AZURE-460] Batch pool image has known exploited vulnerabilities
[PLERION-AZURE-461] Batch application package has exploitable vulnerabilities
[PLERION-AZURE-462] Batch application package has known exploited vulnerabilities

Azure Batch application packages are scanned: turn on Batch accounts under workload scanning and the appliance reads each active application package from the account’s linked storage account, unpacks it and scans it for vulnerabilities, secrets and an SBOM, with findings on the account. The install script grants the appliance identity Storage Blob Data Reader on those storage accounts; run it again after adding a Batch account.
Azure virtual machine data disks are scanned: after the OS disk, each managed data disk is copied, scanned and removed in turn, so packages and secrets on data volumes now count. A data disk that cannot be copied is reported as a warning on the scan.
Web apps and function apps that run a custom container are scanned by image: a site whose runtime stack is DOCKER|<image> has that image pulled and scanned, the same way Container Apps are, instead of a code download that finds nothing.
OpenShift platform images scan through the cluster’s own credentials: give the collector chart the cluster pull secret (collector.registry.pullSecrets: [openshift-config/pull-secret]) and it pulls through the cluster’s image mirror sets, so the platform’s images on quay.io/openshift-release-dev scan alongside your own. The chart also runs under OpenShift’s restricted security context, so no extra grant is needed. Available in collector chart v1.2.9. Learn more →
The Entitlements Analyzer and the asset Access tab have been retired: The Entitlements Analyzer and the Access tab on asset pages are no longer available in Plerion. We’re building a better way to answer your identity questions, such as who can reach a resource and what an identity is allowed to do.

Tag an integration in Plerion: Integration groups can now use tags you define on an integration in Plerion, alongside the tags on your AWS accounts. Open an integration’s settings page, find the new Tags section, and add a key and value; keys already used on your other integrations are offered as you type. A tag defined in Plerion replaces the AWS account tag with the same key, and groups using that key update within seconds. Tagging your accounts in AWS Organizations is still the best route, since Plerion keeps those in sync on every scan; this is for when that isn’t an option. You can also set these tags through the API, and every integration returned by the API now carries its tags with where each one came from. Learn more →
Say hello to a new S3 check: [PLERION-AWS-1182] S3 bucket default encryption does not use a customer-managed KMS key. Until now this control only ran against infrastructure code, so an account scan said nothing about it. The check passes a bucket whose default encryption is aws:kms or aws:kms:dsse under a key you own, which it confirms by resolving the key id, alias or ARN against the keys in the account. It fails a bucket on AES256, one with no default encryption configuration, and one on SSE-KMS under a key AWS manages — including the console’s “AWS managed key (aws/s3)”, which is stored as that key’s ARN. It is Medium severity. Expect a lot of findings: every bucket left on the S3 default produces one.
Say hello to a new S3 check: [PLERION-AWS-1181] S3 Multi-Region Access Point does not block public access. It reads the access point’s own Block Public Access setting and passes only when all four of its flags are on; a missing setting fails. Until now nothing looked at it, so an access point created without the block went unreported. Medium severity, and you can expect one finding per Multi-Region Access Point that does not block public access on the first scan. The setting is fixed when the access point is created, so clearing the finding means replacing the access point rather than editing it.
SCIM provisioning has no switch: Point your identity provider at the SCIM base URL under Admin > Security > Single sign-on > SCIM provisioning and authenticate it with a readWrite organization API key. Learn more →
Just-in-time provisioning stands on its own: Create users at first sign-in alone decides whether a sign-in may create a user. SCIM has no effect on it.
S3 cross-account access findings are now High: [PLERION-AWS-532] moves from Medium to High severity, separately from the message fix listed on 22 September. A bucket policy or an ACL that grants another account is the same exposure our external-access checks report, and this check rated how likely that is lower than they do; now it matches them. Every open finding on the check moves from Medium to High on your next scan, and no bucket’s result changes. The check is also filed under data at risk, access control and cross-account, replacing a placeholder category.
Manage roles over the API: Create roles and grant or revoke them for users and user groups with an organization API key. Learn more →
Buckets on locked-down keys now pass: [PLERION-AWS-1182] reported nothing for a bucket encrypted with a customer-managed key whose key policy does not let IAM grant access, because such a key refuses Plerion’s request to describe it. It now tells whose key it is from the key’s alias, since AWS reserves the alias/aws/ prefix for the keys it manages, so those buckets pass. No failing finding changes.

Two S3 findings now say what they mean: The result messages on these checks contradicted the result itself, and both are corrected. No verdict and no severity changed; what changed is the sentence you read on a finding you already have.

[PLERION-AWS-532] The pass and fail messages were the wrong way round. A bucket that grants access to another account now reads “Amazon S3 bucket allows cross-account access”, and one that does not reads “Amazon S3 bucket does not allow cross-account access”.
[PLERION-AWS-462] Both results carried the same sentence, so a bucket in no backup plan read as protected. A failing bucket now reads “Amazon S3 bucket is not added in the backup plan of AWS Backup”.

Redirect-only website buckets now read as website buckets: [PLERION-AWS-875] decided website hosting on the index document alone, so a bucket that redirects every request to another host — the usual www-to-apex setup — was reported as not hosting a website. It now reads the redirect rule as well. No finding appears or disappears, and the S3 bucket risk score picks up the corrected fact on the next scan.
Thirty-one S3 checks now explain themselves: Each of these shipped a description that was empty or wrong, so opening a finding on one showed you a title and little else. They now say what the check looks at, which setting it reads, and why that setting matters. Eight titles are corrected along with them. No verdict, severity or finding count changes.

View all 31 checks

[PLERION-AWS-22] S3 bucket has unsupported default server-side encryption algorithm
[PLERION-AWS-24] S3 bucket does not have versioning and MFA Delete enabled
[PLERION-AWS-31] S3 bucket for CloudTrail is publicly accessible
[PLERION-AWS-39] S3 bucket does not have object-level read data events logging enabled in CloudTrail
[PLERION-AWS-140] S3 bucket is publicly accessible
[PLERION-AWS-458] Ensure Amazon S3 block public access account settings are enabled
[PLERION-AWS-459] Ensure Amazon S3 buckets have versioning enabled
[PLERION-AWS-462] Ensure Amazon S3 buckets are protected by a backup plan
[PLERION-AWS-475] Ensure Amazon S3 bucket ACLs do not grant READ permission to everyone
[PLERION-AWS-484] Ensure Amazon S3 bucket has block public ACLs (BlockPublicAcls) enabled
[PLERION-AWS-488] Ensure Amazon S3 bucket ACLs do not grant WRITE permission to everyone
[PLERION-AWS-532] Ensure Amazon S3 buckets do not have cross-account access
[PLERION-AWS-546] Ensure AWS S3 buckets storing CloudTrail trails are configured to use Object Lock
[PLERION-AWS-577] Ensure Amazon S3 bucket ACLs do not grant READ permission to Authenticated Users group
[PLERION-AWS-578] Ensure Amazon S3 bucket ACLs do not grant WRITE permission to Authenticated Users group
[PLERION-AWS-585] Ensure Amazon S3 bucket does not allow an action with any Principal
[PLERION-AWS-592] Ensure Amazon S3 bucket policy does not lock out all but root user
[PLERION-AWS-610] Ensure Amazon S3 bucket has lock configuration enabled by default
[PLERION-AWS-611] Ensure Amazon S3 bucket has cross-region replication enabled
[PLERION-AWS-612] Ensure that Amazon S3 buckets are encrypted using AWS Key Management Service (KMS) by default
[PLERION-AWS-625] Ensure Amazon S3 object copy is encrypted using KMS CMKs
[PLERION-AWS-630] Ensure Amazon S3 bucket objects are encrypted using KMS CMKs
[PLERION-AWS-739] Ensure Amazon S3 buckets do not allow access to all authenticated users
[PLERION-AWS-804] Ensure Amazon CloudFront distributions do not point to non-existent S3 origins
[PLERION-AWS-854] Ensure Amazon S3 buckets have access logging enabled
[PLERION-AWS-871] Ensure bucket’s ACL does not allow listing objects
[PLERION-AWS-872] Ensure bucket’s policy does not allow listing objects
[PLERION-AWS-873] Ensure bucket is not empty
[PLERION-AWS-874] How guessable is S3 bucket name?
[PLERION-AWS-875] Is S3 bucket in website hosting mode?
[PLERION-AWS-876] What encryption is the S3 bucket using?

An Object Lock setting Plerion cannot read is no longer a fail: [PLERION-AWS-546] failed any CloudTrail log bucket whose Object Lock setting Plerion could not read, most often because the read was denied, giving it the same result as a bucket with no Object Lock at all. The check now fails only a bucket that genuinely has no Object Lock configuration, and a bucket whose setting it cannot read produces no finding either way. Findings raised on a setting that could not be read clear on the next full scan. In Plerion’s own development accounts 3 buckets in 123 are unreadable this way, so most findings on this check are unchanged.
Say hello to a new S3 check: [PLERION-AWS-1180] S3 access point accepts requests from the public internet instead of a VPC. Create one without a VPC configuration and it gets NetworkOrigin: Internet, so it accepts requests over the public S3 endpoint like the bucket itself does. Every request through it still clears the access point policy, the bucket policy, and IAM, so it’s about where the entry point sits, not who’s let in. The check fails an access point with NetworkOrigin: Internet and passes one with NetworkOrigin: VPC, at Low severity. Internet is the default, so expect findings on most existing access points on the first scan after release. The network origin can’t be changed after creation, so clearing a finding means creating a new VPC-origin access point and removing the old one.

API keys now hold a role: Every tenant API key has a role, so a key does only what its role allows, on the integrations the role covers. Existing keys keep Tenant admin, so nothing changes until you pick a different role. Choose Tenant read-only or a custom role when you create a key, or change an existing key’s role from the API keys list, and the page shows what the key can call. A key can ask the same question itself by making a request to GET /v1/tenant/openapi, which returns the API reference limited to that key. Learn more →
Infrastructure as code (IaC) scan uploads have their own permission: POST /v1/tenant/shiftleft/iac/scan needs CodeRepository:RequestScan. Tenant admin has it. A custom role can add it as Request code scans under Manage integrations.
Say hello to a new Redshift check: [PLERION-AWS-329] Redshift cluster does not have enhanced VPC routing enabled. With enhanced VPC routing off, COPY and UNLOAD traffic between a cluster and S3 leaves over the public AWS network where no security group, network ACL, endpoint policy or VPC Flow Log sees it. The check fails a cluster whose EnhancedVpcRouting setting is off and passes one where it is on. It is High severity, runs on your next scan, and maps to AWS Foundational Security Best Practices Redshift.7, CIS Controls v8, NIST 800-53 and the other frameworks that already list this control.
Say hello to a new AWS Security Hub check: [PLERION-AWS-1177] Security Hub AI Security Best Practices standard is not enabled. The AI Security Best Practices standard adds 31 automated Security Hub controls for Amazon Bedrock, Amazon Bedrock AgentCore, and Amazon SageMaker workloads. The check runs once per region and passes when the region’s subscription to the standard is READY; a region with Security Hub off, no subscription, or a subscription in any other state fails. It is Medium severity and maps to the AWS Well-Architected Machine Learning Lens and Generative AI Lens. Expect one finding for each region where the standard isn’t enabled yet; once the standard reports ready, the next scan closes the finding. Learn more →
Plerion check update: Application Load Balancers that send their access logs to CloudWatch Logs now pass this check. Until now it only recognized logs written to an S3 bucket, so a load balancer using the newer CloudWatch Logs delivery was flagged for logging it already had. The check is retitled to match its peers and its finding message now names the load balancer.

[PLERION-AWS-791] Application Load Balancer does not have access logging enabled

Say hello to a new Kinesis check: [PLERION-AWS-1176] Kinesis channel is encrypted with an AWS-owned key. Kinesis Data Streams now has channels, which deliver stream records straight into an S3 bucket or into S3 Tables without a Firehose in between. A channel that names no KMS key of your own leaves the delivered objects under a key you neither control nor see used. Plerion collects channels as a new asset type and checks each one. A channel’s encryption cannot be changed after it is created, so clearing this finding means replacing the channel with one that sets a customer-managed key.
Say hello to a new AWS Organizations check: [PLERION-AWS-1178] AWS organization does not prevent member accounts from leaving or closing themselves. A member account that can call organizations:LeaveOrganization or account:CloseAccount can walk out from under every guardrail, or close itself and take its logs with it. The check reads every service control policy attached to the organization root, its organizational units, and its accounts, and passes only when each active member account is covered by an unconditional Deny of both actions. AWS attaches such a policy to organizations created from the console after 10 July 2026; older organizations, and those created through the API or CloudFormation, need one added by hand. Expect one High finding per organization that lacks it, on the first scan after this release.
Say hello to a new CloudTrail check: [PLERION-AWS-1179] CloudTrail trail does not log network activity events for VPC endpoints. Network activity events record the API calls made through your VPC endpoints, including the ones an endpoint policy denied, which is where an attempt to move data out through an endpoint shows up. AWS now lets a selector filter those events by userIdentity, so a trail can log only the denied calls from identities outside a list you trust, at a fraction of the cost of logging everything. The check passes an account where at least one of its own trails has an advanced event selector with eventCategory equal to NetworkActivity, and fails the account otherwise; an organization trail managed from another account is not counted. Expect one High finding per AWS account on the first scan after this release, since almost no account logs these events yet.
S3 server access logs delivered to CloudWatch Logs now count as logging: S3 can deliver a bucket’s server access logs to CloudWatch Logs, and mirror them to S3 Tables, instead of a general purpose bucket. Two checks now pass a bucket logged either way. Findings on CloudTrail log buckets whose access logs go to CloudWatch Logs clear on the next scan; buckets logged to another bucket are unchanged. Both checks also get condition-present titles.

[PLERION-AWS-34] S3 bucket for CloudTrail does not have server access logging enabled (was “Ensure S3 buckets storing AWS CloudTrail logs have access logging enabled”)
[PLERION-AWS-333] S3 bucket does not have server access logging enabled (was “Ensure Amazon S3 buckets have server access logging enabled”); in Terraform and CloudFormation scans an aws_cloudwatch_log_delivery_source or AWS::Logs::DeliverySource of type S3_SERVER_ACCESS_LOGS that references the bucket now satisfies it. Seeing that delivery source means reading the whole template, so this check now runs as a template-wide check: S3 buckets declared inside a Serverless Framework serverless.yml are no longer evaluated by it, while CloudFormation and Terraform files are.

Custom reports are now custom dashboards, and you can assign one as a homepage: Build a dashboard in Settings > Custom dashboards, click Assign as homepage, and pick the users and user groups who should land on it when they sign in. Learn more →
Add a ready-made widget or build your own: Add widget opens a panel of ready-made widgets, and Build your own instead opens the Show me, Broken down by and Shown as fields. The title is generated from your answers until you type over it. Learn more →
Pick your own home dashboard: Profile > Home dashboard sets the dashboard you land on. It overrides any dashboard assigned to you, and clearing it restores the assignment.

Onboard with Terraform and scan in a service account you own: Terraform onboarding now offers all three ways to run workload scanning, including a service account you own and Plerion operates. Scanning stays inside your organization, and the accounts being scanned run no appliances of their own. Learn more →
Set the service account up with Terraform as well: Two templates provision it. One grants the access Plerion needs, and one runs for each region you scan in, building the appliance network, the pool that grows and shrinks with the scan queue, and the key their snapshots are encrypted with. Both register with Plerion while terraform apply runs, so there is nothing to paste back into the console. Learn more →
Connect your AI client to Plerion over MCP: The Plerion MCP server gives Claude, Cursor, VS Code, Windsurf, Zed, and Kiro CLI a tool for each Public API operation, plus pleri_chat for questions in plain language. The tool list is built from the operations your own account may call, so a role change takes effect on the next request. Learn more →

SCIM provisioning: Okta, Microsoft Entra ID, or any SCIM 2.0 identity provider can now create, update, and deactivate Plerion users. Existing users with a matching email address are adopted rather than duplicated, and how they sign in does not change. Learn more →
User groups: Grant roles to a group and every member holds them. Groups can be synced from your identity provider over SCIM or created in Plerion. Learn more →
Organization API keys: API keys scoped to the whole organization, with read or readWrite access. Your identity provider uses one for SCIM provisioning. Learn more →
Break-glass admins: Organization admins who can always sign in with a password and cannot be deactivated by your identity provider. At least one is required while single sign-on or SCIM is enabled. Learn more →

Google Cloud workload security: Plerion now scans what runs inside your GCP workloads: Compute Engine instances, managed instance groups, and custom images, plus Cloud Run services and Cloud Functions (1st and 2nd gen), for vulnerabilities, software bill of materials, and secrets left behind. Every scan runs in a scanning project inside your own organization. Learn more → Access stays keyless through workload identity federation (WIF). Access and permissions →

The Kubernetes collector manager runs on arm64: The collector manager image is now published for amd64 and arm64, so it runs on Graviton node pools without adding an x86 node just for Plerion. It ships as a multi-architecture image, so each node pulls the variant it needs and a cluster running both needs no nodeSelector. Learn more →
Integration groups for your AWS accounts: Choose the AWS Organizations tag keys that matter to you in Settings > Integration groups, and every value becomes a group whose membership keeps up as accounts are tagged, retagged, and onboarded. Then filter by integration group across the platform, from findings and assets to dashboards, reports, and workflows. Learn more →

Vulnerability auto-triage (experimental): Plerion can now lower the severity of vulnerabilities whose weakness type limits the harm they can cause. Ten rules cover cases like kernel CVEs found in container images, weaknesses MITRE records as only ever exhausting memory, and faults that need physical access to the hardware. Depending on the estate, 45% to 66% of Critical and High findings move to a lower severity. Nothing is hidden or deleted, the advisory severity is kept, and each change is explained on the finding. Enable it per profile. Learn more →

Kubernetes identities now carry privilege context: Ask which identities in your estate can escalate to administrator and the answer now includes Kubernetes alongside AWS. Plerion tags Kubernetes service accounts, nodes, workloads, and the role bindings that grant them with administrator privileges, susceptible to privilege escalation, and overly permissive privileges, so they appear in the same asset filters, risk scores, notification rules, and workflow conditions your cloud assets already use. Learn more →
Identities carry the privileges they hold: A Deployment running as an administrator service account is an administrator, and so is the account itself. Plerion puts a privilege on the service account that holds it, on the node that holds it, and on every Deployment, DaemonSet, StatefulSet, Job, CronJob, and Pod running as that account. A workload picks it up only when the account’s token is mounted into the pod, because without that token the container holds none of the account’s permissions.

Ten new checks ship with this:

[PLERION-K8S-177] Ensure no role binding grants cluster administrator
[PLERION-K8S-178] Ensure no workload runs with a service account that has cluster administrator privileges
[PLERION-K8S-179] Ensure no workload runs with a service account that can escalate its privileges
[PLERION-K8S-180] Ensure no workload runs with a service account that has overly permissive privileges
[PLERION-K8S-181] Ensure no service account has cluster administrator privileges
[PLERION-K8S-182] Ensure no service account can escalate its privileges
[PLERION-K8S-183] Ensure no service account has overly permissive privileges
[PLERION-K8S-184] Ensure no node has cluster administrator privileges
[PLERION-K8S-185] Ensure no node can escalate its privileges
[PLERION-K8S-186] Ensure no node has overly permissive privileges

Review external access to AWS with resource access grants: A resource access grant is one way a single resource grants access to a single principal, such as an AWS account, a federated identity, an AWS service, or the public. Plerion now builds this inventory for every tenant, analyzing 97 AWS resource types across four sharing mechanisms: resource policies, role trust policies, Resource Access Manager (RAM) shares, and cross-account permissions set directly as an attribute. Learn more →
Perform access reviews end to end: You can export access grants to a spreadsheet or do the whole access review inside Plerion. Name the team accountable for a grant, record a Keep, Remove, Review later, or Trust until review decision, note why the access exists, and set the date to look again. Every change is kept in the grant’s history, and the Past due preset shows the grants whose review date has passed. Learn more →
Expect a wave of untrusted external access findings on the first scan: Plerion raises a finding for every asset that grants access to an external principal you have not confirmed as trusted, and your trusted principals list starts almost empty. Much of that first wave is often access you meant to grant. Set your trusted principals in Settings > Profiles > Trusted principals, or ask Pleri for help, before working the findings one by one. Learn more →

Detection exemptions, now over the API: Read the exemptions on any detection, write a new set, or clear them, without opening the platform. Match on asset name, tags, region, principal, or API Gateway route, and the findings already on your dashboard are re-evaluated rather than waiting for the next scan. List your profiles first, since the default profile covers only the integrations that have no profile of their own.
Learn more →

Plerion’s compliance frameworks, rebuilt against today’s detections: Plerion has re-mapped 40 of its compliance frameworks from scratch against the current detection catalog, producing 15,250 control-to-detection mappings. Eighteen move to the publisher’s latest edition, including PCI DSS 4.0.1, NIST SP 800-53 Rev 5 Release 5.2.0, CSA CAIQ v4.1, UK NCSC CAF 4.0, and the FedRAMP Rev 5 CR26 baselines. The other 22 keep their edition and gain current coverage, and 29 frameworks now include Kubernetes checks alongside AWS, Azure, and GCP. Because each of these mappings was rebuilt rather than patched, your posture percentages will shift in both directions. They now reflect what Plerion detects today. Learn more →
Superseded framework editions have been retired: Where a newer edition now ships, the edition it replaces has been switched off so you no longer see two copies of the same standard. This covers 23 entries, among them PCI DSS 4.0 and 3.2.1, both retired by the PCI Security Standards Council, plus NIST CSF v1.1, ISO/IEC 27001:2013, and FFIEC CAT, which its publisher withdrew in August 2025. A retired edition disappears from your framework list, though its existing mappings are preserved and nothing is deleted. If you were tracking one, its successor is in your list ready to use: some are already switched on, and the jurisdiction- or sector-specific ones are yours to enable when you need them. FFIEC is the exception, as it has no successor.
CIS Amazon Web Services Foundations Benchmark v7.0.0 is now available: Measure your AWS accounts against the newest edition of the benchmark, published in March 2026. All 70 recommendations are mapped to Plerion detections, including six new AWS Organizations controls covering centralized root access, authorization guardrails, organizational unit structure, and delegated administrators, plus a new check for reaching AWS services over VPC endpoints. Every recommendation carries its CIS Level 1 or Level 2 profile. Version 4.0.1 is retired in line with the change above, so your list shows a single current edition.
FedRAMP 20x Key Security Indicators is now available: Measure your cloud against all 46 Key Security Indicators in the FedRAMP Consolidated Rules for 2026, the indicator set behind the FedRAMP 20x certification path. Plerion maps 33 of them to detections across AWS, Azure, GCP, and Kubernetes; the other 13 are process and governance controls, such as confirming that training or incident response procedures stay effective, and each says so on the control instead of showing a false pass. FedRAMP 20x runs alongside the Rev 5 baselines, so your existing FedRAMP frameworks are untouched. Learn more →

GCP access is now fully Plerion-curated: The GCP organization integration grants its organization-wide access through a Plerion-defined custom role, built from a curated, reviewed permission manifest. The role reads only configuration and metadata, never data contents. Plerion screens every new permission Google introduces before it can be granted. Learn more →

Pleri now raises pull requests in Azure DevOps: Ask Pleri to fix a high or critical IaC issue in an Azure DevOps repository and she’ll open the pull request for you, then check its status, request a review, or abandon it with a reason. Azure DevOps speaks its own dialect and so does Pleri: pull requests get reviewers, not assignees, and they’re abandoned, not closed. Learn more →

Privilege escalation findings on IAM policies are now Low: A policy has no effect until it is attached to an identity, and we already report the roles, users, and groups that hold it at full severity. Expect roughly four in ten of your [PLERION-AWS-1013] findings to move to Low. Nothing is removed.

GCP AI coverage widens further: Plerion ships 46 new posture checks across Vertex AI, Vertex AI Workbench and Colab Enterprise, Agent Engine, Vertex AI Search and Gemini Enterprise, Model Armor, Dialogflow CX, Cloud TPU, and Gemini Code Assist, plus project-level org-policy guardrails for Vertex AI Workbench access and Model Garden model use. Asset discovery now also covers 16 new GCP resource types behind these services.

Onboard AWS accounts with Terraform: Deploy Plerion straight from your own Terraform. A new template provisions the IAM role and policies as native Terraform resources and registers the integration automatically, with no manual console step and no CloudFormation stack in your account. Choose whether workload scanning runs inside your account or through a Plerion-managed service account, and apply the template across every account you manage with Terraform.
Know what’s inside your Kubernetes workloads: Workload scanning now builds a software bill of materials (SBOM) for every container image behind your Deployments, DaemonSets, StatefulSets, Pods, Jobs, and CronJobs, so the full package inventory sits on the asset’s SBOM tab. Switch on secret scanning and Plerion also reports the API keys, tokens, and passwords left inside those images on the asset’s Sensitive data tab, with severity so you know what to rotate first. Pick the scan types when you connect a cluster, or change them anytime from the integration’s workload scan settings. Learn more →

Connect your entire GCP organization at once: Plerion now onboards a whole Google Cloud organization from a single generated command, with no service account keys and nothing to fill in first. The onboarding script finds your organization, creates the Plerion service project, and sets up keyless access using Workload Identity Federation. If you prefer infrastructure as code, an equivalent Terraform template does the same job. Plerion then discovers every project in the organization, including ones created later, and you choose which projects to include or let everything onboard automatically. The organization itself is scanned too, from organization details and organization-level IAM policy to folders, organization policies, and VPC Service Controls service perimeters. Revoke access anytime by deleting a single resource. Learn more →

See the GCP organization integration in action

CIS benchmark coverage for Google Cloud: Plerion now maps your Google Cloud posture to the CIS Google Cloud Platform Foundation Benchmark v5.0.0. Track your posture against its recommendations control by control from your compliance settings. Learn more →

A Well-Architected lens for Google Cloud: Plerion now maps your Google Cloud posture to the Google Cloud Well-Architected Framework. Review your workloads against Google’s own recommendations across all six pillars — operational excellence, security, reliability, cost optimization, performance, and sustainability — with answers populated from your Plerion findings. Learn more →

GCP coverage leaps forward, now with AI Security Posture Management: Plerion now discovers and continuously assesses 32 new GCP resource types, extending deep coverage across AlloyDB, Cloud Run, GKE, Spanner, Cloud Functions, Cloud Composer, Filestore, Datastream, Dataflow, Cloud Workstations, Secret Manager, Cloud TPU, and Batch, and most notably across Google’s AI stack: Vertex AI, Model Armor, and Document AI. Behind them ship 38 new posture checks (with 3 existing checks promoted to continuous runtime scanning), hardening everything from public data-plane exposure to encryption and network isolation.
AI-SPM for the GenAI era: Fourteen of the new checks are purpose-built AI security posture management. Seven verify your Model Armor LLM guardrails are switched on and enforcing: prompt-injection and jailbreak defenses, malicious-URI blocking, sensitive-data (DLP) filtering, and Responsible-AI controls, so a misconfigured guardrail can’t quietly leave your models exposed. Six more lock down Vertex AI endpoints, Feature Stores, and Workbench instances for private networking and customer-managed encryption. And for the highest-risk exposures (a public GKE control plane, a public AlloyDB instance, or an anonymously invocable Cloud Run service), Plerion now goes beyond configuration and actively fact-checks them: it probes the live endpoint to confirm the exposure is genuinely reachable from the internet before it reaches your queue, so your most urgent findings arrive already verified.

Secure your AI agents on Amazon Bedrock AgentCore: Plerion now inventories your full AgentCore estate — gateways, runtimes, memory, and the MCP servers and tools your agents reach through them — and checks it against a new set of detections, so you can confirm every agent is configured properly and securely. It flags public invoke access, weak authorizers, non-enforcing policies, and insecure endpoints before an agent or one of its tools becomes an entry point.

Know which findings are running out of time: Failed findings now show an SLA status (within SLA, nearing breach, or breached) with the time left until their resolution deadline. Filter the findings dashboard by SLA status to focus on what’s closest to breaching. Learn more →

Refreshed MITRE ATT&CK Cloud coverage: Plerion updated its MITRE ATT&CK Cloud Matrix to Enterprise ATT&CK v19.1. Your threat mapping now reflects the current cloud technique set, including the Stealth and Defense Impairment tactics.

A new MITRE threat matrix: Plerion’s threat mapping now includes the MITRE ATT&CK Containers Matrix. See which adversary techniques your cloud and code posture covers across your container workloads.

A Well-Architected lens for financial services: Plerion now maps your AWS posture to the AWS Well-Architected Framework Financial Services Industry Lens. Review your workloads against the lens’s best practices for operational resilience, security, and reliability, with answers populated from your Plerion findings. Learn more →

Track your posture against Korea’s ISMS-P: Plerion now maps your cloud and code posture to ISMS-P, Korea’s integrated information security and personal information protection management certification. Turn it on from your compliance settings to track your posture control by control. Learn more →

Well-Architected reviews for your AI and ML workloads: Plerion now maps your AWS posture to two new AWS Well-Architected lenses: the Generative AI Lens and the Machine Learning Lens. Review your generative-AI and machine-learning workloads against each lens’s best practices, with answers populated from your Plerion findings. Learn more →

CWPP scanning, fully managed by Plerion: Scan your workloads without running any scanning infrastructure in your own account. Plerion hosts the appliances in its own accounts and scans across every supported CWPP region. Select it when you onboard an AWS account, and you’re done. Learn more in the platform docs →

Refreshed LGPD compliance coverage: Plerion re-mapped the Brazilian General Data Protection Law (LGPD) against today’s detection catalog, broadening coverage from two to nine of its data-protection articles and adding Kubernetes checks alongside AWS, Azure, and GCP. Your LGPD posture now reflects Plerion’s current cloud and code detections. Learn more →

Measure your AI systems against four security frameworks: Plerion now maps your cloud and code posture to ISO/IEC 42001, NIST AI Risk Management Framework (NIST AI RMF 1.0), OWASP Top 10 for LLM Applications (2025), and OWASP Top 10 for Agentic Applications (2026). Turn any of them on from your compliance settings to track your posture control by control. Learn more →

Trace any cloud asset back to the code that created it: Code to Cloud connects your GitHub repositories to the AWS assets they manage — so when a security finding fires, you know exactly where to go to fix it. On any asset’s detail page, you’ll see the responsible repository with a direct link. Flip it around in Code Security: open any repository and the new Assets tab shows every AWS asset it manages, giving you a clear picture of what’s at stake before making a change. On by default for all GitHub integrations. Supports CloudFormation, CDK, and Terraform. And when you ask Pleri to help remediate a finding, she’ll factor in the linked repository — giving you the right context to know where the fix belongs.

Exempted findings now stay out of your dashboard counts: Dashboard cards and their slide-over panels now respect exemptions — public assets, assets with critical or exploited vulnerabilities, overly permissive privileges, admin privileges, privilege escalation, attack paths, and failed findings all exclude anything you’ve marked as exempt. What you see is what actually needs attention.

Spot privilege escalation in your IAM policies: A new check, [PLERION-AWS-1013], identifies IAM roles, users, groups, and managed policies that allow actions that lead to privilege escalation. The contextual view breaks the offending permissions down — the escalation technique used, what permissions it escalates to, and which actions are required for the attack to succeed vs those that make it easier for an attacker. A new policy tab highlights the offending lines in each policy.

Plerion check updates: We’ve uplifted nine existing checks covering public exposure and access control across EC2, Application Load Balancers, Network Load Balancers, IAM, API Gateway V2, FPGA images, MediaStore, SES, and CloudWatch Logs, making findings clearer and more reliable.

[PLERION-AWS-194] Ensure EC2 instances are not publicly accessible
[PLERION-AWS-530] Ensure Amazon API Gateway V2 routes are authenticated
[PLERION-AWS-553] Ensure IAM roles are not publicly accessible
[PLERION-AWS-567] Ensure CloudWatch log resource policies are not publicly accessible
[PLERION-AWS-568] FPGA Image (AFI) is publicly accessible
[PLERION-AWS-571] Application Load Balancer (ALB) is publicly accessible
[PLERION-AWS-575] Elemental MediaStore container is publicly accessible
[PLERION-AWS-576] SES identity is publicly accessible
[PLERION-AWS-862] Network Load Balancer (NLB) is publicly accessible

Let there be (less) light ☀️🌙: You can now toggle between Dark and Light mode straight from your profile menu. Go full night owl for those late-night incident reviews, or keep it bright for your 9am standups. Your retinas, your call.

Plerion check updates: We’ve improved five existing checks covering public exposure across SQS, Secrets Manager, S3 Glacier, Glue, and RDS, making findings clearer and more reliable.

[PLERION-AWS-92] SQS queue is publicly accessible
[PLERION-AWS-94] Secrets Manager secret is publicly accessible
[PLERION-AWS-114] S3 Glacier vault is publicly accessible
[PLERION-AWS-573] Glue data catalog is publicly accessible
[PLERION-AWS-307] RDS DB cluster snapshot is publicly accessible

Say hello to new more AI-SPM checks: We’ve shipped 86 new checks across Amazon SageMaker and Amazon Bedrock, covering encryption, IAM privileges, network exposure, and runtime configuration.

View all 86 checks

[PLERION-AWS-919] SageMaker AutoML job is encrypted with AWS-owned key
[PLERION-AWS-920] SageMaker feature group is encrypted with AWS-owned key
[PLERION-AWS-921] SageMaker model card is encrypted with AWS-owned key
[PLERION-AWS-922] SageMaker domain is encrypted with AWS-owned key
[PLERION-AWS-923] SageMaker training job is encrypted with AWS-owned key
[PLERION-AWS-924] SageMaker transform job is encrypted with AWS-owned key
[PLERION-AWS-925] SageMaker processing job is encrypted with AWS-owned key
[PLERION-AWS-926] SageMaker hyperparameter tuning job is encrypted with AWS-owned key
[PLERION-AWS-927] SageMaker compilation job is encrypted with AWS-owned key
[PLERION-AWS-928] SageMaker data quality job definition is encrypted with AWS-owned key
[PLERION-AWS-931] SageMaker endpoint config is encrypted with AWS-owned key
[PLERION-AWS-932] SageMaker flow definition is encrypted with AWS-owned key
[PLERION-AWS-933] SageMaker geospatial earth observation job is encrypted with AWS-owned key
[PLERION-AWS-934] SageMaker geospatial vector enrichment job is encrypted with AWS-owned key
[PLERION-AWS-935] SageMaker inference experiment is encrypted with AWS-owned key
[PLERION-AWS-936] SageMaker inference recommendations job is encrypted with AWS-owned key
[PLERION-AWS-937] SageMaker labeling job is encrypted with AWS-owned key
[PLERION-AWS-938] SageMaker model bias job definition is encrypted with AWS-owned key
[PLERION-AWS-939] SageMaker explainability job definition is encrypted with AWS-owned key
[PLERION-AWS-940] SageMaker model package is encrypted with AWS-owned key
[PLERION-AWS-941] SageMaker model quality job definition is encrypted with AWS-owned key
[PLERION-AWS-942] SageMaker monitoring schedule is encrypted with AWS-owned key
[PLERION-AWS-943] SageMaker notebook instance is encrypted with AWS-owned key
[PLERION-AWS-944] SageMaker optimization job is encrypted with AWS-owned key
[PLERION-AWS-946] SageMaker user profile is encrypted with AWS-owned key
[PLERION-AWS-947] Bedrock automated reasoning policy is encrypted with AWS-owned key
[PLERION-AWS-948] Bedrock data source is encrypted with AWS-owned key
[PLERION-AWS-949] Bedrock evaluation job is encrypted with AWS-owned key
[PLERION-AWS-950] Bedrock flow is encrypted with AWS-owned key
[PLERION-AWS-951] Bedrock imported model is encrypted with AWS-owned key
[PLERION-AWS-952] Bedrock model copy job is encrypted with AWS-owned key
[PLERION-AWS-953] Bedrock model customization job is encrypted with AWS-owned key
[PLERION-AWS-954] Bedrock model import job is encrypted with AWS-owned key
[PLERION-AWS-955] Bedrock prompt is encrypted with AWS-owned key
[PLERION-AWS-956] Bedrock session is encrypted with AWS-owned key
[PLERION-AWS-957] SageMaker algorithm has admin privileges
[PLERION-AWS-958] SageMaker AutoML job has admin privileges
[PLERION-AWS-959] SageMaker cluster has admin privileges
[PLERION-AWS-960] SageMaker domain has admin privileges
[PLERION-AWS-961] SageMaker earth observation job has admin privileges
[PLERION-AWS-962] SageMaker endpoint config has admin privileges
[PLERION-AWS-963] SageMaker hyperparameter tuning job has admin privileges
[PLERION-AWS-964] SageMaker image has admin privileges
[PLERION-AWS-965] SageMaker MLflow tracking server has admin privileges
[PLERION-AWS-966] SageMaker model has admin privileges
[PLERION-AWS-967] SageMaker model package has admin privileges
[PLERION-AWS-968] SageMaker notebook instance has admin privileges
[PLERION-AWS-969] SageMaker pipeline has admin privileges
[PLERION-AWS-970] SageMaker processing job has admin privileges
[PLERION-AWS-971] SageMaker training job has admin privileges
[PLERION-AWS-972] SageMaker user profile has admin privileges
[PLERION-AWS-973] SageMaker vector enrichment job has admin privileges
[PLERION-AWS-974] SageMaker notebook domain allows egress internet access to bypass VPC
[PLERION-AWS-975] SageMaker AutoML job has overly permissive privileges
[PLERION-AWS-976] SageMaker earth observation job has overly permissive privileges
[PLERION-AWS-977] SageMaker hyperparameter tuning job has overly permissive privileges
[PLERION-AWS-978] SageMaker processing job has overly permissive privileges
[PLERION-AWS-979] SageMaker training job has overly permissive privileges
[PLERION-AWS-980] SageMaker vector enrichment job has overly permissive privileges
[PLERION-AWS-981] SageMaker cluster has overly permissive privileges
[PLERION-AWS-982] SageMaker domain has overly permissive privileges
[PLERION-AWS-983] SageMaker endpoint config has overly permissive privileges
[PLERION-AWS-984] SageMaker algorithm has overly permissive privileges
[PLERION-AWS-985] SageMaker image has overly permissive privileges
[PLERION-AWS-986] SageMaker MLflow tracking server has overly permissive privileges
[PLERION-AWS-987] SageMaker model has overly permissive privileges
[PLERION-AWS-988] SageMaker model package has overly permissive privileges
[PLERION-AWS-989] SageMaker notebook instance has overly permissive privileges
[PLERION-AWS-991] SageMaker pipeline has overly permissive privileges
[PLERION-AWS-992] SageMaker user profile has overly permissive privileges
[PLERION-AWS-993] SageMaker notebook instance has root access enabled
[PLERION-AWS-994] SageMaker notebook instance allows egress internet access to bypass VPC
[PLERION-AWS-995] SageMaker endpoint without data capture enabled
[PLERION-AWS-996] SageMaker pipeline allows privilege escalation
[PLERION-AWS-997] SageMaker algorithm allows privilege escalation
[PLERION-AWS-998] SageMaker AutoML job allows privilege escalation
[PLERION-AWS-999] SageMaker cluster allows privilege escalation
[PLERION-AWS-1000] SageMaker domain allows privilege escalation
[PLERION-AWS-1001] SageMaker earth observation job allows privilege escalation
[PLERION-AWS-1002] SageMaker endpoint config allows privilege escalation
[PLERION-AWS-1003] SageMaker hyperparameter tuning job allows privilege escalation
[PLERION-AWS-1004] SageMaker image allows privilege escalation
[PLERION-AWS-1009] SageMaker processing job allows privilege escalation
[PLERION-AWS-1010] SageMaker training job allows privilege escalation
[PLERION-AWS-1011] SageMaker user profile allows privilege escalation
[PLERION-AWS-1012] SageMaker vector enrichment job allows privilege escalation

All checks are live now. Go see what lights up.

CloudFormation updates, minus the manual effort: Auto stack update keeps your Plerion stack current with secure, controlled rollouts. Review changelogs, skip versions if needed, and rely on cryptographic verification and isolated execution for peace of mind. Learn more in the platform docs →

Plerion check updates: This release includes a second round of improvements to existing Plerion checks, making findings clearer and more reliable. The following checks were improved:

[PLERION-AWS-78] Redshift cluster does not have encryption in transit enforced
[PLERION-AWS-89] SNS topic is publicly accessible
[PLERION-AWS-102] Lambda layer is publicly accessible
[PLERION-AWS-103] Serverless Application Repository application is publicly accessible
[PLERION-AWS-122] MSK cluster does not have encryption in transit enforced for broker-to-broker traffic
[PLERION-AWS-123] MSK cluster does not have encryption in transit enforced for client-to-broker traffic
[PLERION-AWS-131] MemoryDB cluster does not have encryption in transit enabled
[PLERION-AWS-138] SageMaker endpoint does not have a KMS key configured for volume encryption
[PLERION-AWS-166] ElastiCache for Redis cluster does not have encryption in transit enabled
[PLERION-AWS-180] DocumentDB cluster parameter group does not have encryption in transit enforced
[PLERION-AWS-572] EventBridge event bus is publicly accessible
[PLERION-AWS-824] RDS cluster does not have encryption in transit enforced
[PLERION-AWS-825] RDS instance does not have encryption in transit enforced
[PLERION-AWS-844] EFS file system enforces encryption in transit

The following checks have been removed to ensure you receive clear, actionable findings:

[PLERION-AWS-128] Ensure Amazon Neptune cluster parameter groups use SSL connections so that they have encryption in transit enabled
[PLERION-AWS-840] Ensure Amazon S3 Glacier vaults are encrypted at rest
[PLERION-AWS-841] Ensure Amazon S3 Glacier vaults have encryption in transit enabled
[PLERION-AWS-845] Ensure Amazon DynamoDB tables have encryption in transit enabled
[PLERION-AWS-846] Ensure Amazon EC2 AMIs have encryption in transit enabled
[PLERION-AWS-847] Ensure Amazon Elastic Block Store (EBS) volumes have encryption in transit enabled
[PLERION-AWS-848] Ensure Amazon Elastic Block Store (EBS) snapshots have encryption in transit enabled
[PLERION-AWS-853] Ensure AWS Glue data catalogs have encryption in transit enabled
[PLERION-AWS-856] Ensure Amazon DynamoDB tables are encrypted at rest

Environment wrangling, simplified: Manage Production and Non-production classifications for every cloud integration from one place.
Open the Environments page →

New year, newly improved checks: We’re starting the year strong with a round of improvements to existing Plerion checks, helping you identify misconfigurations more clearly and keep your cloud environments secure. Here is the first batch of improved checks, with clearer and more consistent language:

[PLERION-AWS-149] EMR cluster does not have encryption in transit enabled
[PLERION-AWS-157] OpenSearch domain does not enforce HTTPS
[PLERION-AWS-229] CloudFront distribution does not enforce HTTPS for viewers and origins

Meet your new workload scanning metronome: Define how often your workloads are scanned with daily, recommended or custom schedules. More control and clearer coverage, your way.

Go global with the new global filter: Set your context across the platform using top-level filters on environment, asset group or integration. More improvements coming soon!

Environment classification has arrived: Bring order to your cloud universe by classifying your integrations as Production or Non-production. Zoom into the environment you care about and understand issues with sharper context.

Attack paths for Azure environments: Azure joins the lineup! You can now explore how risks link across your environment and see exactly where to focus your fixes.

View the attack paths in action!