A security platform that cannot see your cloud accounts, repositories and identity providers will miss most of your attack surface. A security platform that can change them is itself part of your attack surface. The resolution is not complicated, but it has to be deliberate: grant read-only access, scoped to what the tool needs, through the mechanism each platform provides for exactly that purpose.

What read-only buys you#

Read access to a cloud account reveals the things external discovery can only guess at: every storage bucket and its policy, every load balancer and the targets behind it, every function with a public URL, every security group that opens a port to the world. It turns an inventory built from the outside into a complete one. It also keeps the blast radius of the security tool itself at zero. If its credentials leak, an attacker learns about your environment; they cannot alter it.

AWS#

Create a dedicated IAM role in each account and grant it through a trust policy to the tool's account, with an external ID to prevent the confused-deputy problem. Attach AWS's managed SecurityAudit policy, which was written for this purpose, or ViewOnlyAccess if you want a broader read of resource configuration. Do not use ReadOnlyAccess without reviewing it: it includes permission to read object contents from S3, which most security tools do not need. Enable CloudTrail on the role so every call it makes is logged.

Azure#

Register the tool as an enterprise application and assign the built-in Reader role at the management group or subscription level. Reader cannot change anything and cannot read secrets in Key Vault, which is the right default. If the tool needs directory information for identity discovery, add Directory Readers in Entra ID rather than widening the Azure role.

Google Cloud#

Create a service account in a dedicated project, grant it the Viewer role at the organization or folder level, and let the tool authenticate with workload identity federation rather than a downloaded key. Viewer is broad; if you want a narrower grant, Security Reviewer plus Cloud Asset Viewer covers most discovery needs. Keep key creation disabled.

GitHub#

Install the tool as a GitHub App, not with a personal access token. Apps request explicit permissions, and read-only on contents, metadata and administration is enough to discover repositories, exposed secret patterns and workflow configuration. Approve the installation for selected repositories first, then widen it. Review the app's permissions in the organization settings every quarter.

Identity providers#

For Okta, Entra ID and Google Workspace, read-only administrator roles exist and should be used. The goal is to see users, groups, applications and sign-in policies, which is what an attacker maps first after an initial foothold. Nothing about discovery requires writing to a directory.

Before you grant anything#

  • Ask the vendor for the exact policy document or permission list, and read it.
  • Confirm how the credential is stored and rotated on their side, and whether they support federation instead of long-lived keys.
  • Confirm that every action is logged in your account, not only in theirs.
  • Check that the tool cannot modify anything through a second mechanism, such as a deployment integration, without a separate grant.

SecureX360 connects this way everywhere: a read-only IAM role on AWS, Reader on Azure, Viewer on Google Cloud, a read-only GitHub App, read-only admin roles in identity providers. AI applications are the exception, because there is nothing to connect to; they are tested from the outside, as an unauthenticated user would. What you connect defines the scope, and every test stays inside it.