Cloud security · AI data exposure · 2026-05-12
Bedrock and Foundry can quietly expose your AI data.
A walkthrough on auditing AWS Bedrock and Azure AI Foundry for over-permissive sharing patterns that can expose model training data, prompt history, or fine-tuning datasets.
If your business has rolled out generative AI in the last 18 months, there is a real chance sensitive data is moving through places nobody has reviewed closely. Not in a movie-villain way. In a quiet, configuration-drift way that shows up when prototypes become production.
Here are the patterns I would check first when reviewing a growing business using AWS Bedrock or Azure AI Foundry.
1. Bedrock fine-tuning jobs pointing at public S3 buckets
A common pattern: a team prototypes a fine-tuned model. They drop the training data into an S3 bucket. Six months later, the prototype is in production and nobody re-audited the bucket ACLs.
When I review this, I start by joining model customization jobs with the storage locations they reference, then checking whether those buckets or storage accounts allow broad access. Sometimes the bucket is empty now; sometimes old training exports, prompt logs, or customer files are still sitting there.
The Steampipe query I run looks roughly like this (sanitized):
select
job.job_name,
job.training_data_uri,
bucket.name,
bucket.acl,
bucket.public_access_block
from
aws_bedrock_model_customization_job as job
inner join aws_s3_bucket as bucket
on job.training_data_uri like '%' || bucket.name || '%'
where
bucket.acl @> '[{"Grantee":{"URI":"http://acs.amazonaws.com/groups/global/AllUsers"}}]'
or bucket.public_access_block is null;
If it returns rows, that's the finding. Fix is in three steps: enable account-level Block Public Access, remove the bucket ACL, audit CloudTrail for any access in the last 90 days to that bucket.
2. Azure AI Foundry workspaces with "anyone in tenant" sharing
Foundry's default workspace sharing model is more permissive than most teams realize. A workspace marked for "anyone in the tenant" doesn't just expose model artifacts; it can expose the prompt history of every interaction.
If your tenant has more than 50 users, "anyone in tenant" is the wrong default. Tighten to specific Compute Contributor or AI Developer roles. Add a separate read-only Reviewer role for compliance audit access.
Foundry also doesn't enforce model endpoint authentication by default. If you have a production endpoint that anyone in the tenant (or worse, anyone with the URL) can hit, you're paying per inference for unauthorized access.
3. OpenAI / Bedrock API keys in plaintext config tables
This one is older but somehow still common. A developer ships an OpenAI integration. The API key gets dropped into an application config table because that was the path of least resistance for the deadline.
Six months later, the key has access to your entire OpenAI org account, can be read by every service account that touches the config table, and has never been rotated. I find these by querying config tables (DynamoDB, Cosmos DB, app settings) for strings matching sk- or sk-ant- or AzureOpenAIKey.
Move them to a secrets manager. Rotate immediately if they've ever been in plaintext. Audit the key's usage log to see if it was accessed outside expected service identities.
How to check this yourself in an afternoon
- Install Steampipe + the AWS, Azure, and Microsoft 365 plugins.
- Run targeted Bedrock / Foundry over-sharing checks; see example findings for the shape.
- Cross-reference against any S3 / Blob / Storage Account marked public, and any Foundry workspace marked tenant-wide.
- Don't shoot the messenger if you find something.
If running this yourself is not realistic, this is exactly what the Switchback AI & Cloud Security Review covers. Fixed scope, 5-7 days, plain-English findings, your IT team gets a fix list they can actually execute. No enterprise sales motion; no six-month consulting project; no committed retainer.
Book a 30-min call See sample findings
Written by Logan French, founder of Switchback Cyber. Opinions here are mine.