Sign-in controls

Kiro offers two sign-in control paths. Deploy managed settings to shape sign-in on company devices. Use Kiro profile settings in the console to control device flow sign-in for each profile.

Sign-in controls live in the same managed-settings.json file as permission policies. They apply to Kiro IDE (version 1.2 and later) and Kiro CLI (version 2.25.0 and later) on the device where the file is deployed.

Sign-in controls read two parts of the managed settings file:

• A rule in the rules array with "capability": "signin_method" restricts which methods the sign-in screen offers. The rule always uses "effect": "deny". match names the methods to remove and exclude names the methods to keep. To allow only some methods, deny everything with "match": ["*"] and list the permitted methods in exclude.
• Keys in the settings object prefill your organization's sign-in details and add the help link.

Kiro reads the file when a sign-in starts, so the controls take effect at the next sign-in. The browser sign-in page shows only the permitted methods, with your details filled in. When the browser hands the result back, the client checks the method again and refuses a denied method before a token is issued, so editing the sign-in URL does not get around the rule.

If you deny every method or the rule cannot be read, Kiro drops the restriction and offers every method rather than locking users out. See Validation and error handling.

Place the file at the OS-protected path for your platform. These paths require administrator or root access to modify. If you already deploy a permission policy, add the signin_method rule and the settings object to that file; both the IDE and the CLI read it.

sudo mkdir -p "/Library/Application Support/Kiro"
sudo nano "/Library/Application Support/Kiro/managed-settings.json"

{
  "rules": [
    {
      "capability": "signin_method",
      "match": ["*"],
      "exclude": ["idc"],
      "effect": "deny"
    }
  ],
  "settings": {
    "idc_start_url": "https://my-org.awsapps.com/start",
    "idc_region": "us-east-1",
    "signin_help_url": "https://it.example.com/kiro-help"
  }
}

Keep the rules array in the file even when you only set settings; use "rules": [] if you have no rule to add. The permission-policy reader expects it.

A signin_method rule has the same fields as a permission rule, but its match and exclude lists hold method names instead of glob patterns:

Use these method names. They are case-sensitive, and the labels on the sign-in screen are not accepted.

A rule may name at most 16 entries across match and exclude. If the file has several signin_method rules, a method denied by any of them is denied.

Every key in settings is optional. Values must be strings of at most 2,048 characters without control characters, and URL values must use https. A value that fails these checks is dropped on its own; the rest of the file still applies.

{
  "rules": [
    {
      "capability": "signin_method",
      "match": ["*"],
      "exclude": ["idc"],
      "effect": "deny"
    }
  ],
  "settings": {
    "idc_start_url": "https://my-org.awsapps.com/start",
    "idc_region": "eu-central-1"
  }
}

The sign-in screen offers only Your organization, with the start URL and Region already filled in.

{
  "rules": [
    {
      "capability": "signin_method",
      "match": ["*"],
      "exclude": ["idc", "external_idp"],
      "effect": "deny"
    }
  ],
  "settings": {
    "external_idp_domain": "example.com",
    "external_idp_region": "us-east-1"
  }
}

{
  "rules": [
    {
      "capability": "signin_method",
      "match": ["social", "builder_id"],
      "effect": "deny"
    }
  ]
}

Removes Google, GitHub, and AWS Builder ID from the sign-in screen and leaves Identity Center and external identity provider sign-in available.

{
  "rules": [],
  "settings": {
    "signin_help_url": "https://it.example.com/kiro-help"
  }
}

Every method stays available and the sign-in screen shows the link.

A Kiro profile administrator can turn off device flow sign-in for that profile. In the Kiro console, open Settings > Device flow authentication, then turn off Users can sign in to the Kiro CLI using device flow.

When the setting is off:

• kiro-cli login and kiro-cli profile hide that profile during device flow sign-in.
• If some profiles remain, the CLI shows how many were hidden and continues with the available profiles.
• If no profile remains during login, the CLI refuses device flow sign-in, clears that sign-in, and directs the user to browser sign-in.
• A refused profile switch keeps the current profile active.
• Browser sign-in remains unchanged, and profiles set to on or left unset remain available.

The change applies the next time a device flow credential is bound to a profile. It does not end a session that is already running.

• On the sign-in screen, only the permitted methods appear, and the Identity Center fields are prefilled from your settings. In the IDE, the help link appears below the sign-in buttons as Need help signing in? and opens in the browser. In the CLI, kiro-cli login prints Need help signing in? <url> before it opens the browser.
• If a denied method completes anyway, for example because the sign-in URL was edited, Kiro refuses it before a token is issued and names the permitted options by their on-screen labels. For example: Google sign-in is not permitted by your administrator. Sign in with "Your organization" instead. The help URL, when configured, follows on its own line.
• In the CLI device-code flow (kiro-cli login --use-device-flow, or a remote machine without a browser), the menu offers only the permitted methods among AWS Builder ID, Google, GitHub, and Your Organization (Identity Center). With one permitted method, the CLI uses it without showing the menu. With none, the CLI explains that no permitted method works without a browser and how to proceed.

Sign-in controls fail open. A mistake in the file never blocks sign-in; it drops the affected control and warns the user so you can fix it. The IDE shows a notification and the CLI prints a Warning: line when kiro-cli login starts, each naming the file and the cause.

• Unreadable or invalid file: If the file is not valid JSON, starts with a byte order mark, is not UTF-8, or has a known key of the wrong type, no sign-in controls are applied. Because the same file carries permission policies, an invalid file also blocks the agent's tools until it is fixed.
• Rule dropped, all methods available: The restriction is ignored, while the settings keys still apply, when the effect is anything other than deny, when a name in exclude is not recognized, when no name in match is recognized, when the rules together deny every method, when they deny no method (for example, exclude covers everything match denies), or when a rule names more than 16 entries.
• Rule narrowed: When match mixes recognized and unrecognized names, the recognized names are still denied and the user is warned that an entry was dropped.
• Setting dropped: A URL that does not use https, or any value that is too long or contains control characters, is ignored on its own. The other settings and the rule still apply.
• Unknown keys: Extra keys in settings are ignored, which lets a newer file work on an older client.

After deploying the file to a test machine:

1. Sign out of Kiro (kiro-cli logout in the CLI, or sign out from the account menu in the IDE) and start a new sign-in
2. Confirm the browser page offers only the permitted methods, with the start URL and Region already filled in
3. Confirm the help link appears on the IDE sign-in screen, or that kiro-cli login prints the Need help signing in? line
4. Confirm no warning about the managed settings file appears. A warning means part of the file did not apply, and it names the cause

Sign-in controls work alongside Kiro's other enterprise features:

• Identity providers set up the Identity Center or external identity provider connection your users sign in with
• Subscription management controls which users have access to Kiro
• Permission policies share the same file and control what the agent can do after sign-in
• Authentication describes the sign-in flow your users follow on each surface