> ## Documentation Index
> Fetch the complete documentation index at: https://docs.openwhispr.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managed Amazon Bedrock and Azure OpenAI

> Configure customer-owned Bedrock or Azure OpenAI access once so employees only need company SSO.

Managed enterprise AI gives employees access to your AWS Bedrock or Azure OpenAI models without distributing cloud keys or asking them to configure a CLI. IT establishes trust once; OpenWhispr issues a short-lived, workspace-scoped identity after company SSO.

Prompts travel directly from the desktop app to your cloud account. OpenWhispr's API supplies identity and policy, but it does not proxy or store the prompt or response.

## Get an Enterprise workspace

Enterprise onboarding is currently sales-assisted. The first IT administrator creates an OpenWhispr account in the desktop app and creates the customer workspace. OpenWhispr then activates that existing workspace as Enterprise and confirms its owner. The owner opens the admin portal and configures SSO, SCIM, policy, and cloud trust. Employees do not configure any of those systems: once IT assigns them, they choose company SSO and receive their workspace, teams, and managed models automatically.

## How access works

1. Your identity provider assigns the employee through SCIM, or SSO admits them through the temporary just-in-time fallback during a pilot.
2. The employee signs in to OpenWhispr with company SSO.
3. OpenWhispr issues a five-minute assertion for that workspace and provider.
4. AWS STS or Microsoft Entra exchanges it for short-lived cloud access.
5. The desktop sends the model request directly to Bedrock or Azure OpenAI.

AWS credentials are requested for 15 minutes. Azure access tokens remain only in desktop memory until Microsoft expires them. Signing out, changing accounts, or changing workspaces clears the local credential cache.

An OpenWhispr login proves who the person is. Access to an Enterprise workspace is checked separately: the API also requires current workspace membership, the correct company SSO provider, the SCIM assignment when enforced, and the workspace policy. Switching workspaces repeats that authorization check.

## Before you start

You need:

* an active OpenWhispr Enterprise workspace; SSO, SCIM, and managed cloud access are not enforced on Business or Pro workspaces
* a verified SAML or OIDC provider; managed cloud assertions require a current company SSO session
* SCIM directory sync, recommended with just-in-time fallback off after rollout
* permission to create AWS IAM federation or a Microsoft Entra workload identity
* deployed and approved models in the cloud region or Azure resource you will use

Open **Policies > Managed enterprise AI** in the OpenWhispr admin portal. The page shows the exact issuer, audience, subject, and trust JSON for your workspace. Copy those generated values; do not type a workspace ID by hand.

<Warning>
  Activate one managed provider at a time. You may save both configurations, but Bedrock and Azure OpenAI cannot both be active for the same workspace.
</Warning>

## Configure Amazon Bedrock

<Steps>
  <Step title="Create the OpenWhispr OIDC provider in AWS">
    In AWS IAM, add an OpenID Connect identity provider. Use the issuer shown by OpenWhispr as the provider URL and `sts.amazonaws.com` as its audience.

    AWS must be able to reach the issuer discovery and JWKS endpoints over HTTPS. See [AWS's OIDC provider guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html).
  </Step>

  <Step title="Create a least-privilege Bedrock role">
    Create a web-identity IAM role in the same AWS account as the OIDC provider. Grant access only to the models or inference profiles your workspace needs.

    Typical runtime actions are `bedrock:InvokeModel` and `bedrock:InvokeModelWithResponseStream`. If employees may browse the Bedrock catalog, also allow `bedrock:ListFoundationModels` and `bedrock:ListInferenceProfiles`.

    Cross-region inference needs permission for both the inference-profile ARN and its destination foundation-model ARNs. Make sure organization SCP region restrictions permit every destination, and review the destination geography with your security and data-residency teams before rollout.
  </Step>

  <Step title="Apply the generated trust policy">
    Enter the role ARN in OpenWhispr. The admin portal generates a trust policy constrained to the OpenWhispr issuer, `sts.amazonaws.com` audience, and `workspace:<workspace-id>` subject.

    Copy that policy to the IAM role. These conditions prevent an assertion for another workspace from assuming it.
  </Step>

  <Step title="Choose the permitted models">
    Enter the AWS region and each allowed Bedrock model or inference profile ID, one per line. Commercial AWS and AWS GovCloud are supported; the role ARN partition must match the region. AWS China is not supported. The managed desktop configuration cannot invoke a model outside this list.

    Choose a default for dictation cleanup, dictation agent, note formatting, note chat, and translation.
  </Step>

  <Step title="Roll out and test">
    Save the provider as **Configured, not active**, allow Bedrock under **Policies > AI providers**, and select **Validate cloud access**. OpenWhispr verifies the AWS identity exchange and Bedrock control-plane access. The employee pilot confirms that the permitted model or inference profile can run; invocation permissions and destination-region service control policies still apply.

    Start the pilot with **Managed by default** and leave **Allow manual setup** on. Have a SCIM-assigned employee sign in with company SSO. When the pilot succeeds, turn manual setup off or choose **Managed required**. Revalidate after changing any trust or provider value.
  </Step>
</Steps>

## Configure Azure OpenAI

<Steps>
  <Step title="Create a workload identity">
    Create a Microsoft Entra app registration or a user-assigned managed identity. Do not create a client secret.

    Record the Entra tenant ID and the application's client ID, or the user-assigned identity's client ID.
  </Step>

  <Step title="Grant Azure OpenAI inference access">
    On the intended Azure OpenAI resource, assign the workload identity the **Cognitive Services OpenAI User** role. Scope the assignment to the resource where possible.

    Azure role changes can take several minutes to propagate. See [Microsoft's Azure OpenAI Entra authentication guide](https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/managed-identity?view=foundry-classic).
  </Step>

  <Step title="Add the generated federated credential">
    In OpenWhispr, enter the tenant ID and client ID. Copy the generated federated credential JSON.

    Add it under **Federated credentials** on the app registration or user-assigned managed identity. The issuer, subject, and `api://AzureADTokenExchange` audience are case-sensitive and must match exactly. Choose the **Other issuer** scenario when the portal asks.
  </Step>

  <Step title="Configure the resource and deployments">
    Enter the Azure OpenAI HTTPS endpoint and use API version `v1` for stable APIs, or `preview` only when a required feature is preview-only. Add each permitted deployment name, one per line, then choose a default deployment for all five OpenWhispr features.

    Enter only the public Azure resource origin, such as `https://acme.openai.azure.com`. Do not add `/openai`, `/openai/v1`, a deployment path, query parameters, or credentials. OpenWhispr adds the API path itself. Azure Government and other Azure clouds are not currently supported.
  </Step>

  <Step title="Roll out and test">
    Save Azure as **Configured, not active**, allow it under **Policies > AI providers**, and select **Validate cloud access**. OpenWhispr verifies the Entra token exchange and access to the exact Azure OpenAI resource.

    Start with **Managed by default** and **Allow manual setup** on, then test with a SCIM-assigned employee using a fresh company SSO session. After the pilot, turn manual setup off or choose **Managed required**. Revalidate after changing any tenant, identity, endpoint, version, or deployment value.
  </Step>
</Steps>

## Choose a rollout mode

| Rollout                | Employee experience                                                     | When to use it              |
| ---------------------- | ----------------------------------------------------------------------- | --------------------------- |
| Configured, not active | Saved for later; desktop behavior is unchanged                          | Prepare or stage a provider |
| Managed by default     | Company SSO selects the administrator's provider and model defaults     | Pilot and gradual migration |
| Managed required       | Managed access is locked; personal profiles and keys cannot override it | Enforced production policy  |

Any active managed mode requires a verified company SSO provider and a workspace policy that allows the selected enterprise cloud. **Managed required** also requires **Require SSO** and a successful validation of the exact cloud configuration within the previous 30 minutes. The admin portal shows these checks before it allows activation.

**Allow manual setup** preserves the existing AWS profile/access-key and Azure API-key flow during migration. Existing manual users are not silently switched until managed access becomes required. Employees without a manual configuration receive the managed provider by default.

## Rotate, switch, or roll back

* **AWS role change:** create the new role and apply the generated trust policy, enter the new ARN and validate the draft, save it, then remove the old trust.
* **Azure identity change:** create the new identity, add the generated federated credential and resource role, enter its client ID and validate the draft, save it, then remove the old credential or role assignment.
* **Model change:** add the new model or deployment, set all affected defaults, save, then remove the old item.
* **Provider switch:** save the inactive provider first, set the active provider to **Configured, not active**, then activate the other. The API prevents two active providers.
* **Emergency rollback:** choose **Configured, not active**. Existing manual access remains available only when your policy and **Allow manual setup** permit it.

Configuration changes advance a workspace-wide generation. Desktops refresh the non-secret configuration when the app regains focus and at least every five minutes while it is open. A newer generation invalidates older in-flight credentials and requests. AWS credentials, Azure access tokens, and OpenWhispr workload assertions are never persisted to disk.

For an emergency that cannot wait for desktop refresh, revoke the AWS role trust or Microsoft Entra federated credential or role assignment. That stops new cloud credentials for the entire workspace. Existing AWS credentials can last up to 15 minutes; Azure tokens last until the expiry Microsoft issued.

## Self-hosted API requirements

If you self-host the OpenWhispr API, configure one stable public HTTPS base URL before creating cloud trust. The generated issuer, discovery URL, JWKS URL, and workload assertions must all use that same origin. AWS and Microsoft must be able to reach the discovery and JWKS endpoints with a valid public TLS certificate; private hosts, changing preview URLs, and deployment aliases that rewrite the issuer are not suitable. Rotate signing keys with an overlap period so previously issued assertions can still be verified until they expire.

## Troubleshooting

| Message                            | What to check                                                                                                                   |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Company SSO is required            | Sign out and sign back in with the company SSO option, not email or social login                                                |
| Directory assignment required      | The employee is active in SCIM and their SSO email matches the directory record                                                 |
| AWS cannot assume the role         | OIDC issuer, audience, subject, role ARN, and trust policy match the generated values                                           |
| Bedrock access denied              | IAM actions, resource ARNs, region, model access, and inference profile permissions                                             |
| Microsoft identity exchange failed | Tenant/client IDs and all federated credential fields match exactly; allow time for propagation                                 |
| Azure OpenAI access denied         | The identity has the correct inference role on the intended resource and the deployment name is exact                           |
| Provider is disabled by policy     | Enable the selected enterprise provider under **Policies > AI providers**                                                       |
| Cloud validation is required       | Select **Validate cloud access** again, then activate **Managed required** within 30 minutes without changing the configuration |

## Related

* [Provision people and teams with SCIM](/help/it/scim-provisioning)
* [Network allowlist](/help/it/network-allowlist)
* [Where your voice and text go](/help/privacy/where-your-data-goes)