How CoverOps touches your cloud

The access model

CoverOps does not host your workloads. It operates on your infrastructure through a role you create inside your own AWS, Azure, GCP, DigitalOcean or Oracle Cloud account, from a policy CoverOps generates for you as Terraform, CloudFormation or a CLI script: an IAM role with an external ID on AWS, a service principal with the Reader role on Azure, a viewer service account on GCP, a custom-scoped read token on DigitalOcean, or an API key on a read-only group in Oracle Cloud. The default is read-only.

On AWS we store no access keys at all: each sync assumes your role and gets short-lived credentials that expire on their own. On Azure, GCP, DigitalOcean and Oracle Cloud the secret, key or token is encrypted at rest with AES-256-GCM and used only by sync jobs. Either way the delegation lives in your account and you can revoke it at any moment.

What the role is permitted to do

• Read your resource inventory, CPU utilisation and cost, in order to price waste
• On AWS, with the write access you granted: stop an idle instance, rightsize an instance, snapshot and delete an unattached volume, each raised as a proposal
• Apply a proposal only after a named person approves it, and roll it back on request
• On Azure, GCP, DigitalOcean and Oracle Cloud: read only; fixes are advice you apply yourself

What it is not permitted to do

• Hold root or owner credentials for your cloud account
• Change a resource you have not tagged coverops:managed=true
• Read application data, database contents, or object storage payloads
• Create new identities or widen its own permissions
• Continue operating after you revoke the role

Visibility and audit

Because CoverOps acts through your provider's own API, every action it takes is recorded in your CloudTrail or Azure Activity Log alongside everything else. You do not have to trust our logs. The authoritative record is one you already own and already monitor.

On top of that, CoverOps keeps its own change history: what it proposed, who approved it, and what the result was, in the audit log, which you can export as JSON from Settings. When CoverOps staff enter your organisation to help, they must give a reason, the visit is time-limited, and it is written to the same audit log.

What data we hold

To do its job CoverOps stores infrastructure metadata: resource identifiers, configuration, utilisation, cost, proposals with their rollback snapshots, and change history. It also stores the account details of the people on your team who use it.

It does not store your application data, your customer records, or the contents of your databases and buckets. Those are never read, and the role is not permitted to read them. Full detail is in the privacy policy.

Revoking access

Delete the role. That is the whole procedure, and it takes effect immediately because the permission lived in your account rather than ours.

Your infrastructure keeps running and your pipelines continue to deploy, because none of it ever ran on us. Nothing degrades because CoverOps stopped being able to reach it. See portability for why that is a design constraint rather than a courtesy.

Reporting a vulnerability

If you believe you have found a security issue in CoverOps, please email office@coverops.dev with enough detail to reproduce it. We acknowledge every report within 2 working days and keep you updated until it is fixed. Our contact details are also in /.well-known/security.txt.

We do not currently run a paid bug bounty. We will credit you publicly if you would like us to, and we will not take legal action against good-faith research that respects user privacy and avoids service degradation.

Questions this page did not answer

Security reviews always have a question the vendor page missed. Send yours to our team and we will answer it directly, including when the answer is that we do not support something yet.