AWS Builder Center

Builder Center

Kiro Administrator Guide: Security and Governance

Kiro Administrator Guide: Security and Governance

Kiro settings that help administrators limit data leakage, agent mishaps, and uncontrollable cost, with each default and how to change it.

Purnaresa Y

Disclosure: written by Purnaresa Y, Security Solutions Architect at AWS, assisted by Claude Opus 5.5.

Summary

Kiro is an agentic tool that helps engineers in many ways. It is good practice to govern how your organization uses agentic tools. Letting employees use tools without governance brings risks of data leakage, agent mishaps, and uncontrollable cost.
If your organization is exploring Kiro or already uses it, this article gives administrators a to-do list for establishing security and governance best practices for Kiro in your organization. I will update the list as agentic tools change. The list is valid as of October 2026.

Decide what agents and users can reach

These five settings decide which models, tools, and sign-in methods users and agents can use, which makes them your main controls against data leakage and agent mishaps. Four of the five defaults are open. Each one needs a decision before rollout.

1. Approve the models users can use (Model availability)

Model availability lets you choose which models users can select in Kiro and set a default model. [1]
Default setting: Off. Users can use any model Kiro supports.
When to configure it: Models differ in inference scope and endpoint location, which is why each one needs a review against your data residency and compliance rules. With the default, every new model Kiro adds reaches your users before anyone reviews it. Turn the list on if your organization has such rules.
 
Short setup guide:
  1. Open the Kiro console and choose "Settings".
  2. Under "Shared settings", turn on "Control which models are available to users" in the Model availability setting.
  3. Choose "Manage approved list", select the models, and set a default model. The list includes "Auto", Kiro's model router.
  4. Choose "Save list".
 
Implication: Auto needs a decision of its own, because it may route requests to any Active model in your profile, including models outside your approved list. To keep processing on approved models only, block Auto and set an approved model as the default. [2] Changes reach users after they restart their session or sign out and sign in again. Once the list is on, new Kiro models stay unavailable until you add them, while the console tells you when one appears.
Keep Kiro clients on the latest version, because older clients may not enforce the list properly.

2. Control which MCP servers run (Model Context Protocol)

MCP servers extend Kiro by connecting it to external services and APIs. You can turn MCP off, or give Kiro a registry URL that lists the only servers users may use. [3]
Default setting: On, with no registry URL. Users can use any MCP server.
When to configure it: Under the default, each local server a user adds runs with the same access as the agent, including source code, environment variables, and credentials. Kiro does not vet or sandbox third-party servers, which is why a compromised one can send code, credentials, and data out without another confirmation from the user. [4] Turn MCP off if your policy allows no external tools, or use a registry if you have a vetted list.
 
Short setup guide:
To turn MCP off:
  1. Open the Kiro console and choose "Settings".
  2. Under "Shared settings", set "Model Context Protocol (MCP)" to Off.
To allow only listed servers:
  1. Write a registry JSON file that lists the allowed servers. The format is a subset of the MCP registry standard v0.1.
  2. Serve the file over HTTPS with a certificate from a trusted certificate authority. Self-signed certificates are not supported. The URL can be private to your network, and users' computers must be able to reach it.
  3. In "Settings", keep MCP on, choose "Edit" on "MCP Registry URL", enter the URL, and choose "Save".
 
Implication: Kiro reads the registry at startup and every 24 hours. A local server that is no longer listed is stopped and cannot be added back, while a server with a different version is relaunched at the registry version. Users can still add their own environment variables and headers, and change timeout, scope, and tool trust permissions. If the client cannot reach the governance API, MCP stays off until the client reconnects.
Both the toggle and the registry are enforced on the client, which means a user with administrative access to their own machine can circumvent them. The controls also cover only users who sign in with IAM Identity Center or API keys, while Builder ID and social sign-in users fall outside them.

3. Decide whether agents can use the web (Web search and web fetch tools)

One switch controls the web_search and web_fetch tools. [5]
Default setting: On. Users can search the web and fetch content from URLs.
When to configure it: With the default, the agent reads web content that nobody in your organization has checked. That content can be wrong. It can also carry hidden instructions that change what the agent does, which OWASP calls indirect prompt injection. In one OWASP example, summarizing a web page with hidden instructions leaks the private conversation. [6] Turn the tools off if your organization trusts only vetted sources, such as internal MCP servers.
 
Short setup guide:
  1. Open the Kiro console and choose "Settings".
  2. Under "Shared settings", set "Web search and web fetch tools" to Off.
 
Implication: Both tools turn off together. Kiro hides them from users and shows a notice in /tools that the administrator disabled web access. The setting is enforced on the client, which means a user with administrative access to their own machine can modify it.

4. Keep API keys off unless automation needs them (API keys)

API keys let developers run Kiro CLI in automation scripts on a local machine or in a remote environment such as a CI/CD pipeline. [7]
Default setting: Off. Users cannot generate API keys.
When to configure it: A key belongs to a user's account, which is why anyone who holds it can use Kiro as that user. [8] Because pipelines keep keys in secrets and scripts, each pipeline adds a place where a key can leak. Keep the setting off until a team needs Kiro CLI in automation.
 
Short setup guide:
  1. Open the Kiro console and choose "Settings".
  2. Under "Kiro settings", turn on "Enable users to generate API keys".
  3. Users then sign in to the Kiro portal to generate their keys.
 
Implication: Your governance rules still apply to sessions that use a key, including MCP restrictions, model access, and web fetch permissions. The keys themselves need the same care as any automation credential. Teams should store them as secrets in the CI/CD platform and never in pipeline files or source control. They should also rotate keys regularly and revoke the ones they no longer use. The docs do not say whether this switch is enforced on the server or on the client.

5. Decide whether the CLI can sign in with device flow (Device flow authentication)

Device flow is a CLI sign-in method that works on a remote machine without a browser (kiro-cli login --use-device-flow). The setting is per Kiro profile. [9]
Default setting: On. Device flow sign-in is available unless you turn it off.
When to configure it: Device flow lets a user approve a sign-in by entering a code on a second device. The OAuth device flow standard lists remote phishing as a risk of this design. [10] In that attack, someone starts the flow on their own device and sends the target a link and a code, for example by email. A target who enters the code approves the attacker's device. Turn device flow off if CLI users always have a browser on the machine they sign in from. Keep it on if people use the CLI on remote machines without one.
 
Short setup guide:
  1. Open the Kiro console and choose "Settings".
  2. In "Device flow authentication", turn off "Users can sign in to the Kiro CLI using device flow".
 
Implication: With the setting off, kiro-cli login and kiro-cli profile hide that profile during device flow sign-in. A user left with no profile is refused and pointed to browser sign-in, which stays unchanged. The change applies the next time a device flow credential is bound to a profile. Sessions already running keep working.

Keep a record of what happens

The settings above limit what agents and users can do. The next two record what they did, which gives you something to audit after the fact.

6. Log prompts when you need an audit trail (Prompt logging)

Prompt logging records inline suggestions and chat conversations from the Kiro IDE and CLI. It logs both the user prompts and Kiro's responses. Kiro stores the logs in an Amazon S3 bucket in your account. [11]
Default setting: Off. Kiro starts logging when you turn it on and enter an S3 location.
When to configure it: With the default, your account holds no record of what users sent to Kiro or what Kiro answered. Turn logging on if you need that record for audit or compliance. Agree on it with your privacy and legal teams first, because the logs hold what users type.
 
Short setup guide:
  1. Create an S3 bucket in the Region where the Kiro profile was installed and in the account where users are subscribed.
  2. Add a bucket policy that lets the service principal q.amazonaws.com call s3:PutObject on your prefix. The policy limits the call to Kiro in your account and Region. The docs give the full policy.
  3. In the Kiro console, choose "Settings", find "Kiro Settings > Logging", and turn on "Log Kiro prompts with metadata".
  4. Enter the S3 URI, for example s3://amzn-s3-demo-bucket/kiro-prompt-logs/.
 
Implication: Each log holds the prompt text, Kiro's response, and the user ID. Logs of inline suggestions also hold the code before and after the cursor. Anyone who can read the bucket can read what your users typed, so restrict access to it. The docs point to Amazon S3 encryption to protect the data. Logging itself has no charge, while you pay for S3 storage and the optional KMS key that encrypts the bucket.

7. Export per-user activity (Kiro user activity report)

Kiro exports daily per-user activity as CSV files in S3, as OpenTelemetry metrics to your collector, or both. The data includes credits used, overage use, message counts, and message counts per model. [12]
Default setting: Off. Kiro starts exporting when you turn it on and enter an S3 location.
When to configure it: The usage dashboard shows totals only, which leaves no way to see which user consumed credits or overages. Turn the report on if you need to tie usage to a person, for example to review unusual consumption. Do it early, because the first report arrives at the next 02:00 UTC after you enable it.
 
Short setup guide:
  1. Create an S3 bucket in the Region where the Kiro profile was installed and in the account where users are subscribed. Add a prefix for the files and the same bucket policy that prompt logging uses.
  2. In the Kiro console, choose "Settings", and under "Kiro user activity reports" choose "Edit".
  3. Turn on "Collect granular metrics per user".
  4. Enter the S3 location, for example s3://amzn-s3-demo-bucket/user-activity-reports/.
 
Implication: Each row of the report includes the user's email address, which makes the files personal data about your users. Only administrators can turn the report on or off. Kiro writes one file per client type (IDE, CLI, and Plugin) each day. Users subscribed in several accounts need a bucket in each account, because cross-account buckets are not supported. The docs recommend keeping these files apart from the prompt log bucket.

Keep spending predictable

Uncontrollable cost is the third risk in the Summary. Overages decide where spending stops, while the dashboard shows how it grows.

8. Decide whether users can exceed plan limits (Overages)

Overages let users keep working after they pass their plan limits. Once on, they apply to all users and groups in the profile. [13]
Default setting: Off.
When to configure it: The default stops usage at each user's plan limit, which keeps spend per user predictable. Turn overages on only if interrupted work costs your organization more than the extra spend, and set the cap when you do.
 
Short setup guide:
  1. Open the Kiro console and choose "Settings".
  2. In the "Kiro settings" section, turn on "Overages".
  3. To set the cap, open the Service Quotas console in us-east-1, search for Kiro, and edit "Maximum allowed overage per Kiro profile". The "Manage" link on the Overages setting opens the same quota.
 
Implication: Overage use costs extra beyond the subscription price. The default cap adjusts automatically with your account's usage history and standing, while a higher cap needs an increase request in Service Quotas. The quota applies to every user in the profile. Per-user overage use appears in the activity report, which is where to look when spend grows.

9. Track usage on the dashboard (Kiro usage dashboard)

The dashboard in the Kiro console shows subscriptions per tier (total, active, and pending), active users, and credits consumed. Only Kiro administrators can see it. Most metrics update hourly, and active users update daily by UTC clock. [14]
Default setting: On.
When to configure it: Keep it on, because it shows credits consumed over time, which makes unexpected growth in usage visible. Turn it off only if you have data privacy or page load concerns.
 
Short setup guide:
  1. In the Kiro console navigation pane, choose "Dashboard".
  2. To turn it off, choose "Settings", and in "Kiro Settings" disable "Kiro usage dashboard".
 
Implication: Viewing the dashboard needs the permissions q:ListDashboardMetrics, codewhisperer:ListProfiles, sso:ListInstances, and user-subscriptions:ListUserSubscriptions. The split between active and pending subscriptions helps you size licenses, because you are charged for active subscriptions and not for pending ones. For detail per user, use the activity report.

Takeaway

Governing Kiro in the console takes three groups of decisions.
  1. Decide what agents and users can reach. Four of the five defaults are open, so set model availability, MCP, web tools, and device flow to match your policy, and enable API keys only for teams that need automation.
  2. Keep a record of what happens. Prompt logging and the user activity report are off by default, so turn them on when you need an audit trail or a per-user view.
  3. Keep spending predictable. Overages are off by default, which limits spend, and the usage dashboard is on by default so you can watch credits consumed.
 
Controls deployed to devices sit outside the console. Permission policies and sign-in controls, for example, live in the managed-settings.json file. [9] Governing how your organization uses Kiro starts with the nine console settings, each reviewed against the risks of data leakage, agent mishaps, and uncontrollable cost.

References

  • [1] Kiro Docs, Models governance, https://kiro.dev/docs/enterprise/governance/model/
  • [2] Kiro Docs, Available models, https://kiro.dev/docs/models/available-models/
  • [3] Kiro Docs, MCP governance, https://kiro.dev/docs/enterprise/governance/mcp/
  • [4] Kiro Docs, MCP best practices, https://kiro.dev/docs/mcp/security/
  • [5] Kiro Docs, Web tools governance, https://kiro.dev/docs/enterprise/governance/web-tools/
  • [6] OWASP GenAI Security Project, LLM01:2025 Prompt Injection, https://genai.owasp.org/llmrisk/llm01-prompt-injection/
  • [7] Kiro Docs, API keys governance, https://kiro.dev/docs/enterprise/governance/api-keys/
  • [8] Kiro Docs, Headless mode, https://kiro.dev/docs/cli/headless/
  • [9] Kiro Docs, Sign-in controls, https://kiro.dev/docs/enterprise/governance/sign-in/
  • [10] IETF, RFC 8628 OAuth 2.0 Device Authorization Grant, Section 5.4, https://www.rfc-editor.org/rfc/rfc8628#section-5.4
  • [11] Kiro Docs, Logging user prompts, https://kiro.dev/docs/enterprise/monitor-and-track/prompt-logging/
  • [12] Kiro Docs, Per-user activity, https://kiro.dev/docs/enterprise/monitor-and-track/user-activity/
  • [13] Kiro Docs, Managing subscriptions, https://kiro.dev/docs/enterprise/subscription-management/
  • [14] Kiro Docs, Kiro usage dashboard, https://kiro.dev/docs/enterprise/monitor-and-track/dashboard/
# kiro# security# governance
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article