Kiro Enterprise Management lets you, the administrator, control how Kiro works for every developer in your organization from one place in the AWS console. You define the controls once, and Kiro applies them in the Kiro IDE, the Kiro CLI, and Kiro Web. 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. It works with IAM Identity Center, Okta, or Microsoft Entra ID as the identity source. Publishing a change reaches every user of the profile at once. Some capabilities are enforced by the client rather than the service; Kiro CLI 3.1.0 or later and Kiro IDE 1.4.154 or later apply those rules. To set it up, follow Get started with Enterprise Management.
The controls have three parts.
| Part | What it does | Example |
|---|---|---|
| Rules | Allow or deny each thing Kiro can do (a capability), or make Kiro ask the developer first. A rule can apply to everyone, to one group, or to one user. | Deny the claude-opus-* models. Ask before Kiro runs git push. Let only one group create API keys. |
| Settings | Set the values that every client uses, and decide whether a developer can change them. | Lock the default model. Send prompt logs to your S3 bucket. Turn on daily activity reports. |
| Files | Distribute the steering files, Skills, and Powers you choose to developers. | An organization coding standard as a steering file. Shared Skills and Powers. |
- In the AWS console, open Kiro > Controls. Each Kiro profile has its own controls; Kiro created and published them when it created the profile. Edit rules and settings in the Form view or as KGL text in the YAML view, and files on the Agent customizations tab.
- Choose Edit to open a draft. Changes are saved as you make them. Nobody gets a draft. Only Publish makes a change live.
- Publish checks the draft and makes it a numbered revision. Actions > Revision history lists them.
- The controls are assigned to the Kiro profile named on the page. Every user of that profile gets the published rules and settings within about five minutes; files arrive when the next session starts. See How changes reach developers.
The console Form view, the console YAML view, the AWS CLI, and the API all work on the same controls, which the AWS CLI and the APIs call a policy: a draft, numbered published revisions, and an assignment to a Kiro profile. The console uses the same APIs.
| Console Form | Console YAML | AWS CLI | API | |
|---|---|---|---|---|
| Who | An administrator | An administrator | An administrator or a script | Your own tooling |
| Writes | Form fields | The policy as KGL text | KGL files | KGL files |
| Checks | Publish | As you type, and Publish | Validate, then Publish | Validate, then Publish |
| Assigns | Done for you | Done for you | Associate | Associate |
| Removes an assignment | Use the AWS CLI | Use the AWS CLI | Disassociate | Disassociate |
| Needs | Console access | Console access | The service model for the AWS CLI | A SigV4-signed client |
In the console, the YAML view counts errors and warnings as you type, and Publish checks the policy and stops on errors. With the AWS CLI and the API, Validate returns the diagnostics without publishing. The AWS CLI needs the Enterprise Management service model; the API needs a SigV4-signed client, see Protocol. The AWS CLI command and API operation for each row are listed in order in Common tasks.
Prefer:
- The Form view to add or change one rule or setting, and to pick users and groups for a rule's condition. With Okta it is the only way to get a user or group ID.
- The YAML view to paste a whole policy from KGL examples, to see every rule at once, and to copy the KGL for a script.
- The AWS CLI to script changes.
- The API when you build your own tooling. See the API reference.
| Term | Meaning |
|---|---|
| Controls | The rules, settings, and files for a Kiro profile. The console page is Kiro > Controls. |
| Policy | The same thing as controls. The text file, the AWS CLI, and the APIs call it a policy. |
| KGL | Kiro Governance Language, the YAML format of the policy file. See the KGL reference. |
| Capability | One thing Kiro can do, such as model_use, shell, web_fetch, or mcp. Each rule names one capability. |
| Kiro profile | Your Kiro profile, the Kiro subscription setup in your account. Controls apply to the users of the profile they are assigned to. |
| Revision | One published state of the controls. Every Publish makes a new one. The APIs call it a version. |
| Assign | Connect published controls to a Kiro profile. The console does this for you; the APIs call it associate. |
On a profile with Enterprise Management, the Kiro Settings page says "Your settings are now in Controls" and keeps the shared profile details, the encryption key, and member account subscriptions. The Kiro settings moved to Controls: choose See where each setting went on the Settings page for the map, which shows each setting's lines in YAML. On a new profile, set these values as policy settings. When Enterprise Management is turned on for an existing profile, the values on its Settings page stop applying at once for every user and are not copied into the policy, so write them down first, then put them back as policy settings.
| Console setting | Policy setting key |
|---|---|
| Default model | default_model |
| Model availability and Manage approved list | model_use rules, with model_governance.enabled |
| Cloud Sessions (Kiro Web) | cloud_sessions.enabled |
| Prompt logging and its S3 location | prompt_logging.enabled, prompt_logging.destination |
| Kiro usage dashboard | usage_dashboard |
| Kiro user activity report and its S3 location | user_activity_report.enabled, user_activity_report.csv_export, user_activity_report.csv_destination |
| OpenTelemetry export | user_activity_report.otel_export, user_activity_report.otel_secret_arn, user_activity_report.otel_protocol |
| MCP registry URL | mcp_registry_url |
The console toggles for model access, web tools, MCP, and API keys become rules on the model_use, web_search, web_fetch, mcp, and apikey_create capabilities. For every key and value, see Setting keys.
Enterprise Management policies are delivered by the Kiro service. The client-side managed-settings.json file described in Permission policies is a separate mechanism.
- Profiles: the preview is on for all newly created Kiro profiles in US East (N. Virginia) (
us-east-1); existing profiles are not affected by this change. - Identity: IAM Identity Center, Okta, or Microsoft Entra ID. With Okta, user and group IDs for rule conditions come from the console's Form view; see Find user and group IDs.
- Clients: Kiro CLI 3.1.0 or later, Kiro IDE 1.4.154 or later, and Kiro Crew LTS. Some capabilities are enforced by the Kiro service on every client. Others are enforced by the client; Kiro CLI 3.1.0 or later, Kiro IDE 1.4.154 or later, and Kiro Crew LTS apply those rules. See Enforcement status.
- Models, API keys, and Kiro Crew messaging and network access are denied until a rule allows them; the controls Kiro creates for a new profile allow every model. Files, shell, web, MCP, and Kiro Crew scheduled jobs keep Kiro's own default until a rule names them. See How rules combine.
- A few KGL fields and settings are accepted but not supported. Before you use one, check Not supported.
Rules decide on the developer's behalf. An allow rule lets Kiro act without asking, a deny rule blocks the action, and an ask rule makes Kiro ask the developer before it acts. Models, API keys, and Kiro Crew messaging and network access stay denied until a rule allows them; the built-in tools and Kiro Crew scheduled jobs keep Kiro's own default until a rule names them. You scope a rule to one group or one user with a when condition, and you remove controls from a profile by removing the assignment. How rules combine is written once, on the KGL reference.
Get started with Enterprise Management: check the prerequisites, review the controls Kiro created for your profile, and publish your first change.
Enterprise Management (preview)