> ## 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. # Changelog > See what's new at Plerion as we deliver features to keep your code and cloud safe. *** 1. **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. * **\[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 2. **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 →](/guides/platform/agent-security) 3. **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 →](/guides/integrations/aws/additional-aws-configurations/provide-plerion-access-to-kms-keys#read-encrypted-resource-details) *** 1. **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 →](/api-reference/preferences/get-a-users-home-dashboard) *** 1. **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](https://www.first.org/epss). 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 →](/guides/platform/vulnerabilities#epss-scores) 2. **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. *** 1. **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. *** 1. **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. 2. **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 →](/guides/integrations/jira#map-jira-fields) 3. **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. 4. **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. *** 1. **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. 2. **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 3. **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 →](/guides/integrations/aws/additional-aws-configurations/scan-agentcore-runtime-code) *** 1. **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](/guides/integrations/kubernetes/overview), and OpenShift, Service Fabric and Batch resources now appear in the inventory. [See what is scanned and how →](/guides/integrations/azure/azure-cwpp-workload-coverage) 2. **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 3. **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. 4. **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. 5. **Web apps and function apps that run a custom container are scanned by image:** a site whose runtime stack is `DOCKER|` has that image pulled and scanned, the same way Container Apps are, instead of a code download that finds nothing. 6. **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 →](/guides/integrations/kubernetes/collector-manager/permissions/allow-access-to-managed-registries) 7. **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. *** 1. **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 →](/guides/platform/integration-groups#define-tags-on-an-integration) 2. **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. 3. **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. 4. **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 →](/guides/administration/scim/overview) 5. **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. 6. **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. 7. **Manage roles over the API:** Create roles and grant or revoke them for users and user groups with an organization API key. [Learn more →](/api-reference/roles/list-roles) 8. **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. *** 1. **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". 2. **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. 3. **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. * **\[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? 4. **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. 5. **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. *** 1. **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 →](/guides/administration/api-keys) 2. **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**. 3. **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. 4. **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 →](/guides/platform/well-architected-workload) 5. **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 6. **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. 7. **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. 8. **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. 9. **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. *** 1. **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 →](/guides/platform/custom-reports/overview) 2. **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 →](/guides/platform/custom-reports/how-to-create-a-custom-report) 3. **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. *** 1. **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 →](/guides/integrations/aws/terraform/getting-started-with-terraform) 2. **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 →](/guides/integrations/aws/terraform/getting-started-with-terraform#set-up-a-service-account-with-terraform) 3. **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 →](/guides/integrations/mcp) *** 1. **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 →](/guides/administration/scim/overview) 2. **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 →](/guides/administration/user-groups) 3. **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 →](/guides/administration/organization-api-keys) 4. **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 →](/guides/administration/scim/overview#break-glass-admins) *** 1. **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 →](/guides/integrations/gcp/workload-scanning/overview) Access stays keyless through workload identity federation (WIF). [Access and permissions →](/guides/integrations/gcp/workload-scanning/access-and-permissions) *** 1. **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 →](/guides/integrations/kubernetes/collector-manager) 2. **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 →](/guides/platform/integration-groups) *** 1. **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 →](/guides/platform/cwpp/vulnerability-auto-triage) *** 1. **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 →](/guides/platform/plerion-risk-score/asset-risk-score) 2. **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 *** 1. **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 →](/guides/platform/resource-access-grants/overview) 2. **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 →](/guides/platform/resource-access-grants/access-review) 3. **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 →](/guides/platform/resource-access-grants/trusted-principals) *** 1. **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 →](/api-reference/detection-exemptions/get) *** 1. **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 →](/guides/platform/compliance-frameworks) 2. **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. 3. **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. 4. **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 →](/guides/platform/compliance-frameworks) *** 1. **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 →](/guides/integrations/gcp/overview) *** 1. **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 →](/guides/integrations/azure-devops#fixing-issues-with-pleri) *** 1. **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. *** 1. **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. *** 1. **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. 2. **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 →](/guides/platform/cwpp/scanning-coverage/sbom) *** 1. **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 →](/guides/integrations/gcp/overview)