Skip to main content
When you connect a source, Amnify requests the access it needs to assess that source’s security posture — and, for GitHub, to prepare fixes for you to review. This section explains what Amnify requests for each provider and why. Two principles hold across every provider:
  • Least privilege. Amnify requests only the access its work requires. For the cloud providers that means strictly read-only access — Amnify reads resource and identity configuration to assess posture and never creates, modifies, or deletes anything. GitHub is the exception: to deliver fixes it also needs write access, but that write is tightly bounded. Amnify only ever opens a pull request for you to review — it never pushes to your default branch, and nothing merges without your approval.
  • Customer-granted and revocable. You grant access to Amnify on your side and can revoke it at any time. Wherever the provider allows it the grant is keyless, with no long-lived secret to hand over; where you do supply a credential, it is one you control and can rotate or revoke.
Amnify organizes each provider into tiers. Tier 1 is the minimum needed to assess a source. Later tiers are optional and widen coverage, for example into the identity layer.

Azure

Read-only access via Amnify Enterprise Application.

AWS

Read-only access via an AssumeRole.

GCP

Read-only access via a Service Account.

GitHub

Read and write via Amnify GitHub App.