Skip to main content
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.
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.

​
Configure Amazon Bedrock

1

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.
2

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.
3

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.
4

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.
5

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.

​
Configure Azure OpenAI

1

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.
2

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.
3

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.
4

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.
5

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.

​
Choose a rollout mode

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