AWS S3 PCI compliance depends on data discovery, not encryption alone

At a glance

What this is: This analysis argues that AWS S3 can hold PCI data, but compliance fails when teams cannot continuously discover where that data has spread across AWS and adjacent workflows.

Why it matters: For IAM and data security teams, the key issue is that access controls alone do not reveal data location, so PCI governance now depends on discovery, classification, and remediation across storage and AI paths.

Context

AWS S3 is a storage control, not a PCI compliance boundary. The compliance gap appears when cardholder data spreads into copies, exports, logs, backups, PDFs, and AI-connected workflows that infrastructure controls do not classify or trace.

This is where cloud security overlaps with identity and data governance. IAM can tell you who may reach a bucket, but it cannot tell you what sensitive data sits inside that bucket or where it moves after a user, browser, or agent touches it.

Key questions

Q: What fails first when AWS S3 stores PCI data without discovery?

A: The first failure is usually scope visibility. Teams may know a bucket exists and may even encrypt it, but they do not know where cardholder data has been copied, exported, or retained across adjacent stores. Once the organisation loses content-level visibility, compliance becomes an assumption instead of an operational control.

Q: Why do encryption and IAM not solve PCI compliance on their own?

A: They protect access and confidentiality, but they do not identify every location where PAN or other regulated data exists. PCI programmes fail when controls protect approved repositories while missing forgotten exports, backups, logs, and file attachments. Discovery is the missing control that makes the rest of the stack usable.

Q: How do security teams know whether PCI access controls are actually working?

A: Look for evidence that access is both limited and reviewed: fewer broad entitlements, clear ownership for every privileged account, monitoring that flags unusual access, and remediation records for accounts that no longer need payment-system reach. If the same identities repeatedly retain access without challenge, the control is procedural rather than effective.

Q: What should organisations do when PCI data appears in an unexpected AWS location?

A: Treat it as a governance exception, not a routine alert. Contain the exposure, determine how the data got there, restrict access, remove unneeded copies, and update discovery and retention rules so the same pattern does not recur in S3, backups, or connected workflows.

Technical breakdown

Why encryption and IAM do not reveal PCI data location

Encryption protects data in place, and IAM restricts who can access storage objects, but neither control answers the core PCI question: where is cardholder data actually stored right now? In AWS, that data can exist in S3, RDS, Redshift, DynamoDB, backups, logs, and exported files, often outside the system teams originally intended. The technical failure is visibility, not just protection. Without content inspection and continuous inventory, security teams are governing containers while the regulated data keeps moving.

Practical implication: pair storage controls with continuous data discovery so PCI governance follows the data, not just the bucket.

How DSPM and DLP change AWS data security

Data Security Posture Management, or DSPM, shifts the control plane from infrastructure posture to data posture. It discovers sensitive content, classifies it, maps exposure, and links findings to remediation. DLP then enforces policy when the data is copied, uploaded, shared, or accessed in an unsafe context. In PCI environments, that combination matters because the same dataset may appear in structured records, unstructured files, and downstream applications. The control objective is not only to secure storage, but to control how regulated data propagates across environments.

Practical implication: use DSPM for discovery and classification, then use DLP to enforce masking, blocking, alerting, or deletion.

Why MCP and GenAI create a new PCI movement path

The article adds an important 2026 wrinkle: AI agents can retrieve enterprise data through APIs and the Model Context Protocol, or MCP. That creates a new transfer path from AWS data stores into model workflows, where traditional bucket-level controls no longer apply cleanly. The risk is not that MCP replaces cloud security, but that it widens the place where sensitive data can exit approved boundaries. Once an agent can query a connected source, the security problem becomes policy enforcement at retrieval time, not only storage hardening.

Practical implication: extend data-loss controls to agentic workflows so retrieval from AWS data stores is policy-checked before model exposure.

Threat narrative

Attacker objective: The practical objective is not a single exploit but uncontrolled access to regulated data through untracked copies and connected workflows.

1. Entry occurs when PCI data is exported from an approved AWS dataset into S3 objects, backups, logs, support files, or other secondary stores.
2. Credentialed access and overexposure then let users, applications, browsers, or connected AI workflows reach copies that were never meant to hold regulated data.
3. Impact follows when the organisation loses track of where the cardholder data sits and cannot confidently govern exposure, retention, or downstream movement.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Discovery is now the decisive control plane for PCI in cloud storage: AWS configuration tells you whether a bucket is public or encrypted, but not whether regulated data has quietly spread into adjacent stores. That creates a governance gap because compliance teams can certify infrastructure while missing the actual regulated content. For practitioners, the lesson is to treat data location as a first-class control objective, not a secondary audit question.

Encryption without content visibility creates false assurance: A private, encrypted S3 bucket can still contain forgotten exports, backups, or support attachments with cardholder data. The failure is not that encryption is useless, but that it governs the wrong layer if teams do not know where PAN resides. Practitioners should align policy, retention, and discovery so protective controls can be applied to real data, not assumed data.

Data movement, not just data storage, is the modern PCI problem: The article correctly extends the risk boundary to SaaS tools, browsers, endpoints, and GenAI workflows. That is the right governance lens because regulated data rarely stays in one repository, and identity controls do not prevent a user or agent from copying it into another context. Practitioners need cross-domain enforcement that follows the data across the workflow.

MCP changes the scope of PCI governance by introducing retrieval-time exposure: AI agents can become an indirect access path to regulated information even when no human is manually downloading the file. That means PCI programmes now need to govern delegated retrieval, not only human access. The named concept here is PCI data movement drift, where regulated information migrates faster than the control model can track it. Practitioners should govern data movement as tightly as data storage.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

PCI data governance now depends on movement control, not just storage hardening: A bucket can be encrypted and still be operationally unsafe if regulated data keeps appearing in exports, backups, logs, and AI-connected workflows. The practical shift is from asking whether S3 is configured correctly to asking whether PCI data can be found, classified, and contained wherever it travels.

Data discovery becomes the control that makes IAM meaningful: Identity permissions tell you which principals can reach storage, but they do not tell you whether those principals can reach cardholder data that should never have been there. For programmes that span cloud and AI workflows, the governance problem is drift between access policy and data reality.

PCI data movement drift: regulated information often leaves its original repository faster than teams can certify it. That creates a control gap that only continuous discovery plus policy enforcement can close. For readers running cloud and AI programmes, the response is to monitor retrieval paths as carefully as storage locations.

For practitioners

• Implement continuous AWS data discovery Scan S3 and adjacent AWS stores continuously for cardholder data, backups, logs, exports, and unstructured files so PCI scope is based on actual content.
• Bind DSPM findings to remediation workflows Convert discoveries into masking, access blocking, alerting, labeling, or secure deletion so each PCI finding changes exposure rather than creating another ticket.
• Extend DLP into AI and MCP retrieval paths Inspect agent tool calls and connected workflows that can move AWS data into models or external apps, and block sensitive data before it leaves approved boundaries.
• Reconcile IAM with data-level access rules Review who can reach buckets and what sensitive content those identities can access, then remove permissions that allow unnecessary copying or export of PCI data.
• Apply retention controls to hidden duplicates Find duplicate PCI copies in backups, files, and support artifacts, then delete or quarantine stale data that no longer has a legitimate business purpose.

Key takeaways

• AWS S3 can be part of a PCI environment, but compliance breaks down when teams cannot locate cardholder data across the wider cloud estate.
• The main control gap is visibility into data location and movement, especially when exports, backups, logs, and AI workflows create hidden copies.
• Continuous discovery, classification, and remediation are the practical controls that turn cloud storage from a configuration exercise into governed data security.

Key terms

• Data Security Posture Management: Data Security Posture Management, or DSPM, is the continuous discovery and monitoring of where sensitive data lives, how it is exposed, and where policy gaps exist. Its value rises when it feeds remediation rather than generating findings alone, especially in environments where AI expands the number of data paths.
• Data Loss Prevention: Data loss prevention is the set of controls used to detect, block, and report sensitive data moving in ways the organisation does not allow. In practice, DLP must account for endpoints, email, cloud apps, APIs, and user behaviour, or it will miss the paths where real exposure happens.
• Cardholder Data Environment: The cardholder data environment is the set of systems, users, and processes that store, process, or transmit payment card data. For NHI governance, it includes every machine identity that can influence those systems, even when the identity itself is invisible to end users.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of modern cloud and AI risk. It helps security practitioners connect identity controls to the broader data and access patterns their programmes now depend on.