Kiro 企業治理：控制企業環境中的登入選項

Hi! I’m Girish, an AWS Community Builder and cloud technology enthusiast. I enjoy exploring AWS services, building hands-on projects, and sharing what I learn with the community.

As agentic development tools become part of enterprise engineering, governance is becoming just as important as productivity. Kiro IDE brings AI-powered capabilities to developers, but enterprise administrators also need control over how developers access these tools.

Kiro already provides several governance controls. In October 2026, AWS introduced another: the ability for administrators to control which sign-in options are available to developers.

If you haven’t read my previous article on Kiro’s enterprise governance features, I recommend checking it out to understand the bigger picture.

Kiro’s managed settings let an administrator restrict the sign-in choices presented on a managed device. In this hands-on walkthrough, I’ll configure two policies: one that keeps AWS IAM Identity Center (IDC) sign-in, and another that keeps both IDC and AWS Builder ID.

The control shapes Kiro’s sign-in experience. It does not create or configure the organization’s identity provider, subscriptions, or device-management policies.

Here is how Kiro sign-in screen looks like before applying managed sign-in controls.

What are we trying to control?

Kiro supports sign-in through AWS IAM Identity Center, external identity providers such as Okta, AWS Builder ID, Google, and GitHub. Social sign-in through Google or GitHub, along with AWS Builder ID, can be convenient for learners and individual developers. Organizations may prefer enterprise-managed sign-in through AWS IAM Identity Center or a supported external identity provider.

A company may want to offer only its approved sign-in methods on managed devices. In this article, I’ll focus on Kiro’s device-level control: a system-protected managed-settings.json file that the IDE and CLI read to apply sign-in restrictions.

When developers use personal accounts or sign in through methods outside an organization’s approved identity setup, that can create a shadow IT concern: the organization may have less visibility into who is accessing the tool and under which account. Managed sign-in controls can reduce that gap on devices where the policy is deployed, but they work alongside device management and identity-provider controls.

A sign-in rule uses the capability name signin_method and the effect deny. With match set to ["*"], the rule targets all methods; the exclude list names the methods to keep available. These method identifiers are case-sensitive: idc means AWS IAM Identity Center and builder_id means AWS Builder ID.

The control does more than hide buttons: Kiro checks the chosen method again when sign-in returns and refuses a denied method before issuing a token. If the file or rule is invalid, Kiro drops the restriction, leaves sign-in methods available, and displays a warning. This behavior is called failing open. It avoids locking everyone out, but it means administrators should watch for warnings and validate the rollout.

Sign-in governance scenarios

I will demonstrate this feature by using two scenarios noted below.

Scenarios

1. IDC only
2. IDC and Builder ID

Methods kept available

• AWS IAM Identity Center
• AWS IAM Identity Center and AWS Builder ID

Example objective

• Require organization-managed sign-in
• Allow both organization and Builder ID sign-in

Both examples use an allowlist, or approved-method list: the rule denies every method, then the exclude list keeps the approved method or methods available.

Configuration and implementation

For this walkthrough, I’m using macOS to demonstrate where to place the managed settings file. The sign-in control itself applies to Kiro on supported platforms.

Place the file on macOS

On macOS, Kiro’s managed settings file is stored at this system-level path:

/Library/Application Support/Kiro/managed-settings.json

An administrator can create the folder and edit the file in Terminal:

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

To deploy this setting across your organization, use your enterprise device-management solution. If a managed-settings.json file already contains permission rules, add the sign-in rule to the existing rules array. Keep the rest of the organization’s policy intact.

Scenario 1: allow only AWS IAM Identity Center

Once these settings are applied and you try to login to Kiro, you should see the login screen similar to below:

If you click on show all options, you would only see one login option since these settings are in effect.

Scenario 2: allow AWS IAM Identity Center and AWS Builder ID

Once these settings are applied and you try to login to Kiro, you should see the login screen similar to below:

The only change to the allowlist is adding builder_id. Under this rule, Google and GitHub remain denied. The Identity Center settings still prefill the organization’s details when a user chooses that method.

Validation

Start by testing on a device where Kiro is installed. For each scenario, deploy the matching managed settings file, then sign out and begin a new sign-in. The IDE reads the managed file locally; if you also test Kiro CLI, sign out there and start a new CLI sign-in as well.

• Confirm the managed-settings.json file is present at the path used by your deployment and is readable by Kiro.
• Check that the JSON is valid and that capability is signin_method, effect is deny, and the exclude values match the intended scenario.
• For Scenario 1, confirm the sign-in page offers only “Your organization” (AWS IAM Identity Center).
• For Scenario 2, confirm the sign-in page offers “Your organization” and AWS Builder ID, with Google and GitHub absent.
• If configured, confirm the Identity Center start URL and Region are prefilled and the help link opens your HTTPS help page.
• Check that Kiro shows no managed-settings warning. A warning means a setting or restriction may have been ignored; correct the cause before broad deployment.

If the options do not match the policy, recheck the file path, JSON syntax, method spelling, and supported Kiro versions. Current Kiro sign-in-control documentation lists support for Kiro IDE 1.2 and later and Kiro CLI 2.25.0 and later; the feature’s rollout or service-region availability can impose additional requirements. Check the current official documentation for your environment before rollout.

Restore all sign-in options

To remove this device-level sign-in restriction, remove the managed settings file and start a new sign-in:

sudo rm "/Library/Application Support/Kiro/managed-settings.json"

Then sign out of Kiro and begin a fresh sign-in. With no managed sign-in rule applied, Kiro returns to offering the sign-in methods supported for that client and environment. If the file also contains permission policies or other managed settings, deleting it removes those too; preserve the file and remove only the signin_method rule when you need to keep the other settings. If your device-management system deployed the file, update that deployment as well or it may be installed again.

Conclusion

In this article, I demonstrated how Kiro’s managed settings can help administrators control which sign-in options are available on managed macOS devices. I walked through two practical policies: allowing AWS IAM Identity Center only, and allowing both AWS IAM Identity Center and AWS Builder ID. I also covered how to validate the configuration and what to check if a policy does not apply as expected.

Sign-in controls are one part of a broader enterprise governance approach. They can help align the sign-in experience with approved identity methods and reduce the chance that developers use unapproved accounts on managed devices. They work alongside identity-provider setup, subscription management, device management, and Kiro’s other governance controls; they do not replace those controls.

As AI-powered development tools become a regular part of software engineering, organizations will need practical ways to support developer productivity while managing access responsibly. A clear sign-in policy is a useful step toward that balance.

Try these configurations in a test environment first, and confirm the sign-in options on a managed device before rolling them out more broadly.

Thanks for reading, and I hope you found this walkthrough useful.

Keep Learning!

Watch the video here:

Thanks,

𝒢𝒾𝓇𝒾𝓈𝒽 ℬ𝒽𝒶𝓉𝒾𝒶
𝘈𝘞𝘚 𝘊𝘰𝘮𝘮𝘶𝘯𝘪𝘵𝘺 𝘉𝘶𝘪𝘭𝘥𝘦𝘳 | 𝘈𝘐 𝘌𝘯𝘨𝘪𝘯𝘦𝘦𝘳𝘪𝘯𝘨
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘚𝘰𝘭𝘶𝘵𝘪𝘰𝘯 𝘈𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘋𝘦𝘷𝘦𝘭𝘰𝘱𝘦𝘳 𝘈𝘴𝘴𝘰𝘤𝘪𝘢𝘵𝘦
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘎𝘦𝘯𝘈𝘐 𝘗𝘳𝘢𝘤𝘵𝘪𝘵𝘪𝘰𝘯𝘦𝘳
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘊𝘭𝘰𝘶𝘥 𝘗𝘳𝘢𝘤𝘵𝘪𝘵𝘪𝘰𝘯𝘦𝘳
𝘈𝘞𝘚 𝘊𝘭𝘰𝘶𝘥 𝘛𝘦𝘤𝘩𝘯𝘰𝘭𝘰𝘨𝘺 𝘌𝘯𝘵𝘩𝘶𝘴𝘪𝘢𝘴𝘵