Skip to main content
Use fresh AWS accounts

Install AlphaAgent Organisations into a new, empty AWS account, and give every AlphaAgent Studio deployment a new, empty AWS account of its own. Three reasons:

  1. It is AWS best practice to isolate each workload in its own account, with its own limits, billing view and permissions.
  2. Amazon Bedrock quotas are set per AWS account. Many users in one deployment share one quota and exhaust it; one account per deployment keeps each team's capacity its own.
  3. The blast radius is smaller. A problem in one deployment, or one team's mistake, cannot reach the others.

Connect your Entra ID tenant for Studio sign-in (SSO)

For the console owner or operator (or IdentityProviderManager) with an Entra ID administrator who can create an app registration and grant tenant-wide admin consent. The person who clicks Connect must be signed in to the console (owner, operator or IdentityProviderManager) and be able to grant tenant-wide consent in Microsoft (a Global Administrator); if your Global Administrator is not the break-glass owner, grant them a console role first on Identity & Access Management > Users (Users, groups and roles). No Studio deployment can be launched until a tenant is connected. This is the second Entra ID set-up and a different Entra object from the SAML application on the previous page: that one signs your administrators in; this one lets the Organisation create each Studio deployment's own enterprise application for single sign-on (SSO) and assign users to it.

1. Open Identity Providers​

In the console open Identity Providers ("Connect your identity provider once, then use it for single sign-on across any of your Studio deployments."). On a new install the empty state reads "No identity providers connected yet". Click Connect identity provider (disabled tooltip: "Requires the IdentityProviderManager role (or owner/operator)"). The Connect an identity provider page opens with an Instructions card and an Identity Provider Configuration card.

2. Create the app registration in Entra​

Your Entra administrator follows the Instructions card:

  1. entra.microsoft.com (or portal.azure.com > Microsoft Entra ID) > App registrations > New registration. Name it, for example "AlphaAgent Organisations - Identity Provider Integration".
  2. Supported account types: Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) (a dropdown, not radios). Under it Entra pre-checks "Select to allow only specific tenants", which disables Register: choose Allow all tenants. Redirect URI: platform Web, value copied from the card, your console origin plus /org-api/identity-providers/callback (for example https://org.example.com/org-api/identity-providers/callback). Click Register.
  3. Copy the Application (client) ID from the Overview page.
  4. API permissions > Add a permission > Microsoft Graph > Application permissions (not Delegated; the groups are collapsed, tick the checkbox rather than the row): Application.ReadWrite.OwnedBy, Application.Read.All, User.Read.All, Group.Read.All, AppRoleAssignment.ReadWrite.All. Click Grant admin consent; the status column flips to granted. A publisher-verification banner may show and does not block.
  5. Certificates & secrets > New client secret: any description, an expiry (default 180 days, maximum 24 months) > Add > copy the Value at once; it stays visible only until the page reloads.

The two Application permissions create and read back each deployment's enterprise application; User.Read.All and Group.Read.All power directory search when you assign people; AppRoleAssignment.ReadWrite.All assigns them to a deployment's application.

3. Enter the credential and connect​

In Identity Provider Configuration: Provider type Microsoft Entra ID (the only choice); Client ID, the GUID (anything else: "That does not look like a Client ID -- it should be a GUID"); Client secret, the Value (Reveal to check the paste; spaces or line breaks are refused, usually browser autofill). Click Connect ("Saving...", then "Redirecting to Microsoft..."). Microsoft's consent page lists six permissions (the five plus the default delegated User.Read) and may carry an "unverified publisher" banner; accept as an administrator who can grant tenant-wide consent. You return to the new provider's page.

What you should see​

The provider page: Tenant name, Tenant ID, Status "Connected", Connected date, Deployments 0; a Connection section with Delete; Credentials with the Client ID (last four characters), Expires ("from Microsoft" or "entered by hand", with days remaining) and Update credentials. The list has a row Tenant, Type "Microsoft Entra ID", Status, Connected. The deploy wizard's Identity provider section now offers "<tenant name> (Microsoft Entra ID)".

Notes​

  • One app registration and one secret serve every tenant you connect. From 30 days before expiry the row reads "Secret expires in N days"; after it, "Secret expired", and provisioning, directory search and assignments fail until updated. Rotate with Update credentials (Client ID, new Client secret, optional Secret expiry; "Verified with Microsoft and saved." or "Saved. Not verified yet" when no tenant is connected). Requires owner or operator (or IdentityProviderManager).
  • A single-tenant registration cannot be consented to from the console's flow. A connect attempt is valid for 15 minutes.
  • Delete removes only the Organisation's record, not the enterprise applications Microsoft created in your tenant; a provider linked to deployments cannot be deleted.
  • A deployment's Identity view can show SAML service-provider values for a deployment with no tenant linked, but the wizard offers no manual SAML path: Deployment detail.
  • Consent errors return you to the list with a message: Troubleshooting the install.