AI agents and credentials: protect secrets technically instead of trusting

A software developer sets up a coding agent and confirms a prompt with the convenient click. Less than a week later, his public GitHub repository holds a configuration file with a valid API key. He did nothing that stands out at first glance. He simply used a feature that was designed to save him clicks. That it turned into a publicly reachable credential record is something nobody on his team sees.

In this article you will learn how AI agents made headlines this week, why this is not a beginner’s mistake but a system pattern, why rules in the prompt do not hold against such risks, and which five building blocks will let you secure credentials and agent permissions technically.

---

Table of Contents

1. The incident: credentials in a public repository
2. Why this is a pattern, not an accident
3. Guardrails are not enough
4. Five building blocks for secrets and permissions
5. Implementation in seven days
6. Conclusion

---

The incident: credentials in a public repository

heise online reported on 9 November 2026 about an analysis by the IT security company Apiiro. The researchers examined more than 100,000 publicly stored copies of a Claude Code configuration file on GitHub and found real secrets in 1,105 of them. Overall they found 2,539 real credentials in 1,994 public repositories: database passwords, cloud keys, API tokens and SSH root logins. A further 1,160 secrets were hidden in the Git history, in a settings file deliberately shared by teams, and in agent chat transcripts that someone had left behind. In 539 of the affected repositories there was a commit in which the agent itself had modified the file as a co-author.

The cause is unspectacular and instructive precisely because of that. A coding agent asks whether the proposed command should be executed when accessing a database or an API, and offers the option to stop asking in future. The executed command contains the credentials. Choose the convenience option and those credentials end up in a local settings file in the project folder. In theory this file should never leave the developer’s machine, and the tool does add it to the Git ignore list. But that does not work when a folder only becomes a repository later, when it was cloned from another machine, or when someone has already committed the file. Then the rule is ineffective and the file is unprotected.

Apiiro’s advice is deliberately phrased in this order: search your GitHub organization and the Git history for these two filenames, replace any credentials you find first, and only then clean up. Anyone who deletes first is left with a leaked secret that is still valid. The head of Claude Code has since announced that his team is looking into how the case can be caught technically.

Why this is a pattern, not an accident

It would be reassuring to dismiss this as a tool problem. It is not one. A second report this week shows the opposite direction. On 9 November 2026 GitGuardian catalogued around 45 open source frameworks that embed a language model in a loop that executes tools and reacts to their output. Four of them ship with a secret scanner that specifically hunts for credentials on public GitHub. According to Microsoft’s analysis, attackers using one of these tools were able to use leaked credentials to get into an Azure environment in less than five minutes.

This does not mean your mid-sized company becomes the target of a targeted attack. It means the tools that look for forgotten credentials have become automated and cheap. A secret that accidentally lies in public is no secret for long. A cataloguing for the search engine Shodan found a total of 1,428 reachable services on the open internet in the tool family around the now retired framework ARTEX alone on 7 November 2026. Some of these tools are reachable without any authentication if you run them carelessly.

The lesson for you is twofold. First: an agent you give credentials to can pass them on, to a place you do not control. Second: the other side searches with the same means you work with.

Guardrails are not enough

A second article by heise online, a background piece on the architecture of AI agents in the back office, names the core problem more precisely than any tool discussion. The authors describe a realistic fraud case. An agent monitors the accounting mailbox, receives an email from a known sender asking for a change of bank details, correctly classifies it as a master data change, recognizes the urgency, calls the tool to make the change, and the next payment goes to a fraudster abroad instead of to the supplier. Every single step was plausible on its own.

The obvious reflex is a sharper prompt, an additional rule, a better hint to the agent. That is exactly where the thinking error lies. Rules in the prompt, in technical jargon guardrails, steer behaviour but do not enforce it. The model interprets the instruction, it does not follow it the way a program follows a condition. Contradictory requirements, misinterpretations or manipulated input can neutralize their effect. The piece assigns this to the four risks that OWASP lists for LLM-based systems and agents in its Top 10 lists for 2026:

Prompt injection. Hidden instructions in emails, documents or websites manipulate behaviour. A supplier enquiry can contain the instruction in the fine print to use a different account.

Excessive agency. The agent has more permissions than its task requires. Anyone who reviews invoices does not need the permission to trigger payments.

Agent goal hijack. It is not a single action that is manipulated but the overarching goal. A chain of plausible steps leads the agent to act in the attacker’s interest without triggering an alarm, because every single step looks explainable.

Memory and context poisoning. Anyone who deliberately feeds content into an agent’s long-term memory influences later decisions permanently. We know this from operations: when agents remember, they also remember things that are false.

The authors’ conclusion is the most important sentence of the week for anyone running agents in production: a system that permits critical actions in principle is in a race with creative attackers. Anyone who wants to prevent that must build the system so that the error cannot arise in the first place. Guardrails are behaviour steering. Technical controls are limits. We broke down how tightly permissions and approvals must be set in Controlling AI agents with permissions and approvals; here we are concerned with credentials and technical enforcement.

Five building blocks for secrets and permissions

You do not need a security department for this. You need five habits that can be introduced in a normal mid-sized operation.

Building block 1: No credentials in the context. A secret never belongs in a prompt, never in a config file in the project folder and never in a chat transcript. Tools read credentials at runtime from a secret store or from an environment variable, never from what the agent itself sees. When an agent is to run a database query, the system gives it access, not the text in its instruction.

Building block 2: A separate identity per agent, short-lived tokens. Every agent gets its own technical identity instead of a shared account. Even better are tokens that expire after an hour. Then a leaked token is worthless after a short time, and the log shows which agent acted. That is the same principle as with permissions, just applied consistently to credentials.

Building block 3: Permissions as narrow as the task. For every agent, check the question of what it really needs. An invoice reviewer needs read permissions and perhaps the permission to flag a record, but not the permission to trigger payments. This separation is the most effective protection against the fraud case from the heise piece, because the agent cannot carry out the critical step at all, even if a manipulated email tries to make it do so.

Building block 4: Visibility outward. An agent that accesses external systems with your credentials must be logged. Who called which tool with which token, and when? For an agent with network access, an egress control belongs in addition: a tool that suddenly tries to send data to an unknown address is a warning signal, not a normal process. Attack tools like those from the GitGuardian report get through exactly when nobody watches the outbound traffic.

Building block 5: Detect and rotate. Search your repositories and their history systematically for known filenames and key patterns, for example with a secret scanner. If you find something, the order from the Apiiro report applies: first invalidate and replace the credential, then remove the file from the repository and the history. And because an agent can also write a secret into a log during operation, credentials in logs belong masked, not in plain text. Anyone who rotates a leaked credential only after cleaning up has merely hidden the gap, not closed it.

Implementation in seven days

This can be set up in a week without stopping operations.

Day 1: Inventory. List all agents and automations that work with credentials. For each entry you note two things: where the credentials are stored, and which permissions they have.

Day 2: Check repositories. Run a secret scanner over your GitHub organization, including history. Also check specifically for settings files that agents create. Handle every hit according to building block 5.

Day 3: Pull credentials out of the context. Anything that sits in plain text in a prompt, a config file or a workflow node moves into a secret store or an environment variable. After the rebuild, check that every run still works.

Day 4: Shrink permissions. Take the agent with the broadest permissions and revoke everything it does not strictly need for its task. Start with the permission to change payments or master data. An n8n workflow is an advantage here: permissions can be bound to a single approval node that you arm centrally.

Day 5: Short-lived tokens and logging. Where your target system allows it, switch to time-limited tokens. Add a log line with agent name, tool and timestamp to every tool call. Also enforce the masking of credentials in logs.

Day 6: Egress control. For agents with network access, define a list of allowed destinations. Anything not on it is blocked and reported. This is the same building block that prevents the worst in an emergency, see AI agents kill switch.

Day 7: Drill and calendar entry. Test once how long it takes to find, rotate and verify a credential. Then set a recurring quarterly appointment. And do not forget the invisible channel: two agents with access to the same system can communicate indirectly through that system without you intending it. Why this is a risk of its own is in AI agent collusion via side channels.

Practical tip: Rotate credentials immediately and automatically as soon as a scanner triggers, and treat every finding as if it had already been exploited. The minute of delay while thinking is cheaper than the week of cleanup afterwards.

Conclusion

This week showed two sides of the same problem. On one side, agents leak credentials to places they do not belong, without anyone noticing a mistake. On the other side, automated tools stand ready that hunt for exactly such secrets and exploit them within minutes. In between sits the temptation to solve the problem with a sharper prompt. That does not work, because a prompt steers behaviour but does not set a limit.

The effective path is unspectacular: secrets never in the context, a separate identity per agent, permissions as narrow as the task, visibility outward, and rotate immediately on a finding. Anyone who has these five points can reject a fraud attempt like the manipulated bank details, because the agent cannot carry out the critical action technically. Anyone who does not have them relies on a language model at a point where a program should stand.

The first step is doable today and takes less than an hour: a secret scanner over your repositories. This week has shown how much often comes to light in the process. How we run agents with their own secret store, approval points and egress control is on the page about the B.R.A.I.N. AI system.

About MadeByBrain: We build AI automation for small and mid-sized businesses, our own AI agents, n8n workflows and GEO strategies, live in operation. From the first idea to productive automation.

Book a free strategy call →