Get started with Enterprise Management

Follow this page to review the controls Kiro created for your profile and publish your first change, so that every developer on that profile gets a working Kiro with the rules you chose. You need to be an administrator of the AWS account that owns the profile. Kiro Enterprise Management is in preview for new Kiro profiles created in US East (N. Virginia) (us-east-1). It is on for all newly created profiles there; existing profiles are not affected by this change. For what a rule can and cannot decide on a developer's behalf, see Security and trust. When you are done, pick a policy that fits your organization from KGL examples and look up any field in the KGL reference.

• A newly created Kiro profile in US East (N. Virginia) (us-east-1); existing profiles are not affected by the preview. Publishing a change reaches every user of the Kiro profile at once, so try your first change on a profile with few users.
• A Kiro profile in us-east-1 with IAM Identity Center, Okta, or Microsoft Entra ID as its identity source.
• An administrator role that allows the q:*EnterpriseManagement* IAM actions. AdministratorAccess is enough.
• Users subscribed to Kiro who sign in through the profile's identity source in Kiro CLI 3.1.0 or later, Kiro IDE 1.4.154 or later, or Kiro Web at app.kiro.dev. Keep one developer sign-in for yourself: the client-side checks on this page, such as opening the model picker, run as a developer on the profile.
• The AWS CLI with the Enterprise Management service model. The aws kiro-em commands on this page need it. See Protocol.
• For a profile that had settings before Enterprise Management, a note of every value on its Kiro Settings page. When Enterprise Management is turned on, those values stop applying for every user of the profile and are not copied into the policy. See What changes from the console settings.

Rules that apply to one group or one user use IDs, not names. The console's Form view gives the ID for every identity source; two identity sources also show it in their own console. Write the IDs down before you write a rule in YAML.

A group name in place of a group ID makes Publish fail with "Encountered unexpected error when processing request".

1. Install Kiro CLI 3.1.0 or later, or update the Kiro IDE to 1.4.154 or later.
2. Sign in to each client through the profile's identity source. With IAM Identity Center, that is your start URL, for example https://d-1234567890.awsapps.com/start.

To verify, confirm that each client finishes sign-in. If your organization already distributes a steering file, it arrives at ~/.kiro/cloud-cache/resolved/config/organization/steering/ after sign-in.

Kiro created the controls for your profile, and published them, when it created the profile. Review them before you change anything.

1. In the AWS console, in us-east-1, open Kiro > Controls. The Profile Controls page shows the live revision, who published it, and the profile it applies to.

2. Choose Edit. Rules and settings opens in the Form view, with one section per area: Models, MCP, Shell, Network and web, Filesystem, Skills, powers and agents, Agent behavior, Sessions and access, Privacy and telemetry. Switch to YAML to read the whole policy as KGL. Note which capabilities have a rule and what the settings block holds; a rule you did not write came with the profile.

3. Make your first change in the Form view. Under Models, Model availability rules lists the model_use rules; open one to change Allow or Deny, add model IDs or wildcards, add exceptions, or limit it to users and groups. Open Default model to pick another model; the list holds only the models your model_use rules allow. Developer override set to Can update lets a developer pick their own model (!replace in YAML); Not allowed fixes it for everyone.

4. Under Models, turn Model governance on. A new profile ships with it off, and until it is on the model_use rules do not limit which models developers see. Changes are saved to the draft as you make them.

5. Choose Publish. Publish checks the policy and stops on errors; the YAML view counts errors and warnings as you type. After it finishes, the page shows the new revision as Live.

To verify, restart the clients and, as a developer on the profile, open the model picker (/model in the Kiro CLI). Expect the models your model_use rules allow. Run checks on client-enforced capabilities, such as shell and fs_write, in the Kiro CLI or the Kiro IDE (see Enforcement status). A change takes up to five minutes to reach the client after Publish; restart the client to get it sooner. If the model list is empty after five minutes, check that the revision is Live, then sign out and sign in again.

1. On the Profile Controls page, choose Edit, then change a rule or setting in the Form view or the KGL in the YAML view. Changes are saved to the draft as you make them; a draft does not affect any developer. Finish editing closes the draft without publishing.
2. Choose Publish. Publish checks the policy and stops on errors. Only Publish makes a change live. Before you publish, Actions > View changes shows what the draft changes against the live revision.
3. For a rule or setting, wait up to five minutes, or restart the client. For a file, start a new session; a running session keeps the old copy.

You can also make each change with the AWS CLI or the API. For when to use each, see Ways to manage a policy.

For console behavior you may meet while editing, see Known issues.

To verify, confirm the new revision number next to Live, then check the behavior in a client: a rule or setting after five minutes or a restart, a file in a new session.

Every Publish makes a numbered revision. Actions > Revision history lists them. Actions > Download saves the current KGL as a file, which is also the way to keep a copy before a large change.

To stop applying controls to a profile, remove the assignment. The policy stays in the account.

Use the AWS CLI. First list your policies to get the policy's resource ID and confirm which profile it governs:

aws kiro-em list-enterprise-management-resources --region us-east-1

Then remove the assignment. <resource-id> is the policy ID from the list; <profile-id> is the Kiro profile ID from the Kiro console.

aws kiro-em disassociate-enterprise-management-resource \
  --region us-east-1 \
  --resource-id <resource-id> \
  --scope-type PROFILE \
  --scope-id <profile-id>

Disassociate a policy before you delete it. If you delete a policy while it is assigned, the profile stays bound to it and assigning another policy fails with "already associated with resource …"; disassociate the deleted policy by its ID. For the command and its fields, see DisassociateEnterpriseManagementResource.

To verify, list the resources again and confirm that the profile is no longer associated.

After a change, ask developers to restart Kiro, or wait five minutes. A rule that blocks something shows no message from you; Enterprise Management has no custom rule messages, so tell developers whom to contact.

Pick a policy that fits your organization from KGL examples, look up any field in the KGL reference, then check which capabilities are enforced in Enforcement and limits.