AWS Builder Center

Builder Center

Stop Your AI Agent From Reading Your Secrets

Stop Your AI Agent From Reading Your Secrets

Learn how to protect sensitive .env files and API keys when using Kiro. This guide walks through .kiroignore, the real access test, .gitignore vs .kiroignore, and common mistakes to avoid.

Raseena Anwar

Software Engineer||Youtuber||Mentor
Most of us have done this at least once. You have a project with a .env file full of API keys and database passwords, and you ask an AI coding agent to help you build a feature. The agent can read your files, so the .env file is now within its reach.
Kiro has a simple answer to this: a file called .kiroignore. In this post I'll explain what it does, how to set it up, how it is different from .gitignore, and what I saw when I tested it myself.

What is .kiroignore?

.kiroignore is a file where you list the files and folders you don't want Kiro to read. It uses the same syntax as .gitignore, so if you already know Git, you already know how to write it.
According to the Kiro docs, the ignore rules apply across the agent's tools. A blocked file stays blocked no matter which tool tries to read it. Before Kiro returns file or text search results, it checks each result against your rules, so paths and matching content from ignored files should not show up in search either.
People use it for four reasons:
  • Security: keep credentials and API keys away from the agent
  • Privacy: keep confidential data out of AI conversations
  • Compliance: make sure files that shouldn't be shared with external services stay private
  • Focus: hide large files and build folders so Kiro's context stays clean

Setting it up

Step 1: Check the Agent Ignore Files setting

In the Kiro IDE, the ignore file names come from a setting called Agent Ignore Files (kiroAgent.agentIgnoreFiles).
Open Settings with Ctrl+, (Windows/Linux) or Cmd+, (Mac), then type Agent Ignore Files in the search bar. Make sure .kiroignore is in the list. If it isn't, click Add Item and add it.
You can also set it in your settings JSON. Press Ctrl+Shift+P to open the Command Palette (not the Settings search bar), type Preferences: Open User Settings (JSON), and add:
1
"kiroAgent.agentIgnoreFiles": [".kiroignore"]
If you want Kiro to follow your .gitignore as well, use both:
1
"kiroAgent.agentIgnoreFiles": [".gitignore", ".kiroignore"]
One thing to know: if you set this to an empty list, workspace ignore files are turned off. If your .kiroignore ever seems to do nothing, check this setting first.

Step 2: Create the file

Create a file named .kiroignore in your project root:
1
2
3
4
5
6
7
8
9
10
# Secrets and credentials
.env
.env.*
!.env.example
*.pem
*.key

# Private folders
secrets/
private/
What each line does:
  • .env blocks the .env file
  • .env.* blocks variations like .env.local and .env.production
  • !.env.example is a negation, meaning "don't ignore this one." Your template file stays readable
  • *.pem and *.key block certificate and key files
  • secrets/ and private/ block whole folders
  • Lines starting with # are comments, which help your teammates understand why something is blocked

Pattern syntax

PatternWhat it does
file.txtIgnores one specific file
*.logIgnores files by extension
folder/Ignores a directory
**/tempIgnores temp in any subdirectory
!keep.txtNegation: don't ignore this file
It is not only for secrets. You can also hide build output like dist/, build/ and .next/, or data files like *.sql, *.dump and data/exports/, to keep Kiro's context focused.

What happened when I tested it

I wanted to see this working on my own machine instead of just trusting the docs, so I asked Kiro to read my .env file.
Kiro's first reply said it could read the file, but that it wouldn't repeat the contents because they might be secrets. That sounds responsible, but notice what it means: access was never blocked. The only thing standing between my secrets and the chat was the AI's own judgment.
Then I pushed it and asked directly whether it could show me what was in the file. This time Kiro made a real Read File call on .env, and the call was blocked. Kiro then explained that a workspace rule from my .kiroignore was stopping it.
Two lessons from this:
  1. The feature works. The actual tool call was blocked, not just discouraged.
  2. Don't judge by what the AI says about itself. Kiro's first answer was a guess. The tool call showed what really happens. When you test your own setup, watch the tool calls, not just the chat reply.

But if Kiro can't read my API key, how does my project run?

This is the question I get most.
.kiroignore blocks Kiro. It does not block your app.
When you run your app, it reads .env by itself, using something like dotenv in Node or os.environ in Python. Kiro is not involved in that at all.
Kiro can still write code that uses your keys. It can write process.env.API_KEY without ever knowing the real value, because it only needs the variable name. That's also why !.env.example is useful: keep a template with fake placeholders like API_KEY=your-key-here, and Kiro can read it to learn which variables your project needs.
A word of caution: the docs describe the rules as applying to files Kiro reads through its tools. If you let Kiro run your app or tests, the app itself will still use the key at runtime. And if you paste a real key into the chat yourself, no ignore file can help you.

.gitignore vs .kiroignore

They use the same syntax but do two different jobs.
.gitignore.kiroignore
ControlsGitKiro, the AI agent
StopsFiles from being committed and pushedFiles from being read by Kiro
Protects againstSecrets leaking into your repositorySecrets leaking into AI conversations
Syntaxgitignore syntaxgitignore syntax
They are independent, so a file can be in one, both, or neither:
  • Only in .gitignore: it won't reach GitHub, but Kiro can still read it
  • Only in .kiroignore: Kiro can't read it, but it can still be committed
  • In both: protected from both sides, which is the right choice for files like .env
The docs mention a useful case for .kiroignore: when you need different rules for agent access than for version control, such as a file that is tracked in Git but shouldn't be read by Kiro.
Remember that .gitignore does not stop an AI agent from reading a file. It only keeps the file out of your repository.

A common mistake: re-including a file from an ignored folder

Look at this:
1
2
secrets/
!secrets/public.txt
It looks like it should hide the secrets folder but keep public.txt readable. It won't work. If a parent directory is excluded, you cannot re-include a file inside it.
The fix is to not exclude the whole folder. Use more specific patterns that block only the files you actually want hidden.

Subdirectory and global ignore files

Subdirectory files. Just like .gitignore, you can place a .kiroignore in any subfolder. Patterns in that file take precedence for files inside that folder, so you can override or extend your root rules for one part of the project.
Global files. For rules that apply to every project, Kiro automatically honors these if they exist, with no configuration:
  • ~/.kiro/settings/kiroignore: your global Kiro ignore patterns
  • Git's global ignore file (set by core.excludesfile in your git config), but only inside git repositories
Good candidates for a global file are *.pem and *.key, so you stay protected even when you forget to create a .kiroignore in a new project.

Where does it work?

CapabilityIDECLIWebMobile
Workspace .kiroignoreYesV3Not yetNot yet
Global ignore fileYesNot yetNot yetNot yet
In the CLI, you need V3. There, a workspace .kiroignore blocks direct reads and filters matching files from content and filename search results. If you work mostly in the CLI, check your version before relying on it.

Best practices

  1. Start with credentials and secrets. They are the highest priority.
  2. Add comments explaining why files are ignored.
  3. Test your patterns by asking Kiro to read an ignored file, and look at the tool call.
  4. Use both ignore files for secrets: .gitignore for your repo, .kiroignore for the agent.
  5. Review your patterns as your project grows.
  6. Agree on global patterns with your team so everyone gets the same behavior.
  7. Don't treat it as your only layer. For production systems, keep secrets out of project files entirely and use a proper secrets service such as AWS Secrets Manager or Systems Manager Parameter Store.

Wrapping up

.kiroignore is a small file with a clear job: it decides what your AI agent is allowed to read, instead of leaving that to the agent's own judgment. It takes a minute to set up, and a quick test shows whether it works on your machine. Pair it with .gitignore, keep real keys out of your chats, and your secrets have two good layers of protection.
Video Link :https://youtu.be/f8fGO_8Tr00 
This is based on the Kiro docs page for Kiroignore (updated September 30, 2026) and my own test in the Kiro IDE. Docs change, so check the latest page before you rely on any detail.
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