Shadow Cloud Usage by Vendors

A financial services organization conducted a routine cloud cost audit and discovered dozens of EC2 instances and S3 buckets they did not recognize. After investigation, they traced the resources back to a managed services vendor who had spun up infrastructure inside the customer's AWS account to perform work on an engagement , using an IAM role the customer had provisioned for the vendor without output limits or resource creation restrictions. The vendor considered it routine. The customer had never approved it. The infrastructure had been running for four months, had never appeared in any security review, was not covered by the organization's patch management program, and contained customer data the vendor had deposited there for processing. Nobody on either side had considered it a governance event. That is shadow cloud in a vendor context , not rogue employees using unauthorized SaaS tools, but authorized vendors creating unauthorized infrastructure inside your own environment.

What is Shadow Cloud Usage by Vendors, Really?

Shadow cloud usage by vendors is the creation, modification, or operation of cloud resources within a customer's environment , or using the customer's cloud identity and billing , without the customer's explicit knowledge and approval of those specific activities. It is distinct from the broader concept of shadow IT, which typically refers to employees using unauthorized applications. Vendor shadow cloud is more operationally significant because it happens inside infrastructure the customer controls and pays for, using access the customer deliberately granted, by parties the customer has contractually engaged , and yet it still falls entirely outside the customer's governance framework.

The mechanism is straightforward. A vendor is granted an IAM role or equivalent cloud identity to perform defined work in the customer's environment. That role, if not carefully scoped, may include permissions to create new compute instances, provision storage, deploy containerized workloads, or configure networking resources. When the vendor's engineers need additional infrastructure to perform their work , for processing, for staging, for tooling, for convenience , they use the access they already have. From a technical standpoint, nothing unusual has happened. From a governance standpoint, ungoverned infrastructure now exists in the customer's environment, outside the customer's asset inventory, outside their security scanning coverage, and potentially holding customer data under conditions the customer has never reviewed.

What makes this particularly difficult to govern is that it is often entirely well-intentioned. The vendor is not trying to evade oversight , they are trying to do their job efficiently, using the tools and access available to them. The problem is structural: IAM roles provisioned without explicit resource creation restrictions, combined with vendors who are accustomed to operating autonomously in cloud environments, produce ungoverned infrastructure as a natural byproduct of normal vendor operations. The governance gap is not the vendor's bad intent , it is the absence of boundaries the customer never established.

Shadow cloud usage by vendors concentrates risk across several specific dimensions:

• Ungoverned compute and storage provisioned outside the customer's asset inventory, not covered by patch management, vulnerability scanning, or configuration monitoring
• Data deposited on unauthorized infrastructure , vendor-created resources that hold customer data under storage and access conditions the customer has never reviewed or approved
• Billing exposure , vendor-provisioned resources running on the customer's cloud account and generating costs that may be difficult to attribute or recover
• Compliance scope expansion , unauthorized infrastructure that processes regulated data inadvertently expanding the customer's compliance scope without a corresponding expansion of controls
• Persistent infrastructure after engagement end , vendor-created resources that remain in the customer's environment after the vendor relationship concludes, unmonitored and unpatched indefinitely

Why this matters

Shadow cloud usage by vendors is one of the clearest examples of how third-party risk in cloud environments cannot be assessed at the vendor organization level alone. A vendor with excellent internal security practices, a mature cloud governance program, and a SOC 2 Type II report can still create ungoverned infrastructure in a customer's environment simply because the customer's IAM role did not prohibit it and the vendor's engineers defaulted to the path of least operational resistance. The risk is not in the vendor's environment , it is in yours, created by the vendor, invisible to your security controls.

The compliance dimension is particularly consequential. When a vendor provisions unauthorized resources in a customer's environment and those resources process regulated data , personal data under GDPR, cardholder data under PCI-DSS, protected health information under HIPAA , the customer's compliance posture has materially changed without anyone making a deliberate decision. The vendor's resource is in scope. The customer's controls may not cover it. The audit will find the gap regardless of how it was created.

From a security standpoint, vendor-created shadow resources represent an attack surface the customer cannot see. Vulnerability scanning that covers the known asset inventory does not scan resources that are not in that inventory. Security monitoring configured around known workloads does not alert on activity in unknown ones. An attacker who discovers vendor-created shadow infrastructure in a customer's environment has found a foothold that bypasses the customer's detection capabilities , not because those capabilities are inadequate for known resources, but because the resource they are exploiting was never on the list.

Where most teams get this wrong

The most consistent failure is granting vendors resource creation permissions as part of a general operational access grant without recognizing that resource creation is a fundamentally different capability from resource access. A vendor who needs to read from a specific S3 bucket and write results to another does not need the ability to create new EC2 instances, provision new storage, or deploy new networking configurations. But most IAM roles provisioned for vendor operational access include these capabilities by default because the engineer provisioning the role did not explicitly exclude them, and managed policies that include them are easier to apply than custom policies that do not.

The second failure is the absence of any monitoring for resource creation events in vendor-associated cloud activity. CloudTrail and equivalent logging services capture resource creation events , they record every EC2 instance launched, every S3 bucket created, every database provisioned. The data is available. But most organizations do not have alerts configured to notify them when vendor-associated identities create new resources, which means vendor shadow infrastructure is discovered through cost audits or accidental observation rather than through active governance.

• IAM roles provisioned for vendors including resource creation permissions that are never used for the authorized work but never explicitly excluded
• No alerting on resource creation events by vendor-associated identities , new infrastructure appears in the environment with no notification
• Asset inventory processes that do not tag vendor-created resources , making it impossible to distinguish authorized from unauthorized infrastructure
• No contractual prohibition on unauthorized resource creation , vendors operating without explicit boundaries on what they can provision
• No decommissioning requirement , vendor-created resources not removed at engagement end because nobody catalogued them during the engagement

What good looks like

In well-governed environments, vendor cloud activity is bounded not just by what the vendor is authorized to access but by what they are authorized to create. IAM roles provisioned for vendor access explicitly restrict resource creation permissions to what is operationally necessary, and any resource creation activity by vendor-associated identities generates an alert that triggers a review. The result is that vendor-created infrastructure is a known, documented, and governed asset rather than an accidental byproduct of vendor operations.

• IAM roles scoped to exclude resource creation unless explicitly required , vendors authorized to read, write, or modify specific resources without implicit permission to provision new ones
• Mandatory resource tagging enforced by policy , all resources created in the environment automatically tagged with owner, purpose, and creation date, making vendor-created resources immediately identifiable
• Alerts on resource creation events by vendor-associated identities , CloudTrail events triggering notification when vendor IAM roles launch new compute, storage, or networking resources
• Contractual resource creation governance , vendor contracts specifying what types of resources the vendor is authorized to provision, requiring pre-approval for any resource creation outside that scope
• Decommissioning inventory as part of engagement closure , vendor-created resources catalogued at the start of an engagement and explicitly decommissioned or transferred at its conclusion
• Periodic cloud resource audits that cross-reference the asset inventory against known authorized resources and flag unrecognized items for investigation

Tooling

Governing vendor shadow cloud requires tooling that provides visibility into what exists in your cloud environment, who created it, and whether it meets your security baseline , regardless of whether it was provisioned through a formal process or informally by a vendor engineer.

Cloud Asset Inventory , AWS Config, Azure Resource Graph, GCP Asset Inventory

These native services maintain a continuous inventory of all resources in a cloud environment, including who created them and when. AWS Config, in particular, enables rules-based compliance checking against all resources , flagging resources that do not meet tagging requirements, that are not covered by security scanning, or that belong to unrecognized IAM identities. For vendor shadow cloud governance, these tools provide the visibility layer that makes unauthorized infrastructure discoverable without waiting for a cost audit.

Cloud Security Posture Management , Wiz, Orca Security, Lacework

CSPM platforms provide agentless scanning of cloud environments that covers every resource in the inventory , not just resources that are in an approved list or covered by agent-based tools. When a vendor creates an EC2 instance that is not in the customer's known asset inventory, a CSPM tool will scan it, assess its security posture, and surface any vulnerabilities or misconfigurations alongside known resources. The discovery capability is as valuable as the security assessment , CSPM makes shadow resources visible.

Cloud Activity Monitoring , AWS CloudTrail, Azure Activity Log, GCP Admin Activity Audit Logs

Resource creation events are captured in cloud audit logs. Configuring alerts on resource creation events attributed to vendor IAM roles or service principals provides real-time notification when vendors provision infrastructure. The alert does not necessarily mean a policy violation has occurred , it means a governance review should happen. The vendor may have a legitimate reason for the resource. The point is that the customer finds out immediately rather than in a quarterly cost review.

Infrastructure Policy Enforcement , AWS Service Control Policies, Azure Policy, GCP Organization Policy

At the most restrictive end of the governance spectrum, cloud-native policy enforcement can be used to prevent specific classes of resource creation entirely , either for the entire account or specifically for vendor-associated identities. AWS Service Control Policies can deny resource creation API calls for identities that match a vendor pattern, making unauthorized resource creation technically impossible rather than merely detectable. For high-security environments or highly sensitive vendor relationships, this proactive enforcement is more robust than detection-and-response.

Governance challenges

The governance challenge with vendor shadow cloud is that it requires anticipating what vendors might do in addition to governing what they are authorized to do , a harder problem. Most governance frameworks are built around authorizing specific activities and preventing unauthorized ones. Shadow cloud arises in the space between those two categories: activities that are not explicitly authorized but are also not explicitly prohibited, performed by parties with legitimate access, for purposes that serve the customer's interests. Governing this space requires explicit boundary-setting that most vendor access provisioning processes do not perform.

Closing this gap requires shifting the default assumption from permissive to restrictive. Rather than granting vendor access and trusting that vendors will stay within reasonable bounds, mature governance starts from a minimal permission set and expands it only when specific operational needs justify specific additions. That shift requires more engineering effort at provisioning time, but it eliminates the entire category of ungoverned vendor infrastructure that arises when boundaries are never defined.

• Adopt a default-deny approach to resource creation permissions in vendor IAM roles , explicit permission to create specific resource types where required, implicit denial of everything else
• Require vendors to submit a resource plan before any engagement that involves infrastructure work in the customer's environment , what will be created, why, and what will be decommissioned when the work concludes
• Include unauthorized resource creation as a contract violation , not a misunderstanding to be resolved informally, but a defined breach of the vendor's operational obligations
• Conduct a cloud resource audit at engagement start and end , a baseline inventory of vendor-associated resources at kickoff and a decommissioning confirmation at close
• Assign a cloud governance owner for every significant vendor engagement , a named individual responsible for monitoring vendor cloud activity and reviewing resource creation alerts

If you are a small team

Start by auditing every IAM role currently assigned to a vendor and identifying which ones include resource creation permissions , EC2 run instances, S3 create bucket, RDS create DB instance, and equivalent permissions in Azure and GCP. For every role that includes these permissions, assess whether resource creation is actually required for the vendor's authorized work. In most cases, it is not , and removing those permissions immediately reduces your shadow cloud exposure without affecting the vendor's ability to perform their authorized functions.

• Run a resource creation permission audit on all vendor IAM roles using AWS IAM Access Analyzer or equivalent , identify which vendor roles can create new infrastructure
• Enable resource creation alerts in CloudTrail for vendor-associated identities , a simple CloudWatch rule that triggers on CreateBucket, RunInstances, or equivalent events attributed to vendor roles
• Add mandatory resource tagging as an account-level policy , all resources must have an owner tag at creation, making untagged or vendor-tagged resources immediately visible in the inventory
• Add one question to your vendor onboarding process: 'Does your work require creating new cloud resources in our environment, and if so, what types and for what purpose?'

What to require

Ask directly:

"Does your work in our cloud environment require creating new resources , compute, storage, networking, or otherwise? If so, what resources, why, and what is your process for decommissioning them when the work concludes?"

"How do you ensure that your engineers working in our cloud environment stay within the scope of authorized activities and do not provision resources outside what has been explicitly approved?"

"What is your process for inventorying and cleaning up resources you have created in a customer's environment at the end of an engagement?"

Expect as evidence

• A clear description of what resource types the vendor requires access to create, with operational justification
• Evidence of internal controls preventing vendor engineers from provisioning unauthorized resources in customer environments
• A defined decommissioning process for vendor-created resources at engagement close
• Willingness to operate within a tagged, inventoried, monitored resource creation framework

A vendor who responds to the resource creation question with 'we just use whatever we need to get the work done' is describing an absence of governance boundaries. That is a vendor whose cloud activity in your environment needs to be constrained by your controls, because they have not constrained it themselves.

How to evidence it

Cloud asset governance , including governance of vendor-created resources , is increasingly examined in SOC 2 audits, cloud security assessments, and regulatory reviews. Demonstrating due diligence requires evidence that your organization actively manages what exists in your cloud environment, not just what was formally provisioned through approved processes.

• Cloud asset inventory records showing all resources are tagged, attributed, and covered by security controls
• IAM role permission audits confirming vendor roles are scoped to exclude unauthorized resource creation
• Resource creation alert configurations and response records demonstrating active monitoring of vendor cloud activity
• Vendor engagement records documenting approved resource types and decommissioning confirmations at engagement close
• Periodic cloud resource audits with findings and remediation records

Key Takeaway

Shadow cloud usage by vendors is not a story about bad actors. It is a story about authorized parties operating inside an environment with no walls. When you grant a vendor access to your cloud environment without explicit resource creation boundaries, you have not governed what they can build there , you have trusted them to self-govern, in an environment they do not own, against standards they have never seen. The infrastructure they create in that space is yours , your compliance scope, your attack surface, your billing, your audit finding. Defining boundaries before access is granted costs one engineering conversation. Discovering ungoverned vendor infrastructure after the fact costs significantly more.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations