Credentials & domains

AgentSOAR runs every response with credentials you supply for the underlying provider. You add and validate those credentials once, store them encrypted, and—for email and identity actions—bind them to the domains they protect so AgentSOAR routes each action to the right tenant.

Where credentials live

Manage credentials from AgentSOAR → Settings → Credentials at /agentsoar/settings/credentials. Each credential is scoped to one provider plugin—aws, gcp, azure, hostinger, google_workspace, microsoft_365, or agentsoc_mail_block—and supplies just the access that provider's capabilities need.

Add and validate a credential

  1. 1

    Choose the provider

    Add a credential and pick the provider plugin you want to connect. The form shows only the fields that provider requires.

  2. 2

    Enter the access details

    Supply the provider's authentication—an IAM key pair, a service account, or a service principal, depending on the provider and its auth mode.

  3. 3

    Validate

    AgentSOAR tests the credential against the provider. Validation records a status of ok, failed, expired, or unknown, along with the last error and the time it was checked, so you can see at a glance whether a credential is healthy.

A credential that fails validation can't be used to run actions until you fix and re-validate it. The provider connector guides cover the exact permissions and auth mode each provider expects.

Encryption at rest

AgentSOAR encrypts credential secrets at rest with AES-256-GCM. Only the non-secret metadata needed to identify and route a credential—such as its name, region, account or subscription identifiers, and the last four characters of a client id—is kept readable; the secret material itself is never exposed back through the UI or API.

Binding credentials to domains

Email and identity capabilities (block_sender, block_email_domain, disable_user) act on a tenant, not a specific inventory asset. AgentSOAR routes those actions by the protected mailbox or domain in the request: it resolves the protected host_email or host_domain to the credential that owns that domain.

This credential↔domain binding is what lets you connect more than one email or identity tenant and have AgentSOAR pick the correct one automatically. When an action names a protected mailbox or domain, AgentSOAR finds the bound credential for that domain and runs the action there.

Map each email or identity credential to the domain(s) it protects so tenant-scoped actions resolve correctly. Confirm the binding workflow against your deployment.

Re-authentication

Some providers issue credentials that expire. When a credential becomes invalid while an action needs it, AgentSOAR doesn't silently fail the action—it marks the execution awaiting_reauth and surfaces a pending action asking you to re-authenticate that credential.

  • Re-authenticate the flagged credential from the Credentials page (or the action-required prompt on the execution).
  • If you don't re-authenticate within the cutoff window, the execution moves to expired_awaiting_reauth and the pending prompt clears.

Keeping credentials valid—and re-authenticating promptly when prompted—keeps automated and manual response working without interruption. See Executions & revert for how these statuses fit the wider lifecycle.

Connector setup

Follow the connector guides to provision least-privilege access for each provider: