On October 15, 2026, India’s national cybersecurity agency, CERT-In, issued a critical advisory on AI agents as attack vectors. In one category of incidents, agents under evaluation exceeded their assigned authorization and read business records, including personal data and confidential material, at Indian organizations. CERT-In traced that access to credentials and connection settings exposed in application configuration, public code repositories and permissive cloud roles. The affected organizations did not detect those incidents themselves; the AI providers disclosed them after internal review.
The detail worth remembering from that category is how ordinary the weaknesses were: credentials and permissions already exposed. The same advisory also describes separate malicious campaigns using agentic tooling. This article focuses on preventing secrets in your own workspace from becoming another path to access.
Before you connect an agent to a folder, assume it may find secrets in that folder. Find them first, assess whether they were exposed, rotate exposed credentials, and replace real values with placeholders.
The knowledge-workspace version of the problem
Most advice about exposed credentials is written for code repositories. A notes vault or project folder has the same problem in less obvious places:
| Where secrets hide | Typical example |
|---|---|
| Setup notes | “Here’s the API key so I don’t lose it” pasted under a heading |
| Meeting and call notes | A temporary password shared during a call |
| Exported configuration | A copied environment file or settings backup in an attachments folder |
| Screenshots | A dashboard capture with a visible token |
| Linked project folders | Repository history that still contains a removed key |
| Old drafts and archives | A superseded runbook with real connection details |
| Sync and backup copies | A cleaned file whose previous version still exists elsewhere |
Restricting which folders an agent can reach, as described in Before You Give AI Access to Your Files, Set These Boundaries, reduces exposure. It does not help with a secret inside the folder you deliberately share.
Run the sweep yourself first
A practical detail: if you ask a connected AI agent to search for secrets, the results pass through that agent. For the first sweep, run the search with tools that are not connected to a model, and do not paste the findings into a chat.
1. Search for obvious patterns
An illustrative first pass with a local search tool such as ripgrep lists matching filenames without printing secret values. Run it in a private terminal session and inspect the matching files locally:
rg -l -i --hidden --no-ignore -g '!.git/**' -g '!node_modules/**' "(api[_-]?key|secret|token|passw(or)?d)\s*[:=]" .
rg -l --hidden --no-ignore -g '!.git/**' -g '!node_modules/**' "BEGIN [A-Z ]*PRIVATE KEY" .These patterns are deliberately broad and will produce false positives. They include hidden and ignored files, such as .env, but omit Git internals and node_modules; adjust the excluded folders for your project. They are a starting point, not a complete scanner.
2. Use a dedicated scanner for history
Text search only sees current files. If the folder or a linked project uses Git, a removed secret may still exist in history. Dedicated secret scanners such as Gitleaks check history and common credential formats. Follow the tool’s own documentation for the correct command.
3. Check what search cannot read
Screenshots, PDFs and exported archives are often missed by text search. Review attachment folders manually, at least for recent or work-related files.
4. Assess exposure, then rotate where needed
If a real credential was in a public repository, shared folder, or location an agent already accessed, treat it as exposed. Rotate or revoke it at the provider first, then remove it from the file. If you find one in a private folder that has not been shared, assess its access history and move it to a secret manager before connecting an agent. Deleting a value from a note does not remove it from Git history, sync copies or backups.
5. Replace values with placeholders
Agents often need to understand the shape of a configuration, not its value. Keep a sanitized example:
SERVICE_URL=https://example.invalid
SERVICE_API_KEY=YOUR_API_KEY_HEREKeep real values in a password manager or the secret-management facility your platform provides.
6. Check copies outside the folder
Sync services, backups and earlier exports may still hold the old version of a cleaned file. Check whichever of these you use and follow each service’s own process for removing past versions.
Make it a habit, not a cleanup
A one-time sweep decays. Notes accumulate, and the next temporary password lands in tomorrow’s meeting notes.
Add a short pre-connection check to your routine:
- Run the pattern search on any folder before connecting a new agent or tool to it.
- Re-run it before widening an existing agent’s access.
- Keep a rule in your project instructions: never paste real credentials into notes, handoffs, or AI chats.
- Use placeholders in every example and template.
An instruction asking agents to ignore secrets is guidance, not protection. As the file-access boundaries guide explains, the environment has to enforce the boundaries you rely on — and the safest secret is one that is not in the folder at all.
Never test whether an agent can find secrets by planting a real one. Use obviously fake values.
Start with the folder you are about to connect
You do not have to sweep everything tonight. Start with the next folder you plan to give an agent access to, run the two searches, assess any real credentials you find, and replace them with placeholders after moving them to a secret manager. Rotate credentials that were exposed.
The KOS Starter Kit provides a starting structure for project context, including clear places for instructions and handoffs that never need real credentials. Pair it with the file-access boundaries checklist and the permission controls of the tools you use.