Privacy and security

Kiro is an AWS application that works as a standalone agentic IDE. Kiro's security framework is built around AWS's security infrastructure and follows practices to protect your development environment and data. Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.

Security is a shared responsibility between AWS and you. The shared responsibility model describes this as security of the cloud and security in the cloud:

• Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS Compliance Programs. To learn about the compliance programs that apply to Kiro, see AWS Services in Scope by Compliance Program.

• Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations

This documentation helps you understand how to apply the shared responsibility model when using Kiro. It shows you how to configure Kiro to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Kiro resources.

In the Kiro chat module, you can paste a specific URL for your device to fetch and use it as context to help Kiro answer your query or solve your task. You are responsible for the URL content that you fetch and ensuring that your use complies with any applicable third-party terms and laws.

Kiro offers two interaction modes, Autopilot and Supervised, that control how you review agent actions. Both modes grant the agent the same capabilities: creating, modifying, searching, and deleting files in your codebase and running commands that impact the filesystem. The difference is the review workflow, not the underlying permissions or access scope.

In both modes, the agent writes file changes to disk during tool execution. In supervised mode, these writes are tagged for your review. After the agent's turn completes, Kiro checks for pending file changes and prompts you to accept or reject before continuing. If you reject, files revert to their pre-turn state.

Kiro classifies the following operations as file-modifying. Any of these operations triggers a mandatory review prompt at the end of the agent's turn:

This review check is built into Kiro's workflow and cannot be skipped by the AI model. If a file-modifying operation ran during the turn, the approval prompt will appear.

Shell commands follow a separate approval path. By default, all commands require your approval before execution (see trusted commands). To maintain full oversight, keep your trusted commands list minimal and avoid broad wildcards.

When supervised mode is enabled, Kiro enforces the following behaviors for file-modifying operations:

• Turn-level review for file-modifying operations: Every file-modifying operation listed above results in an approval prompt before changes are applied.
• Automatic revert on rejection: If you reject, files are restored to their exact state before the agent's turn began.
• Protected path enforcement: Writes to protected paths require explicit approval before the write occurs, in both modes.
• Command approval: Unrecognized commands require your approval before execution, in both modes.

Supervised mode reviews changes made through Kiro's file-editing operations. Other actions, such as shell commands you've added to your trusted list, follow their own approval policy. Supervised mode does not restrict which files the agent can read, which commands it can suggest, or what network access it has.

To maintain full oversight of your environment:

• Keep your trusted commands list minimal and avoid broad wildcards.
• Use protected paths to require approval for writes to sensitive locations.
• Use workspace isolation and credential scoping as described in best practices.

In Autopilot mode, Kiro works autonomously:

• Kiro executes multiple steps without requiring approval for each one.
• Kiro makes decisions based on its understanding of your requirements.
• You can toggle autopilot on/off in the chat interface.
• Changes are written and applied immediately. You can review them after the fact.
• You can interrupt at any time and revert changes via Revert all changes or checkpoints.

In Supervised mode, Kiro works interactively, pausing for your review after each turn:

• After the agent modifies files, it pauses and presents a diff for your review.
• You can accept individual changes (hunk-level granularity) or reject them to revert.
• The agent asks clarifying questions when needed.
• To reduce interruptions, consecutive edits to the same file may be batched.

Supervised mode is best suited for situations where you want to closely review agent output. For example, when working in an unfamiliar codebase, making changes to critical paths, or onboarding a new team member to agent-assisted workflows.

Use Autopilot when you trust the task scope and want the agent to work efficiently without interruption. Use Supervised when you want to review each set of changes before they persist. In both cases, apply the security controls described in best practices to protect sensitive files, credentials, and infrastructure.

When operating in either mode, you can view individual or all file changes made by the agent by selecting View all changes in the Chat module. You can also select Revert all changes or revert to a checkpoint to restore your files to their previous state.

By default, Kiro requires approval before running any command. You can create your own trusted commands list by searching for Kiro Agent: Trusted Commands in your settings.

Kiro uses simple string prefix matching to determine if a command should be automatically trusted:

• Exact matching: Commands must match exactly (e.g., npm install)
• Wildcard matching: Use * to trust command variations (e.g., npm * trusts all npm commands)
• Universal trust: Use * alone to trust all commands (use with extreme caution)

The system treats entire commands as single strings and only checks if they start with trusted patterns. It does not analyze command structure, chains, or special characters, putting full responsibility on you to carefully configure trusted patterns.

Kiro requires explicit approval before writing to certain protected paths, preventing unintended modifications to sensitive workspace configuration files. This applies in both Autopilot and Supervised mode — when the agent attempts to create or modify a file matching a protected pattern, you see a confirmation prompt and the change is not applied until you approve it. If you decline, the agent skips the write and continues with the rest of the task.

The following path patterns are protected:

• Path contains — Matches if the pattern appears anywhere in the file path. For example, .vscode/ matches both .vscode/settings.json and .vscode/extensions.json.
• Exact basename — Matches if the filename (the last segment of the path) exactly equals the pattern. For example, mcp.json matches project/mcp.json but not mcp.json.bak.

When a match is detected, Kiro pauses and displays a confirmation prompt. The file is not written until you approve.

Kiro provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.

When using GitHub or Google authentication with Kiro, be aware that the Kiro agent operates within your local environment and may access:

• Local files and repositories
• Environment variables
• AWS credentials stored in your environment
• Other configuration files with sensitive information

1. Workspace Isolation
   • Keep sensitive projects in separate workspaces
   • Use .gitignore to prevent access to sensitive files
   • Consider using workspace trust features in your IDE
2. Use a Clean Environment
   • Consider creating a dedicated user account or container environment for Kiro
   • Limit access to only the repositories and resources needed for your current project
3. Manage AWS Credentials Carefully
   • Use temporary credentials with appropriate permissions
   • Consider using AWS named profiles to isolate Kiro's access
   • For sensitive work, remove AWS credentials from your environment when not needed
4. Repository Access Control
   • When using GitHub authentication, review which repositories Kiro can access
   • Use repository-specific access tokens when possible
   • Regularly audit access permissions

Kiro supports Open VSX extensions, including remote SSH extensions (the community-maintained Open Remote - SSH extension on Open VSX is a popular choice), to provide a familiar development experience. For comprehensive information about extension compatibility and support in Kiro, see our extension compatibility guide.

By following these practices, you can enjoy Kiro's capabilities while maintaining appropriate security boundaries for your development environment.