Loading story…
Amazon Web Services (AWS) commissioned NCC Group to conduct an independent architectural review of Amazon Elastic Kubernetes Service (EKS) to validate AWS's claims regarding data security, specifically focusing on the prevention of AWS operator access to customer content. The review assessed the technical controls and operational architecture designed to ensure that AWS personnel cannot read, copy, extract, or modify customer data managed by EKS, affirming the service's compliance with stringent data privacy requirements for regulated and sensitive workloads.
Following the completion of the review, AWS publicly announced that Amazon EKS has received independent affirmation of its 'zero operator access' design. This means that EKS is architected so that AWS employees do not have technical pathways to access customer content, with administration handled through automation and secure APIs. The announcement reinforces AWS's commitment to customer trust and transparency, highlighting the company's ongoing efforts to provide secure cloud infrastructure and meet the expectations of customers with critical data privacy needs.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
AWS published a security blog post stating that Amazon EKS had received independent affirmation of its zero operator access design, citing the external assessment. This marked AWS's official public response and communication of the report's findings.
NCC Group released a public report assessing security claims about Amazon Elastic Kubernetes Service, including its zero operator access design. The publication provided an independent affirmation of AWS EKS security architecture claims.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Amazon EKS access management and Pod Identity add IAM-native controls for granting cluster access and workload AWS permissions, but security research found they can create lateral-movement and privilege-escalation paths. An attacker who compromises an IAM principal with `CreateAccessEntry` and `AssociateAccessPolicy` permissions can create or alter an EKS access entry and potentially obtain Kubernetes `cluster-admin` access. EKS access policies combine cumulatively with legacy `aws-auth` ConfigMap mappings and Kubernetes RBAC bindings, complicating effective-permission reviews; even `AmazonEKSEditPolicy`, and in some cases `AmazonEKSViewPolicy`, may expose escalation or sensitive-data-disclosure opportunities. Pod Identity introduces a node-local agent that supplies temporary AWS credentials to workloads, expanding the impact of node or pod compromise. A compromised `hostNetwork` pod may intercept plaintext traffic to the local agent endpoint and capture credentials issued to other pods on the same worker node. Organizations should audit both EKS API and Kubernetes RBAC authorization paths, limit access-entry administration, apply namespace-scoped and least-privilege permissions, protect kubelet pod-file access, and segregate untrusted workloads. IAM Roles for Service Accounts (IRSA), which uses projected service-account OIDC tokens to obtain role-specific STS credentials, remains an alternative where preventing node-local credential interception is a priority.
Sep 3, 2026
Amazon Web Services (AWS) has announced the AWS European Sovereign Cloud, a new independent cloud infrastructure designed to address the unique sovereignty, security, and compliance requirements of European public sector organizations and highly regulated industries. The AWS European Sovereign Cloud incorporates the Sovereign Reference Framework (ESC-SRF), which aligns with governance, operational control, data residency, and technical isolation criteria, and is undergoing independent third-party audits to validate its compliance with European regulatory expectations. AWS is also making the ESC-SRF available through AWS Artifact, enabling customers and partners to build upon these sovereignty controls for their own compliance needs. In parallel, AWS has reaffirmed its commitment to supporting customers in meeting the requirements of the EU's NIS 2 Directive, which aims to strengthen cybersecurity across the Union. As NIS 2 is transposed into national law across EU member states, AWS is working closely with national cybersecurity authorities and customers to ensure robust security practices and compliance. These efforts are part of AWS's broader responsibility to secure digital infrastructure in Europe and to help organizations build resilience and trust in the online environment.
Jun 29, 2026
AWS published a reference architecture for **Amazon Bedrock AgentCore** that limits AI agents to the requesting user’s permissions by propagating end-user authorization context to downstream services instead of enforcing access control in agent code. In the design, users authenticate through **Amazon Cognito**, custom claims such as department are added to JWTs, and **AgentCore Runtime** validates those claims before the agent runs. AWS said this approach reduces the risk of unauthorized data exposure from prompt injection or application bugs because the agent acts as an orchestrator rather than a trusted gatekeeper. The architecture demonstrates three enforcement patterns across common enterprise data sources: user-scoped temporary AWS credentials for **Amazon DynamoDB** using `STS AssumeRoleWithWebIdentity` and session tags, metadata-based filtering for **Amazon Bedrock Knowledge Bases**, and OAuth 2.0 on-behalf-of token exchange for **Salesforce** through AgentCore Identity. In the example CRM workflow, Sales and Finance employees can use the same agent while only receiving records allowed by their own roles, with AWS also recommending stronger isolation such as separate knowledge bases and IAM policies where stricter separation is required.
Aug 20, 2026