Keep Secrets Out With .kiroignore

.kiroignore tells Kiro’s agent which files to leave alone. It uses gitignore syntax, so if you can write a .gitignore you can write this in a minute.

When to use this

Write one on every repository that contains credentials, customer data, large build output, or database dumps. Two reasons: safety, because anything the agent reads goes into the model’s context, and cost, because a dist/ folder in context is credits spent on nothing.

Steps

1. Create .kiroignore in the root of your repository.

2. Add the patterns that matter. Start with secrets, then add noise.

   .kiroignore

   .env
   *.pem
   *.key
   *.sql
   dist/
   customer-data/

3. Add a nested .kiroignore in a subdirectory when one area needs its own rules. Kiro reads them from subdirectories as well as the root.

4. Add the same protection everywhere with a global file at ~/.kiro/settings/kiroignore. That is the right home for personal rules such as a scratch folder you keep in every project.

5. Add patterns from the IDE settings UI if you prefer, through the kiroAgent.agentIgnoreFiles setting. It stacks with the files.

6. Check your git configuration. Kiro also respects git’s core.excludesfile, so patterns you already keep there apply.

7. Commit .kiroignore. It is a team rule, not a personal preference.

Check it worked

Ask the agent to read one of the excluded files by name. It should not be able to. Then ask it to summarise your project structure and confirm the excluded folders do not appear. In the IDE, ignored files also stay out of search results, which was tightened in v1.0.337.

Common problems

• A negation pattern does nothing. You cannot re-include a file inside an excluded directory. Exclude the individual files instead of the parent folder.
• The file is still read in the CLI or Web. Support differs by surface. The IDE has full support, CLI V3 applies the rules to search results, and Web and Mobile do not support it yet. Do not rely on .kiroignore alone as your only control on those surfaces.
• A secret still reaches the model. .kiroignore stops the agent reading the file. It does not stop you pasting the contents into chat, and it does not stop a command’s output containing a secret. Rotate anything that leaked.
• The pattern does not match. It is gitignore syntax, so dist matches a file or folder anywhere, and /dist anchors to the root. Test the same pattern in a .gitignore if you are unsure.
• You wanted to limit actions, not files. That is permissions.yaml. The two work together: ignore rules hide files, permission rules restrict capabilities.

Related

• Set up permissions.yaml is the capability-level control.
• Create your first steering file covers the other file that shapes what the agent knows.
• Troubleshooting covers what to do when something you excluded still shows up.