If you are the person who holds the credentials, a cost tool is a security decision before it is a cost decision. You are being asked to grant a third party access to your cloud accounts, and the reasonable default is no.
This is what the request should look like if the answer is going to be yes.
Reading a bill requires reading, and nothing else
Cost and usage data is a read operation. There is no legitimate reason for a monitoring tool to create, modify or delete anything in your account in order to report what you spent.
That principle disposes of most of the debate. If a permission is not required to read billing data, it should not be in the policy.
What each provider actually needs
AWS. A cross-account IAM role, assumed with an external ID, granting read access to Cost Explorer and Cost and Usage Reports. The AWS-managed Billing read policy or a narrow custom policy covering ce:Get*, cur:Describe* and organizations:List* is sufficient. No access keys, because a role with an external ID is both revocable and unusable by anyone else.
GCP. A service account with roles/billing.viewer on the billing account, and roles/bigquery.dataViewer on the billing export dataset if you use detailed export. Project-level permissions are not required to read billing.
Azure. Cost Management Reader at the billing scope. This is a purpose-built role and there is no reason to grant anything broader.
AI and SaaS providers. A read-only or usage-scoped key where the provider offers one. Several — OpenAI among them — distinguish admin keys from usage keys; take the narrower one.
That list is complete. Any additional permission needs a specific justification tied to a feature you actually want.
The requests that should end the conversation
Write permissions of any kind. Sometimes framed as "so we can apply recommendations" or "to tag resources for you". Both are real features, and both should be a separate, explicitly-granted permission — not bundled into the connection you set up to read a bill.
An agent in your cluster or on your hosts. Some categories of cost tooling genuinely need this, notably Kubernetes-level allocation. Cloud and AI billing does not. An agent expands your attack surface and your patching burden for data available via an API.
Long-lived root or organisation-owner credentials. A tool that asks for a root access key has not thought about your security posture, which tells you something about the rest of the product.
Access keys where a role is available. Keys are copied, leaked and rarely rotated. A role with an external ID can be revoked in one action and cannot be replayed elsewhere.
Blanket read on everything. ReadOnlyAccess on AWS covers your data, not just your bill. Read-only is not the same as narrow, and the difference matters — it is the gap between seeing what you spent and seeing what is in your S3 buckets.
The questions worth asking a vendor
Beyond the permission list, four questions separate serious answers from marketing.
What exactly do you store? Cost and usage metadata is one thing; resource names, tags and query text can carry business or personal data. Ask what is retained and for how long.
Where is it processed and stored? Relevant for GDPR and for any customer contract with data residency terms.
How do I revoke access? The answer should be one action on your side that takes effect immediately, not a support ticket.
Do you have SOC 2, and can I see the report? The report matters more than the badge.
Why this is usually the deciding factor
If you hold the credentials, you are also the person who will be asked why a third party had access when something goes wrong. A tool that can be connected with a revocable read-only role is a decision you can make yourself in an afternoon. A tool that needs an agent and write access is a security review, an architecture discussion, and probably a quarter.
That difference is often the entire reason one tool gets adopted and another does not, regardless of features.
StackSpend is read-only and agentless by design: a scoped role or a read-only key per provider, revocable by you at any time, with nothing running inside your infrastructure. The whole estate can be connected in an afternoon without a security review blocking it — which is deliberate, because that is usually the constraint that matters.
FAQ
What permissions does a cloud cost tool actually need?
Read access to billing and usage data only. On AWS that is a billing-scoped role assumed with an external ID; on GCP a service account with Billing Account Viewer; on Azure a Cost Management Reader. Nothing else is required to report spend.
Should a cost monitoring tool need an agent?
Not for cloud or AI billing, which is available through provider APIs. Agents are justified for in-cluster allocation such as Kubernetes cost splitting, but that is a different problem from reading a bill.
Is ReadOnlyAccess on AWS safe to grant?
It is read-only, but it is far broader than billing — it exposes data across services, not just cost. Prefer a billing-scoped policy. Read-only and least-privilege are not the same thing.
Why use an external ID for the IAM role?
It prevents the confused deputy problem: without it, anyone who learns your role ARN could attempt to assume it. The external ID ties the trust relationship to your specific tenant and makes the role unusable elsewhere.
