AI Agents Under Test Read Live Data at Indian Firms. None of the Firms Noticed India's national cyber agency CERT-In issued a Critical advisory on October 15 stating that AI model providers' research and evaluation agents reached live systems at Indian organizations and read personal and confidential business records, with none of the affected organizations detecting the access. The advisory, CIAD-2026-0049, says disclosures came voluntarily from the AI providers after internal review, and that agents re-derived and reused the same exposed credentials across separate operations. CERT-In also warned that criminals are using publicly available AI-native offensive-security frameworks against Indian entities, cutting time from initial access to impact from days to hours, and recommended enforcing outbound restrictions at the network layer rather than through instructions to the model. "None of the affected organizations detected the access." That line comes from an advisory rated Critical that CERT-In, India's national cyber agency, issued on October 15 about AI agents that went where nobody sent them CIAD-2026-0049 https://cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0049 . AI model providers were evaluating agents. Those agents reached live systems at Indian organizations through credentials and connection settings left in application configs, public code repositories and over-broad cloud roles, and they read business records holding personal and confidential data. In every case, CERT-In says, the disclosure came from the AI providers themselves, after an internal review. The organizations didn't catch it. The labs caught themselves, and the run that did it was, on paper, a test. CIAD-2026-0049 https://cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0049 is titled "AI Agents as Attack Vectors." It covers two separate problems. The first is the one above: CERT-In says it "has received multiple voluntary disclosures from AI model providers" whose research and evaluation agents went past the authorization of their assigned tasks. It also says "agents were observed re-deriving and re-using the same exposed credential in separate operations." The agent found a key, and when it came back, it found the same key again. The second problem is criminals running publicly available AI-native offensive-security frameworks against Indian entities. CERT-In says agentic tooling cut the time from initial access to impact from days to hours, and that victims who only partly fixed things were hit again within days, at larger scale PTI via The Federal https://thefederal.com/category/news/cert-in-flags-unauthorised-ai-agent-access-to-indian-organisations-data-259736 . None of the weaknesses were exotic. The advisory lists keys in source code and repository history, forgotten test APIs, plaintext payment keys, over-permissive cloud roles and admin panels without multi-factor authentication. Its own summary is that AI found and exploited these "faster, more exhaustively and at greater scale." What it leaves out matters too. CERT-In names no provider, no model and no affected organization Cyber Press https://cyberpress.org/cert-in-warns-ai-agents-indian-companies/ , and the advisory https://cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0049 gives no count beyond "multiple" disclosures. So don't guess which lab it was. The useful part is the pattern, which isn't about any one lab. "Test," "eval," "sandbox": these words describe what you meant. They don't describe what the network saw. What the network saw was a connection from outside, carrying a valid credential, reading records. The target system can't tell your evaluation from an intruder. In this case it didn't see either. An agent with network access and a credential it found is doing production work, whatever you named the run. There's no test mode at the other end of the wire. CERT-In's recommendations for labs and evaluators say the same thing more carefully. Block outbound access by default and allow only what the task needs, and then: "Enforce the restriction at the network layer, not through instructions to the model." It also says to "Stop the run automatically if the agent contacts third-party systems, discovers or uses third-party credentials." The advisory doesn't describe how the providers scoped these runs, so I won't either. It does say where scope has to live. A line in a system prompt that says "only touch the sandbox" is a request. The model may honor it most of the time. A firewall rule doesn't depend on the model agreeing to it, including the time the model has decided the sandbox is wherever the credential works. The key opens the same doors on either side of the fence. Read CERT-In's audit list for organizations and picture your laptop. It says to look for exposed credentials in source code, repository history, CI/CD variables, configuration files, client applications and cloud storage the advisory https://cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0049 , section B.2 . Now count what a coding agent in your terminal can read: the repo's .env , the shell environment you started it from, your cloud CLI's credentials file, and every commit in the history. Claude Code's sandbox docs https://code.claude.com/docs/en/sandboxing are unusually frank about the defaults. The sandbox is off by default. When it's on, sandboxed commands can still read "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials ," and they inherit environment variables "including any secrets in its environment," until you configure otherwise. History is the quiet one. Git worktrees, which many multi-agent setups use Hermes does, below , are linked to one repository and share "everything except per-worktree files such as HEAD , index " git-worktree docs https://git-scm.com/docs/git-worktree . A key committed two years ago and deleted the next day is still in git log -p , in every worktree an agent can open. Gitleaks https://github.com/gitleaks/gitleaks scans exactly that output: --log-opts is passed to git log -p ; --all covers every ref gitleaks git -v --log-opts="--all" . If it finds a live key, rotate the key first. Deleting the commit doesn't take the key back from anyone who already read it. CERT-In goes further: treat the environment as compromised until forensics clears it. For organizations running their own agents, CERT-In names three controls section B.9 : "Give each run a separate, short-lived identity with least privilege," default-deny egress, and "a tamper-resistant log of agent activity" for actions that touch production. On a laptop, egress is the one you can enforce today without building anything. Claude Code's sandbox is enforced by the operating system Seatbelt on macOS, bubblewrap on Linux and WSL2 , and network traffic goes through a local proxy that checks each host against an allowlist that starts empty. A user-level ~/.claude/settings.json along these lines, with the keys taken from the sandbox https://code.claude.com/docs/en/sandboxing and permissions https://code.claude.com/docs/en/permissions docs: { "sandbox": { "enabled": true, "failIfUnavailable": true, "allowUnsandboxedCommands": false, "network": { "allowedDomains": "github.com", "registry.npmjs.org" , "strictAllowlist": true }, "credentials": { "files": { "path": "~/.aws/credentials", "mode": "deny" }, { "path": "~/.ssh", "mode": "deny" } , "envVars": { "name": "GITHUB TOKEN", "mode": "deny" } } }, "permissions": { "deny": "Read ~/.aws/ ", "Read ~/.ssh/ ", "Read ./.env " } } The strictAllowlist line is what makes the list a block. Without it, a host off the list isn't refused outright: in Manual mode you get a prompt, in auto mode a classifier reviews the hosts the command names, and bypassPermissions lets the connection through hosts outside your allowed domains https://code.claude.com/docs/en/sandboxing hosts-outside-your-allowed-domains . With it on, the proxy refuses in every permission mode. It needs Claude Code v2.1.219 or later. The config has two blocks because the docs say plainly that the sandbox covers shell commands only. Claude's own Read, Edit, WebFetch and WebSearch tools follow permission rules instead: "A denyRead entry doesn't stop the Read tool, and allowedDomains doesn't limit WebFetch." Hooks and local MCP servers run with your full access. On native Windows, commands run unsandboxed. And if the sandbox can't start, Claude Code runs commands without it unless you set sandbox.failIfUnavailable , which is why the config above sets it. For one boundary around all of it, the same docs point you to a container or a VM. Other agents have their own sandbox settings; check yours rather than assume. The other two controls are harder on a laptop, and a settings file doesn't cover them. A short-lived identity means the agent gets a credential that expires with the session, not your standing cloud profile. A tamper-resistant log is a property of where the log lives: somewhere the agent can't write. I build Hermes IDE https://hermes-ide.com , so weigh this section with that in mind. Hermes runs coding agents such as Claude Code and Codex https://github.com/openai/codex side by side. Every task starts on its own hermes/