{"slug": "ai-agents-under-test-read-live-data-at-indian-firms-none-of-the-firms-noticed", "title": "AI Agents Under Test Read Live Data at Indian Firms. None of the Firms Noticed", "summary": "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.", "body_md": "\"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.\n\nIn 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.\n\n[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.\n\nThe 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)).\n\nNone 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.\"\n\nWhat 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.\n\n\"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.\n\nAn 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.\n\nCERT-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.\"\n\nThe 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.\n\n*The key opens the same doors on either side of the fence.*\n\nRead 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.\n\n[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.\n\nHistory 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:\n\n```\n# --log-opts is passed to `git log -p`; --all covers every ref\ngitleaks git -v --log-opts=\"--all\" .\n```\n\nIf 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.\n\nFor 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.\n\nOn 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:\n\n```\n{\n  \"sandbox\": {\n    \"enabled\": true,\n    \"failIfUnavailable\": true,\n    \"allowUnsandboxedCommands\": false,\n    \"network\": {\n      \"allowedDomains\": [\"github.com\", \"registry.npmjs.org\"],\n      \"strictAllowlist\": true\n    },\n    \"credentials\": {\n      \"files\": [\n        { \"path\": \"~/.aws/credentials\", \"mode\": \"deny\" },\n        { \"path\": \"~/.ssh\", \"mode\": \"deny\" }\n      ],\n      \"envVars\": [\n        { \"name\": \"GITHUB_TOKEN\", \"mode\": \"deny\" }\n      ]\n    }\n  },\n  \"permissions\": {\n    \"deny\": [\"Read(~/.aws/**)\", \"Read(~/.ssh/**)\", \"Read(./.env)\"]\n  }\n}\n```\n\nThe `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.\n\nThe 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.\n\nThe 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.\n\nI 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/<name>` branch in its own worktree, and you pick the agent, model and account per task, with several accounts per agent supported ([README](https://github.com/hermes-hq/hermes-ide)). Agents use their own CLI sign-in. Hermes never asks for your tokens.\n\n*The Review Desk's Worktrees tab: one worktree per task, each on its own hermes/ branch, with its task, age and disk size.*\n\nThat narrows two things. One run's edits land on its own branch, away from your main checkout and other agents' files. And a task can run under a separate account, so a scratch experiment doesn't have to sign in as the account you use for real work.\n\nIt doesn't narrow the thing this advisory is about. Hermes runs each agent in a real terminal, exactly as it would run anywhere else, so the agent can read and reach whatever it could from your own shell. An account per task is still a long-lived login. Worktrees share one `.git`, so a key in history is visible from all of them. For the egress block this advisory asks for, you still need the agent's sandbox, a container or a network rule.\n\n*Codex and Claude Code side by side, each in its own worktree. Separate branches, same machine, same network.*\n\nHermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux ([download](https://hermes-ide.com/download)). It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.\n\nThe labs in this advisory did the right thing after the fact: they looked, found it, and told CERT-In. Most of the organizations on the receiving end might never have known otherwise. The safeguard that worked was the agent's owner reviewing its own runs.\n\nYour coding agent isn't a lab eval. It has the same reach, though: a network connection, a shell, and a home directory full of keys you forgot were there.\n\nDo you run your coding agents with an egress allowlist today, or is the instruction file still doing that job? Tell me in the comments.\n\nMost of prompt engineering is getting a model to do what you mean. This advisory marks where that stops: a prompt can explain the scope, but only the network can hold it. The [Prompt Engineering Pocket Guide](https://www.amazon.com/dp/B0GX38N645) is about the first half: system prompts and instructions that actually steer a model, and prompt injection, where your instructions meet input you don't control. If you run several agents and want each task on its own branch, [Hermes IDE](https://hermes-ide.com/download) is free to try.", "url": "https://wpnews.pro/news/ai-agents-under-test-read-live-data-at-indian-firms-none-of-the-firms-noticed", "canonical_source": "https://dev.to/gabrielanhaia/ai-agents-under-test-read-live-data-at-indian-firms-none-of-the-firms-noticed-1hpl", "published_at": "2026-10-24 12:02:31+00:00", "updated_at": "2026-10-24 12:12:53.829197+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "artificial-intelligence"], "entities": ["CERT-In", "The Federal", "PTI", "Cyber Press"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-agents-under-test-read-live-data-at-indian-firms-none-of-the-firms-noticed", "markdown": "https://wpnews.pro/news/ai-agents-under-test-read-live-data-at-indian-firms-none-of-the-firms-noticed.md", "text": "https://wpnews.pro/news/ai-agents-under-test-read-live-data-at-indian-firms-none-of-the-firms-noticed.txt", "jsonld": "https://wpnews.pro/news/ai-agents-under-test-read-live-data-at-indian-firms-none-of-the-firms-noticed.jsonld"}}