Kiro Enterprise enables centralized management of user subscriptions, access controls, and governance settings for an organization’s users through an identity provider.
When an organization adopts Kiro, administrators should understand the settings that enable users to use Kiro in accordance with the organization’s requirements.
This article explains these settings by topic for Kiro administrators.

Concepts

Kiro uses several concepts to manage users and resources.
This section describes the concepts used in this article.
See Kiro Concepts for a full list.

Kiro Profile

A Kiro profile is an AWS resource for management that defines and enforces administrative settings and subscriptions for enterprise users in a given AWS account and region.
You can create only one Kiro profile per AWS account per Region. This means that you can create a separate profile in each Region within the same account.
You manage users and configure administrative settings separately for each Kiro profile.
The Kiro settings apply separately to each profile.
This lets you apply different settings to each profile. You can create up to 20 Kiro profiles per Region.

Kiro Enterprise user

A Kiro enterprise user is someone you have added to Kiro and assigned to a Kiro subscription tier through the Kiro console.
Kiro enterprise users can access Kiro through IAM Identity Center, Okta, or Microsoft Entra ID.
This article focuses on users managed through IAM Identity Center.
Users who sign in through AWS Builder ID or a social login provider such as GitHub are individual subscribers rather than Kiro enterprise users, even if they have a paid subscription.

Kiro Administrator

In Kiro, users who can access the Kiro console and manage user subscriptions and Kiro Profile settings are considered administrators.
The IAM identity used by the Kiro administrator requires the IAM permissions described here to subscribe users and configure settings in the Kiro console.
To prevent unintended changes, configure appropriate IAM permissions for both Kiro administrators and regular users.

Subscriptions for users and groups

Subscriptions are assigned to IAM Identity Center users and groups.
What is worth noting here is that there is no such concept as a group subscription.
When you subscribe a group, the subscription is applied to each individual user within that group.
For this reason, the Groups tab in the Kiro console does not display users’ subscription status.
To check a user’s subscription status, view subscription status on the Subscriptions tab.

AWS managed applications in IAM Identity Center for Kiro

When setting up Kiro with IAM Identity Center instance, the following AWS managed applications are created within the instance for Kiro.
The application names include the region where the Kiro profile was created.

• KiroProfile-[region]
• Kiro Sign-In - KiroProfile-[region]

You can change the name of an existing Kiro profile from Settings > Edit > Profile settings in the Kiro console.
Changing the name also updates the corresponding KiroProfile-[region] application name, but the Kiro Sign-In - KiroProfile-[region] application name remains unchanged.

IAM Identity Center (IdC)

Choosing between an organization instance and an account instance

You can use either an IAM Identity Center organization instance or an account instance to manage Kiro users.
An organization instance provides organization-wide identity management capabilities.
It is recommended to use an organization instance if you plan to roll out Kiro across your organization.

An account instance lets you create a Kiro profile that is independent of the profile associated with your organization instance.
As described earlier, settings configured in the Kiro console apply separately to each Kiro profile.
You can therefore use a separate account instance and Kiro profile to test features or changes to settings without affecting the profile associated with your production organization instance.

You cannot later convert an account instance into an organization instance, or vice versa.
Therefore, consider your use case before deciding which type of instance to create.

Regions for the Kiro profile and the IAM Identity Center instance

In Kiro, the Kiro profile region and the IdC region are treated separately, and the two regions do not have to match.
See Supported regions for the current list.

• The region where your IAM Identity Center instance is enabled. This is where you manage user identities.
• The region where your Kiro profile is created. This is where data is stored. This region might be different from the region of your IAM Identity Center instance.

Setting up Kiro with IdC

Setting up Kiro with an organization instance (management account)

Setting up Kiro with an organization instance is straightforward.
Go to the Kiro console and choose Sign up for Kiro to start the setup.

⚠️ If an organization instance has not been created yet, the message below appears. Complete the instance creation in the IAM Identity Center console.

If an organization instance exists, the following screen appears. Choose Set up application as admin to complete the setup.

After Kiro redirects you to the Kiro console, confirm that the ssoins-[your-id] value under Manage users & groups (IAM Identity Center) matches your IAM Identity Center instance ID.

Setting up Kiro with an account instance (member account)

Even if your organization already uses an IdC organization instance, you can create a Kiro Profile using an account instance when setting up Kiro in a member account.
To create an account instance, you must first allow account instance creation in the organization instance.

The following steps are to create a Kiro profile with an account instance in the member account.

1. Go to the Kiro console home page and choose Onboard your team to Kiro.
2. Under Select your identity management source, choose IAM Identity Center.
3. Enter the user's email address instead of choosing Set up application as admin.
   1. If an account instance and its users already exist, Kiro completes the setup.
   2. If no account instance exists, Kiro creates an account instance and an IdC user with the email address that you entered.

⚠️If no IdC user with the email address that you entered exists in the IdC instance, entering First/last name creates the new user automatically.

When Kiro creates an account instance during setup, it creates the instance in the same region as the Kiro profile.
To use a different region, create the account instance in that region before Kiro setup.

When users with the same email address exist in both an organization instance and an account instance

If users with the same email address exist in both an organization instance and an account instance, the following screen appears when you enter the user’s email address.

• When you choose Continue, Kiro is associated with the organization instance.
• When you choose Switch User and continue with the setup, Kiro is associated with the account instance.

⚠️ If the screen does not appear even though users with the same email address exist in both instances, try reloading the page or clearing your browser cache.

Kiro resources across multiple regions and accounts

Keep the following points in mind when creating Kiro profiles across multiple regions or accounts.

• Each profile can subscribe IdC users independently.
• Kiro profiles are created in the account where Kiro was set up.
• AWS Managed Applications are created within the IdC instance associated with Kiro.

It is important to understand which resources are created in which regions and accounts.
Since this can be a bit complex, let’s look at the following two scenarios.

Scenario 1: Creating multiple profiles within the same account

Suppose account A is the management account of an AWS organization.
An organization instance and a Kiro profile have already been created in us-east-1.
The organization instance contains an IdC user A who has been assigned a Kiro subscription.

In this case, account A can create a new Kiro profile in a different region, such as eu-central-1.
During Kiro setup, you need to associate the Kiro profile with an existing organization instance because IAM Identity Center supports only one instance per account.

Go to the Kiro console in eu-central-1 and proceed with setup.
This creates the following resources:

• A Kiro profile in the eu-central-1 region.
• AWS managed applications within the organization instance in the IdC region (us-east-1):
  • KiroProfile-eu-central-1
  • Kiro Sign-In - KiroProfile-eu-central-1

After Kiro setup is complete, you can subscribe users and groups from the associated IdC instance to the Kiro profile in eu-central-1.
You can also subscribe user A, who is already subscribed through the profile in us-east-1.

One benefit of subscribing an IdC user to multiple profiles is that credit plan limits can be allocated independently.
Credits used when logging in with the Kiro profile in us-east-1 are not counted toward the credit usage in eu-central-1.
By subscribing the same user to multiple profiles, the user can switch between profiles depending on the use case.
However, note that subscribing the same user to two profiles results in charges for both subscriptions.

Scenario 2: Creating Kiro profiles in a member account

Next, let’s consider setting up Kiro in us-east-1 in member account B, which belongs to the organization described above.
In this case, there are two options: you can either use an existing organization instance or create a new account instance in account B and associate it with Kiro.
This example uses the existing organization instance in account A.

When you go to the Kiro console in us-east-1 in account B and complete the setup, the following resources are created:

• A Kiro profile in the us-east-1 region in member account B.
• AWS managed applications within the organization instance in the IdC region:
  • KiroProfile-us-east-1
  • Kiro Sign-In - KiroProfile-us-east-1

Note that AWS managed applications are created per Kiro profile.
When you check the IdC console in management account A, you can confirm that the applications with the same names have been created with Owning account ID values corresponding to account A and account B, respectively.

After setup is complete, you can subscribe IdC users from the organization instance to the Kiro profile in account B.
You can also subscribe user A.

Finally, let’s consider setting up Kiro in eu-central-1 using an account instance in account B for testing purposes.
When you go to the Kiro console in eu-central-1 in account B and complete the setup, the following resources are created:

• A Kiro profile in the eu-central-1 region in the member account B.
• AWS managed applications within the account instance in the IdC region:
  • KiroProfile-eu-central-1
  • Kiro Sign-In - KiroProfile-eu-central-1

The applications are created within account instances, not organization instances.
Since IdC users are managed independently within account instances, you can manage IdC users and Kiro subscriptions separately from organization instances.

Why isn't an existing IAM Identity Center instance detected during Kiro setup?

When you set up Kiro in an account that already has an IdC instance, you will see an option to connect to that existing instance.
If this option is not displayed, the IAM identity that you use may not have the permissions required to create a Kiro profile.
Without these permissions or when some required actions are denied by a service control policy (SCP), the instance is treated as if it does not exist.

Browser developer tools are useful for checking which actions are denied.

1. Open your browser's developer tools and go to the Network tab.
2. Clear the network log and start recording.
3. Continue with the Kiro setup.
4. In the Status column, find a failed request or one with a 4xx or 5xx status code.
5. Click the request and check the Preview or Response tab to investigate the cause of the error.

For example, the following network log entry shows that the organization instance cannot be found because an SCP in the organization denies sso:ListInstances.

{"__type":"AccessDeniedException","Message":"User: arn:aws:iam::[Account ID]:[IAM Identity] is not authorized to perform: sso:ListInstances on resource: arn:aws:sso:::instance/* with an explicit deny in a service control policy: arn:aws:organizations::[Account ID]:policy/[Organization ID]/service_control_policy/[Policy ID]"}

Why a subscription assigned to a group is not reflected in a user's status

If you add a user to a group that already has a Kiro subscription, there may be a delay of up to 24 hours for the subscription to propagate to user status in the Kiro console.
On the other hand, subscribing a group that already has users takes effect within a short time.

Access control

Restricting who can assign subscriptions

Attach an identity-based IAM policy that denies q:CreateAssignment to any IAM identities or permission sets that must not assign subscriptions.
To enforce the same restriction across your AWS organization, use an SCP that denies q:CreateAssignment.

Blocking Builder ID and social login (allowing IAM Identity Center sign-in only)

AWS Builder ID and social login use the following endpoints respectively.

• AWS Builder ID: https://view.awsapps.com/start
• Social login: https://kiro-prod-us-east-1.auth.us-east-1.amazoncognito.com

To require users to sign in through IAM Identity Center, configure your organization's network controls, such as its proxy or firewall, to block these endpoints.
Blocking these endpoints stops new sign-ins only but note that users who are already signed in keep working.

⚠️Blocking view.awsapps.com can also affect other services using AWS Builder ID, such as Amazon QuickSight. Check the impact on those services before you block this endpoint.

Allowing or denying web_fetch for specific domains

Kiro IDE v1 and Kiro CLI v3 introduced capability-based permissions, which let you control web_fetch access by domain.
The following example allows fetches from docs.aws.amazon.com, asks for confirmation before fetching from kiro.dev, and denies fetches from aws.amazon.com.

rules:
  - capability: web_fetch
    effect: allow
    match:
      - docs.aws.amazon.com
  - capability: web_fetch
    effect: ask
    match:
      - kiro.dev
  - capability: web_fetch
    effect: deny
    match:
      - aws.amazon.com

See documentation for the complete permissions syntax.
Permissions require a configuration file on each client.

Restricting web tools

Turning off Web search and web fetch tools in the Kiro console restricts the use of web_search and web_fetch at the client level.
The setting is enabled by default and is applied per Kiro profile.

You can also use capability-based permission rules to block both tools by setting effect: deny for web_fetch and web_search.

rules:
  - capability: web_fetch
    effect: deny
  - capability: web_search
    effect: deny

However, permission rules have to be configured on each client.
It is recommended to use the setting on the Kiro console to enforce this for all users of the profile.

Allowing only the MCP servers approved by your organization

By default, users can use any MCP server in their Kiro client.
Administrators can either disable MCP entirely or specify a list of MCP servers in an MCP registry.

Disabling MCP entirely

In the Kiro console, go to Settings > Shared settings, and toggle Model Context Protocol (MCP) to Off.
When MCP is off, the client suppresses all MCP servers and makes no MCP tools available to the agent.
The /mcp command shows MCP has been disabled by your administrator.

Specifying an allow-list

To control which MCP servers users can use, create a JSON file that lists the allowed servers, serve the file over HTTPS, and add its URL to the Kiro profile.

1. Open the Kiro console.
2. Choose Settings.
3. Under Shared settings, confirm that Model Context Protocol (MCP) is On.
4. In the MCP Registry URL field, choose Edit.
5. Enter the URL of the MCP registry JSON file.
6. Choose Save.

Once the allow-list is enabled, it applies to everyone using that Kiro profile.
If you want to check the behavior before applying it, one option is to create an account instance and a Kiro profile in a test account and specify the MCP registry URL there.
Since the MCP registry setting applies per Kiro profile, separating profiles lets you verify the behavior without affecting other profiles.

API keys

API keys enable headless authentication for CI/CD pipelines and automation scripts.
This section covers what you need to know to manage them.

Creating an API key

When API key generation is enabled for a Kiro profile, any user with a Kiro subscription can create an API key.
API keys are specific to a user and a Kiro profile. A user cannot view API keys created by another user, and keys created by the same user in different Kiro profiles remain separate.
Even a Kiro administrator cannot list another user's keys.

Disabling API keys

To prevent users from generating API keys, turn off Enable users to generate API keys in the Kiro console.
After you disable API keys, users can no longer generate new API keys, and all existing API keys are also disabled (this will takes some time to take effect).
This applies to the entire Kiro profile; you cannot enable it for selected users within the profile.
To allow API keys for only some users, consider separating them into a different account with a separate Kiro profile.

Credit consumption for API key usage

Kiro associates an API key with the user who created it.
Credits consumed using the key are decremented from the subscription credits of the user who created the key.
When a user reaches their plan limits, their key stops working unless overages are enabled.

What to do if an API key is compromised

Ask the user who generated the API key to delete it on Kiro Web and generate a replacement key.
API keys do not expire automatically, and only the user who generated a key can delete it.
If the user cannot delete the key for some reason, another option is to disable the IdC user instead.
This takes time to take effect, however, so deleting the key directly is the recommended approach.

Data management

Kiro processes various types of data.
To manage that data properly, it is important to understand how your data is processed and stored.

Data storage

Kiro stores your questions, responses, additional context such as code, and request metadata so that it can respond to your requests.
In some circumstances, Kiro also stores this data for abuse detection.
When you enable prompt logging or the user activity report, Kiro also stores the data required to generate reports and log events.
Kiro does not use this content from Kiro enterprise users for service improvement.

telemetry and content collection

Telemetry includes usage data, errors, crash reports, and performance metrics.
Kiro enterprise users are automatically opted out of telemetry and content collection for service improvement.
This opt-out does not prevent an administrator from enabling user activity reports in the Kiro console.
See Types of telemetry collected for details about the telemetry.

Regions where data is processed under cross-region inference

Kiro is powered by Amazon Bedrock and uses cross-region inference to distribute traffic across AWS regions and improve inference performance and reliability.
Cross-region inference is enabled by default and cannot be disabled.

The important thing is that cross-region inference does not affect where your data is stored.
Even when Kiro processes a request in another Region, it stores the data in the region associated with your Kiro profile.
Kiro stores prompts and responses from Kiro enterprise users only as needed to provide and maintain the service - for example, for prompt logging and user activity reports - and does not use this content for service improvement.

Global cross-region inference

For models and capabilities marked as experimental, Kiro may use global cross-region inference to improve performance, throughput, and capacity availability.
Inference requests for these models and capabilities may be processed in commercial AWS regions worldwide, including regions outside the one associated with your Kiro profile.
As with cross-region inference, the Region where your data is stored is not affected by global cross-region inference either; it remains the Region of your Kiro profile.
To avoid global cross-region inference, do not use models or features marked as experimental.

Abuse Detection

Kiro uses Amazon Bedrock, so the abuse detection mechanisms implemented by Bedrock apply to all model usage in Kiro.
In addition, Kiro provides the following features for abuse detection.

• For Kiro Free Tier users only, Kiro may store inputs for up to 60 days to detect activity that violates the terms of service or use policies. This does not apply to Kiro enterprise users.
• For OpenAI GPT models, classifier-flagged traffic is retained for up to 30 days for automated offline abuse detection. The traffic is stored in the region where the inference request was processed. This also applies to Kiro enterprise users.

Code references

Kiro learns, in part, from open-source projects.
A suggestion might therefore be similar to publicly available code.
In Kiro IDE, the code reference log identifies suggestions that are similar to publicly available code.
Kiro administrators can turn off code suggestions with references in the Kiro console.
Like other console settings, this setting applies per Kiro profile.

Encrypting a Kiro profile with a customer managed key (CMK)

Kiro encrypts stored data using AWS owned encryption keys from AWS Key Management Service (AWS KMS) by default, but there is an option to use a CMK for data encryption.
Kiro administrators can configure a CMK for the Kiro profile on the Kiro console.
Check the following requirements.

• Only symmetric keys are supported.
• The IAM principal configuring the key has the IAM permissions described here.
• The key has a key policy to allow q.amazonaws.com to perform the following actions:

{
      "Effect": "Allow",
      "Principal": {
        "Service": "q.amazonaws.com"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey",
        "kms:CreateGrant"
      ],
      "Resource": "*"
    }

To configure a CMK, open Settings for the Kiro profile, enable Encryption key, and select an existing CMK or create a new one.
To verify that Kiro is using your key, enter a URL in MCP Registry URL, update the profile, and then search AWS CloudTrail for a Decrypt API call.
In the CloudTrail event, verify that userAgent is q.amazonaws.com and that requestParameters.keyId matches the ARN of your key.
These values indicate that Kiro used your key to decrypt the MCP Registry URL.

  "userAgent": "q.amazonaws.com",
  "requestParameters": {
    "encryptionAlgorithm": "SYMMETRIC_DEFAULT",
    "keyId": "arn:aws:kms:<region>:<account-id>:key/<your-key-id>"
    ...
  }

⚠️ Specifying an MCP Registry URL restricts the MCP servers available to users. After you confirm the Decrypt API call, clear the URL to remove the restriction.

What CMK does not cover

Kiro writes prompt logs and user activity reports to the S3 bucket that you specify.
The CMK configured for the Kiro profile does not encrypt these files.
S3 encrypts them with Server-Side Encryption by default.
To encrypt these files with a CMK, configure the destination S3 bucket to use that key.

Models

Does Kiro use only the models on the allow list when Auto is selected as the model?

No.
When Auto is selected, Kiro may route the request not only to the models on the allow-list but also to other models available in the region where your Kiro profile is located.
To control exactly which models are used, exclude Auto from the approved list and include only the specific models you want to allow.

Some models are unavailable in certain regions

Model availability varies by country and region.
See Models for availability by model.

Others

Tracking users' credit consumption

The Credits consumed metric on the dashboard is useful for tracking usage by subscription tier. Kiro refreshes this metric hourly.
For a per-user breakdown, enable the user activity report and check the Credits_Used column in the CSV.
The UserId and User_Email columns contain the IAM Identity Center user ID and email address, respectively.

Is there a published SLA for Kiro?

Kiro has no SLA.
Your use of Kiro is governed by the AWS Customer Agreement and the AWS Service Terms as described in Kiro License.