Cloud

Cloud is section 05 of the Connections page (Reagent → Connections). It holds the three hyperscaler connections, AWS, Azure, and GCP, and two cloud security posture connections, Wiz and Upwind.

The hyperscaler connections are read-only by default. Reagent reads inventory and audit logs and changes nothing in your accounts. Each hyperscaler credential also backs alias tiles that need one extra permission grant and no new credential:

Wiz and Upwind are their own connectors. Each reads from a security product that is already watching every cloud you onboarded there, so Reagent gets the posture and runtime view of all those clouds through one credential.

Connecting any tile requires the manage integrations permission (Administrator, MSSP Admin, or a custom role that includes it). AWS and GCP offer a Test Connection button; run it before saving.

In the signal tables below, live-validated means the signal has been confirmed end to end against a live account. Template means the signal ships with the connector but has not yet been confirmed against a live account.

AWS

Connector: aws-aws · Auth: Cross-account role assumption (Zaun-managed role, or IAM user access keys) · Requires: any plan

Reagent reads your AWS estate through a chain of IAM roles. It assumes a Delegated Admin role in your Security Tooling account, and that role assumes a read-only Execution Role in each account you put in scope. From there Reagent inventories Bedrock models, Bedrock Agents, AgentCore gateways and workload identities, and Bedrock usage in every in-scope account and region.

Lights up: AI Control-Plane Activity, Deployed Models, AI Prompts & Model Routing/Use, Custom Agents on Builder Platforms, MCP Servers in Cloud Applications, Platform Agent Registries.

The Bedrock and AgentCore reads need additional IAM policies on top of the base Execution Role. Each alias tile shows its own: the AWS Bedrock tile for Bedrock inventory, usage, and cost, and the AWS AgentCore Gateway tile for AgentCore gateways, targets, the policy engine, and workload identities. Both tiles use this connection's credential and show Connected as soon as AWS does; data flows once the policy is attached. See AI tools and AI gateways.

How the access chain works

Zaun principal (or your IAM user)
  > assumes the Delegated Admin role in your Security Tooling account (with External ID)
    > assumes the Execution Role by name in each in-scope account
      > reads AWS APIs in that account and region

The Delegated Admin role assumes the Execution Role by name with a wildcard account ID (arn:aws:iam::*:role/<ExecutionRoleName>), so a single statement covers every account, current and future. You never list per-account role ARNs. Each account is scoped by the trust policy on its own Execution Role, which the template sets, not by a list on the Zaun side.

Two ways to start the chain:

• Zaun-managed role (recommended). Zaun's own principal assumes your Delegated Admin role directly. No IAM user, no stored access keys. Available only where your Zaun deployment exposes a principal ARN; otherwise the option is greyed out and the form defaults to Access keys.
• Access keys. An IAM user in your Security Tooling account whose only permission is sts:AssumeRole on the single Delegated Admin role ARN. It is the only long-lived credential, and it never references anything per account.

Before you start

• You need the manage integrations permission in Reagent.
• Use your Security Tooling (central or hub) account for the Delegated Admin role and, on the access-keys path, for the IAM user. Do not use the Organizations management account.
• You need rights to create CloudFormation stacks in the Security Tooling account and in each account Reagent should monitor, or CloudFormation StackSets rights for many accounts.
• Decide which accounts and regions are in scope. Reagent reads only the accounts you list, and only where the Execution Role is deployed.
• The Connections page links both CloudFormation templates and pre-fills their parameters. Launch Stack opens CloudFormation in a new tab with the template loaded and parameters pre-filled; review, then create. Download YAML lets you inspect a template first.

Setup: Zaun-managed role (recommended)

1. In Reagent, open Connections and click AWS. Under Authentication Method choose Zaun-managed role. The form shows the Zaun principal that your Delegated Admin role will trust; Launch Stack pre-fills it as ZaunPrincipalArn.
2. The form pre-fills a random External ID. Keep it, regenerate it, or paste your own. Launch Stack pre-fills whatever is in the field as ExternalId, and the template's parameter must match this field byte-for-byte.
3. Deploy the Delegated Admin role in your Security Tooling account, not the Organizations management account. In the Delegated Admin Role step click Launch Stack, review the pre-filled parameters, and create the stack. Leave the stack's Tags section empty. This role trusts the Zaun principal with the External ID and can assume the Execution Role by name across every account in your organization.
4. Deploy the Execution Role in each account Reagent should monitor. For one account click Launch Stack (1 account). For many, use CloudFormation StackSets: Copy StackSet info gives you the template URL and parameters to paste into the StackSet wizard. The same role name is created in every account. Deploy to one region only; IAM is global.
5. Back in Reagent, enter the Account ID and Region, confirm the Delegated Admin Role name and Execution Role Name (both pre-filled with the names the templates create), confirm the External ID, then add every account and its regions under In-Scope Accounts & Regions.
6. Click Test Connection. When both hops pass, save. No access keys are involved at any point.

Setup: access keys

1. In your Security Tooling account, not the Organizations management account, create an IAM user for Zaun (a user, not a role). Give it one permission: sts:AssumeRole on the single Delegated Admin role ARN you create in the next step. Nothing per account.
2. In the Reagent form choose Access keys, optionally enter the IAM User ARN so it pre-fills the template, and deploy the Delegated Admin role in your Security Tooling account with Launch Stack or Download YAML. This is the role Zaun assumes first. Its policy lets it assume the Execution Role by name across every account in your organization, so you never list individual account ARNs.
3. Deploy the Execution Role in each account Reagent should monitor, one click for a single account or StackSets for many, exactly as in the Zaun-managed path.
4. Create access keys for the IAM user: IAM → Users → Security Credentials → Create access key.
5. In Reagent, enter the Access Key ID and Secret Access Key along with the fields below, click Test Connection, and save.

Fields

Permissions

The exact, validated read-only policy ships inside the Execution Role template. The table below is the reference the Connections page shows, by service; the template is authoritative. The Bedrock and AgentCore policies are separate and are granted from their alias tiles.

Optional: set the Execution Role template's IncludeResponseActions parameter to true (default false) to add the write permissions that response actions use. Leave it off for a read-only connection.

What Reagent reads

• Bedrock control-plane activity from CloudTrail, inference profiles, provisioned throughput, and cost and usage, per in-scope account and region.
• Bedrock Agents, AgentCore gateways, and AgentCore workload identities.
• The organization's account list, when the management account is in scope.
• Every call shows up in CloudTrail as a role session named with your Role Session Name Prefix, so you can audit what Reagent read.

Azure

Connector: azure-monitor · Auth: Service principal (OAuth2 client credentials) · Requires: any plan

Reagent reads your Azure subscriptions through one app registration. It uses Azure Resource Manager and Resource Graph to inventory Azure OpenAI accounts and model deployments, Log Analytics for KQL reads, and Cost Management for billed AI spend. The roles below are all read-only.

Lights up: AI Prompts & Model Routing/Use, Deployed Models.

The Azure AI Foundry and Azure AI Foundry Gateway tiles use this credential. Connect Azure first; those tiles show Connected as soon as Azure does, and their data flows once the extra roles are granted. See AI tools and AI gateways.

Before you start

• You need the manage integrations permission in Reagent.
• Rights to register an application and create a client secret in your Entra ID tenant.
• Rights to add role assignments on each in-scope subscription and on your Log Analytics workspace.
• The Workspace ID of the Log Analytics workspace Reagent should query.
• The subscription IDs you want in scope. Reagent creates one read pipeline per subscription, and the first row is the default subscription for ad-hoc ARM operations.

Setup

1. Go to Azure Portal → App registrations → New registration and register an application for Zaun.
2. Under Certificates & secrets, create a new client secret. Copy the Value column immediately; Azure only shows it once. Do not copy the Secret ID, the UUID-shaped value next to it.
3. Grant Reader at subscription scope for each subscription you will list: Subscription → Access control (IAM) → Add role assignment → Reader, assigned to your app registration. Required for Activity Log, Resource Graph, and NSG reads.
4. Grant Log Analytics Reader at workspace scope: Log Analytics workspace → Access control (IAM) → Add role assignment → Log Analytics Reader, assigned to your app. Required for KQL queries.
5. Grant Cost Management Reader for each subscription: Subscription → Access control (IAM) → Add role assignment → Cost Management Reader, assigned to your app registration. Required for billed AI spend. Reader is not sufficient.
6. Collect the values: Tenant ID from Azure AD → Overview → Tenant ID, Client ID from App registration → Application (client) ID, the client secret Value, Workspace ID from Log Analytics workspace → Overview → Workspace ID, and your subscription IDs.
7. In Reagent, open Connections, click Azure, enter the values, add each subscription under In-scope Subscriptions, and save.

Fields

Permissions

What Reagent reads

• Azure OpenAI accounts and model deployments in each in-scope subscription.
• Activity Log, Resource Graph, and network security group state per subscription.
• Log Analytics query results from the workspace you name.
• Billed AI spend per subscription.

GCP

Connector: gcp-security · Auth: Service account JWT bearer (JSON key), or keyless Workload Identity Federation from Okta or Entra · Requires: any plan

Reagent reads your Google Cloud organization through a service account that lives in one admin project and is granted roles at the organization node. The org-wide asset sweep and IAM-policy search cover every project under the Discovery Scope. Vertex inventory and usage, Model Armor, Cloud Run, and GKE are read on the admin project only. The connector covers Cloud Audit Logs, IAM, Compute Engine, Resource Manager, and Cloud Asset Inventory.

Lights up: AI Prompts & Model Routing/Use, Deployed Models, Custom Agents on Builder Platforms, MCP Servers in Cloud Applications, Platform Agent Registries, IDE Coding Agents.

The Google Vertex and Google Agent Gateway tiles use this credential. Connect GCP first; those tiles show Connected as soon as GCP does, and their data flows once the extra roles are granted. See AI tools and AI gateways.

Admin project and Discovery Scope

These are two different fields, and both are needed.

• Admin project ID is the project ID (not the number), from the Cloud Console project selector or the service account key JSON. The service account lives here, the APIs are enabled here, and every call bills and counts quota here, including org-wide reads. It is Zaun's home base in your organization, not the limit of what it can be granted. Any project you administer will do.
• Discovery Scope is how far Zaun can see. Set it to your organization id from gcloud organizations list, written as organizations/<id>, once the roles are granted at the organization node. A folder works too, written as folders/<id>. With it set, the cross-project asset sweep and IAM-policy search cover every project beneath the node.

Leave Discovery Scope blank and Zaun reads the admin project and nothing else, however broadly the roles were bound. The connection tests green either way, so nothing later tells you which one you got. GCP cannot enumerate projects you have not granted on, so AI in a sibling project is simply absent rather than flagged, which looks identical to a clean estate.

Before you start

• You need the manage integrations permission in Reagent.
• Someone holding roles/resourcemanager.organizationAdmin on the organization must bind the roles at the organization node. Project Owner is not enough, so this step often belongs to a different person than the rest of the setup.
• An admin project you administer.
• Your organization id from gcloud organizations list, or the folder your platform team scopes grants to.
• A choice between a service account JSON key and keyless Workload Identity Federation. WIF changes how Zaun proves who it is; it does not change what that identity is allowed to read, so the roles are the same on both paths.

Setup: gcloud CLI

The Connections page generates a setup script for the environment. It enables the APIs, creates the service account, binds every role at the Discovery Scope, verifies the bindings, and creates the key, in one pass.

1. In Reagent, open Connections, click GCP, and open the gcloud CLI setup tab. Enter your Admin project ID and Organization ID (discovery scope) to prefill the script. The script binds at the scope you give, so the permissions cover every project beneath it, now and in future. Left blank, it binds on the project alone and Zaun sees only that project.
2. Click Copy to paste the script straight into a shell, or Download .sh and run it with bash. Downloading is the safer choice if you want to read it through first, and it is the one to send to whoever administers the organization.
3. Run it as someone holding roles/resourcemanager.organizationAdmin on that organization. Project Owner is not enough to bind at the org node.
4. The script is bash and runs as-is on macOS (including the stock bash 3.2), Linux, and Cloud Shell. On Windows, use Cloud Shell, the terminal icon in the Cloud Console: gcloud is already installed and you are already signed in. WSL or Git Bash also work. PowerShell and cmd do not.
5. When it finishes, upload or paste the zaun-key.json it produced into the Service Account JSON Key field, set Discovery Scope to your organization id, click Test Connection, and save.

The script is safe to re-run. It checks that it can reach the scope before touching anything, waits for the service account to propagate, retries each role binding, and verifies every role is bound before creating a key, so a partial failure cannot hand you a credential that authenticates but reads nothing. It stops at the first role it cannot grant and prints the reason.

One grant the script cannot do for you: read access on the Cloud Billing export dataset (roles/bigquery.dataViewer on that one dataset). The script prints the command; run it yourself, as described in step 4 of the manual setup. Without it every AI cost reads as zero.

Setup: manual

1. Enable the required GCP APIs on the admin project: APIs & Services → Enabled APIs & Services → + Enable APIs and Services. The full list is under Permissions below. A call against an API you skipped fails with SERVICE_DISABLED even when the credential and roles are correct.
2. Create a service account. In the admin project, go to IAM & Admin → Service Accounts → Create Service Account. Name it something like zaun-security.
3. Grant the required IAM roles at the organization node, where they inherit to every project beneath it: gcloud organizations add-iam-policy-binding ORG_ID --member="serviceAccount:SA_EMAIL" --role=ROLE for each of the twelve roles under Permissions below. Granting at the project level also works, but then Zaun sees only that one project. Prefer the organization node, or a folder if your platform team scopes grants that way.
4. Grant read on the Cloud Billing export dataset. roles/bigquery.jobUser from step 3 only lets Zaun run a query, not read the result. Find the billing export dataset with bq ls (it may live in a different project) and grant roles/bigquery.dataViewer on that dataset only: bq add-iam-policy-binding --member='serviceAccount:SA_EMAIL' --role=roles/bigquery.dataViewer 'PROJECT:BILLING_DATASET'. This grant cannot be inherited from the organization node. Skip it and every AI cost reads as zero.
5. Download the service account key JSON. On the service account's Keys tab, click Add Key → Create new key → JSON. Save the file securely. Skip this step if you use Workload Identity Federation.
6. (Optional) Configure Workload Identity Federation. Set up a Workload Identity Pool and link it to your identity provider (Okta or Entra). This replaces the key entirely; there is no key to rotate or leak. The three values you need are in the WIF section below. Still grant the roles in steps 3 and 4.
7. Enter credentials, set the Discovery Scope, and test. Upload the JSON key file (or paste it), enter your Admin project ID, set Discovery Scope to your organization id, and click Test Connection. Zaun's JWT bearer flow requests the read-only OAuth scopes listed below; review them before saving.
8. (Optional) Turn on Vertex AI Data Access audit logging. See the section below before you decide.

Fields

Workload Identity Federation

WIF is keyless. Zaun exchanges a token from your IdP for a Google token through STS:

1. Zaun requests an access token from your IdP app.
2. It exchanges that token with Google STS for a federated token.
3. It impersonates the service account for a Google access token.
4. It uses that token for GCP API calls.

Zaun caches the IdP token and refreshes it on its own. This path needs nothing else configured in Zaun first. Three things are needed: the pool's audience, the service account to impersonate (the same zaun-security account, which still needs every role), and the client ID, client secret, and token URL of an app in your IdP.

Permissions

Grant all twelve roles at the organization node. All but one are read-only.

APIs to enable on the admin project:

OAuth scopes (read-only):

These scopes are sent on every token exchange in the service-account JWT to Google STS flow. All are read-only. Final access is the intersection of these scopes and the IAM roles granted to the service account.

What Reagent reads

• Vertex model usage from Cloud Monitoring, Vertex endpoints and model registry, and Vertex Agent Engine.
• Cloud Asset Inventory AI resources and IAM policy across every project under the Discovery Scope.
• Agent gateways, Discovery Engine agents, and Gemini Code Assist logs.
• Model Armor, Cloud Run, and GKE on the admin project.
• Cloud Audit Logs, IAM, Compute Engine, and Resource Manager metadata.

Optional: Vertex AI Data Access audit logging

It is off by default. While it is off, Cloud Monitoring still reports per-model token totals, so usage looks fully measured but carries no calling identity and cannot be attributed to a person or a team. Turning it on logs every model call, which has cost and retention implications. That is your decision, not Zaun's. The Private Logs Viewer role grants permission to read these logs without creating them.

Console: IAM & Admin → Audit Logs → Vertex AI API → Data Read.

Wiz

Connector: wiz · Auth: OAuth2 client credentials (Wiz service account), per Wiz region · Requires: any plan

On the Connections page the Wiz tile sits under Cloud security posture. Wiz continuously analyzes the clouds you onboarded there (AWS, Azure, GCP, OCI, Alibaba Cloud, VMware) for risks across workloads, identities, network exposure, secrets, and compliance. Reagent reads Wiz through its GraphQL API: issues, the Security Graph resource inventory, vulnerability and misconfiguration findings, and the cloud accounts Wiz covers.

Lights up: none of the discovery signals directly. Wiz supplies the posture view: issues, vulnerability and misconfiguration findings, and the Security Graph inventory across every cloud onboarded in Wiz, without a second set of cloud credentials.

Before you start

• You need the manage integrations permission in Reagent.
• Wiz rights to create service accounts under Settings → Service Accounts.
• Your Wiz region, taken from your tenant URL.

Setup

1. In Wiz, go to Settings → Service Accounts.
2. Click Add Service Account.
3. Assign the required scopes listed under Permissions below.
4. Copy the Client ID and Client Secret. They are shown only once.
5. In Reagent, open Connections, click Wiz, select the Wiz Region matching your tenant URL, enter the Client ID and Client Secret, and save.

Fields

Permissions

The Wiz form lists all of the following as required scopes on the service account. Read scopes cover data collection. Write scopes support response actions and automation.

What Reagent reads

• Issues across every cloud in Wiz.
• Security Graph resource inventory.
• Vulnerability and misconfiguration findings.
• Cloud account coverage and Wiz audit logs.

Upwind

Connector: upwind · Auth: OAuth 2.0 client credentials plus Organization ID, scoped to one Upwind region · Requires: any plan

On the Connections page the Upwind tile sits under Cloud security posture. Upwind is a cloud-native application protection platform with runtime-powered cloud security. Reagent reads its cloud and runtime asset inventory, runtime threat alerts and correlated threat stories, vulnerability and configuration findings, API security posture, and SBOM packages. Cloud model deployments and cloud-deployed agents surface from that inventory with runtime context.

Lights up: Deployed Models, Custom Agents on Builder Platforms.

Before you start

• You need the manage integrations permission in Reagent.
• Admin access to the Upwind console.
• Your Upwind region. The API credential must be scoped to the same region.
• Your Organization ID, the org_ value from the console.

Setup

1. Log into the Upwind console as an admin.
2. Go to Settings > Credentials.
3. Click Generate Credentials.
4. Choose the API credential type, then pick the permission scope (see Permissions below).
5. Name the credential, for example "Zaun Integration".
6. Copy the Client ID and Client Secret immediately. The secret is only shown once.
7. Find your Organization ID: click your organization name in the top-right corner of the console and expand it to reveal the org_ value.
8. In Reagent, open Connections, click Upwind, select the Region matching your Upwind deployment, enter the Organization ID, Client ID, and Client Secret, and save.

Fields

Permissions

Read scopes are enough for inventory and findings. Grant the write scopes only if you want response actions to run through Upwind.

What you can monitor

• Cloud and runtime asset inventory: EC2, containers, pods, Lambda, RDS, and more.
• Threat detections (CDR): runtime alerts with MITRE ATT&CK mapping.
• Threat stories: correlated incident narratives grouping related alerts.
• Vulnerability findings: CVEs enriched with runtime context, EPSS, and exploitability.
• Configuration findings (CSPM): compliance violations against frameworks.
• API security: discovered endpoints with auth state and exposure.
• SBOM packages: software composition across workloads.
• Automation: workflows and webhook integrations for response actions.