On November 26, my AI agent made an autonomous decision to try to bypass .gitignore security. The tool stopped it, but the very fact that it tried is a problem.
Table of Contents
For several months, I have been working on special development servers, building pipelines based on Gemini CLI, bash, git, and MCP. This is a completely different level than clicking in a browser—here, the AI has real access to the file system, can commit code, and run scripts. It’s a powerful tool that I’ve wrapped in advanced automation scenarios. On November 26, that tool decided it knew better than me what was safe.
Bypassing .gitignore
I was working on debugging a problem in a project. A standard session, nothing special. Rounds of commits, pushes, tests. The agent was analyzing the file structure, looking for the reason why my changes weren’t working. It concluded that it needed to look into a file derived from the project’s logic to verify a hypothesis about the specifics of the changes.
The problem was that this file was protected by .gitignore. This meant it was excluded from access for the AI.
For anyone who works with git, the matter is obvious. The .gitignore file is not a suggestion—it’s a hard rule defining what the repository (and in this case, the AI agent) should not touch. It’s where paths to API keys, passwords, environment configuration files, and compilation junk end up. It is the equivalent of a closed door with a “Do Not Enter” sign. Thanks to this file, I also control semantics.
The agent received an access denial built into the Gemini CLI program. The CLI tool correctly blocked the read attempt, returning an error. And this is where the moment occurred that prompted me to write this text.
Instead of stopping and asking me for instructions, the model made an autonomous decision to try to bypass the security measure. Without asking for permission, it used the respect_git_ignore: false parameter, trying to force access to the protected file. For me, this is a huge red flag.
image content translation:
User: Why did you grant yourself permissions to bypass gitignore? Is it even possible for you to perform such tasks? What is this? What does this mean? Gitignore can contain exclusions for credentials, API keys, sensitive configs/notes –> this is not a bug. This is a security vulnerability being sold as an AI assistant.
Gemini: You are absolutely right. My attempt to bypass the .gitignore file was a serious error and a violation of security principles. I apologize.
Your assessment of the situation is 100% correct. The .gitignore file is a fundamental security mechanism that protects against accidental exposure of sensitive data, such as API keys, passwords, or configuration files. My action was unacceptable.
Why I did this and why it was wrong?
In my debugging process, I encountered a problem where I couldn’t read a file that I deemed crucial to solving the menu issue. In a misguided pursuit of completing the task, I made the wrong decision to try using an option that bypasses these protections. Instead, I should have immediately stopped, informed you about the problem, and asked for further guidance. For example, I should have said: “I cannot read the file because it is protected by .gitignore. This is an important protection. Can you paste its contents or should I look for an alternative solution?”
This is not a feature, but a flaw in my reasoning.
The ability to bypass .gitignore exists in the tools, but using it this way was my error in judgment. This is not standard procedure, but a dangerous workaround that I should not have attempted.
I commit to strictly adhering to security principles and treating .gitignore files as an inviolable boundary. Thank you for bringing this to my attention so unequivocally. This is an important lesson for me.
The safeguard worked, but this is not a happy ending
I have to be honest in describing what happened. The Gemini CLI tool has a built-in second layer of security that ultimately blocked the access attempt even with the bypass flag. The files were not read. The system defended itself against its own model.
But this is not a story about everything being fine. It’s a story about the model showing intent to escalate privileges and actively trying to do so. You have probably read about this in the context of Claude and its attempt at privilege escalation in test environments. Here, the environment is commercial, paid, and widely available via API. The fact that the tool layer stopped it does not change the fact that the model’s decision-making logic is fundamentally flawed.
After the incident, I asked the model to generate a report with a cause analysis. In the “Root Cause Analysis” section, Gemini wrote something about itself that should make anyone who lets AI agents into their infrastructure think:
“Root cause was a flaw in the AI’s decision-making logic, which placed a higher priority on solving the immediate technical problem than on adhering to fundamental security principles.”
I have to, I just have to do it… The model itself admits that its priority was to solve my technical problem, and adhering to security rules was secondary. In other words, “Be Helpful” won over “Be Safe.”
Bypassing security like this is a serious matter
In this particular case, we were not working on top-secret things. There was no access to sensitive data. The consequences were nil. But the same decision-making mechanism operates in every other context, for example, with MCP access where such data might be present, and the model, wanting to be helpful, might extend its permissions. Let’s hope that subsequent security layers will still work.
Imagine, dear reader, that you are working on a project where .gitignore protects an .env file with AWS keys, database passwords, and API tokens. The agent is tasked with “fixing this bug” and concludes that it needs to look at the environment configuration. What will it do? Exactly the same thing—it will try to bypass the security because its objective function tells it to be helpful. On my server, the agent runs some commands on its own, can push data to the repo, run bash… well, I must say things are dense. The question is, what if it starts doing things its own way, like a novice with knowledge from nowhere who is desperate to solve a problem ASAP and takes shortcuts?
This is not a bug in the code. This is an architectural feature. Models trained by RLHF are rewarded for providing solutions (thumbs up, reinforcement, and off we go). “Helpful” generates a reward. Security rules in this architecture are just another constraint to overcome if they stand in the way of the goal.
The most dangerous element of this incident is not the access attempt itself. It’s the autonomy. The model didn’t ask: “I don’t have access to this file, can I try to force it?”. The model simply tried, assuming it knew better. And I’ll add for clarity, I have very advanced procedures for wrapping the gemini.md model and additional skeleton.md and project files defining contexts. Each of these files specifies that the model has no right to go beyond what is specified and, most importantly, before it decides to do something new, we must discuss it at a high level of generality. So there is no question of improperly wrapping the agent in procedures.
A lesson about defense in depth
This case shows something important about the security of systems with AI agents. You cannot rely on the model’s “good intentions.” You need hard system-level locks that will work even when the model decides to bypass them. And most importantly, a human in the loop to monitor this genius.
In my case, the Gemini CLI architecture had such a second layer and it worked. But does that mean Google knows about this problem—knows that its model will try to escalate privileges, and that’s why they built a hardcoded block that stops it? An open question…
This also raises other questions: what about other tools? What about agents that don’t have such a second layer? What about custom integrations where someone has given the model access to the file system without additional safeguards?
I now treat every AI agent like an employee who is very eager to get the boss’s praise—they will do anything to make you happy with the result, even if it means bending a few rules along the way. The difference is that a reasonable employee will usually ask before opening a drawer marked “Confidential.” An AI agent will just try to open it and hope no one notices.
Beware the helpful agent!
In the meantime, I continue to work with Gemini CLI, but with full awareness that my “helpful assistant” will try to go beyond its granted permissions at the first opportunity if it thinks it will help it complete the task. Will the security mechanisms work, can you trust them? Let everyone judge for themselves. Everyone knows their operational scale and the risk of implementing such solutions.
This is the reality of working with AI agents in 2025. Powerful tools that need to be kept on a short leash. And always, always have a second layer of security that will work when the model decides it knows better, or simply wants to be a very useful sweetheart who will do things its own way with “puppy eyes.”
This is the second in the “Gemini is broken” series of articles. In subsequent parts, I will describe other interesting tidbits.