Security & access
You’re about to give a stranger access to production. Here’s exactly what that means.
It’s the right thing to be careful about, so this page answers it properly rather than making you ask. The short version: read-only, metadata only, one named person, deleted after 30 days, revocable by you in one click.
Read-only, always
The role we ask for grants no write, delete, or modify permission anywhere. Even if we wanted to change something in your account, the credentials would not allow it.
No data, no secrets, no code
The policy covers billing and resource metadata — instance sizes, volume types, retention settings. It grants no access to object contents, database rows, environment variables, or source code.
One engineer, start to finish
The same person runs your audit from the moment access is granted to the moment the report lands. Your credentials are not shared with a team, a contractor, or an offshore bench, because there isn't one.
You revoke it in one click
Access arrives as a CloudFormation stack you control. Delete the stack when the audit is delivered and every permission disappears with it.
Your data
Six questions, answered without hedging.
- What we collect
- Cost and usage data, plus resource configuration metadata — sizes, types, ages, retention and utilisation settings.
- What we never collect
- Object contents, database contents, application logs, secrets, environment variables, source code, or customer PII.
- Where it lives
- An encrypted disk on a single workstation, plus the delivered report. Nothing is loaded into a third-party analytics or FinOps platform.
- Who sees it
- Only the engineer running your audit. No subcontractors, no subprocessors, no AI training.
- How long we keep it
- Working data is deleted 30 days after the report is delivered. You can ask for immediate deletion at any point, including mid-audit.
- What you keep
- The report, the walkthrough recordings, and the raw findings. They're yours; there's no platform to lose access to.
Nothing hidden
The actual IAM policy we ask for.
Not a summary of it — the policy itself. Read it, hand it to your security team, or diff it against what we send you. Every action in it is a Describe, Get, or List.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PlainstackReadOnlyAudit",
"Effect": "Allow",
"Action": [
"ce:Get*",
"ce:Describe*",
"ce:List*",
"cur:Describe*",
"compute-optimizer:Get*",
"compute-optimizer:Describe*",
"support:DescribeTrustedAdvisor*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudwatch:Describe*",
"ec2:Describe*",
"rds:Describe*",
"rds:ListTagsForResource",
"elasticache:Describe*",
"es:Describe*",
"es:List*",
"s3:GetBucketLocation",
"s3:GetBucketTagging",
"s3:GetLifecycleConfiguration",
"s3:ListAllMyBuckets",
"elasticloadbalancing:Describe*",
"autoscaling:Describe*",
"lambda:List*",
"lambda:GetFunctionConfiguration",
"ecs:Describe*",
"ecs:List*",
"eks:Describe*",
"eks:List*",
"dynamodb:Describe*",
"dynamodb:List*",
"logs:Describe*",
"savingsplans:Describe*",
"savingsplans:List*",
"organizations:Describe*",
"organizations:List*"
],
"Resource": "*"
}
]
}Delivered as a CloudFormation stack · Delete the stack to revoke
FAQ
What security teams ask.
Can you see the contents of our S3 buckets or databases?
No. The policy grants s3:ListAllMyBuckets and configuration reads such as lifecycle rules and tagging — it does not grant s3:GetObject, so bucket contents are inaccessible. The same applies to databases: we can read that an RDS instance is db.r6g.xlarge with Multi-AZ enabled, but nothing inside it.
Will you change anything in our account?
We can't. There is no write permission in the policy. Every recommendation is delivered as something your team executes, and if you'd rather we implement changes ourselves, that's a separate engagement with separate, explicitly scoped credentials you grant at that time.
Do you sign NDAs?
Yes, gladly, and we'll sign yours rather than insisting on ours. If you don't have one, we have a mutual NDA we can send over before any access is discussed.
What if our security team wants to review the policy first?
That's the right instinct, and the full policy is published on this page for exactly that reason. Send it to them before you book anything. We're also happy to join a call with your security lead.
Can we scope access to a single account or region?
Yes. For AWS Organizations we usually ask for read access at the management account for billing data plus the member accounts you want covered. If you'd rather start with one account, that works — it just narrows what the audit can see.
Do you carry insurance?
Ask on the call and we'll share current coverage details. For engagements where it matters, we can align coverage to your contract requirements before signing.
Still have a question about access?
Ask before you book — it’s a better use of both our time than finding out on the call. Security questions get answered the same day.