AI 智能體測試期間讀取印度企業即時資料，相關企業均未察覺

• Book: Prompt Engineering Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

"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). 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.

What the advisory says, and what it leaves out

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).

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), and the advisory 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.

A test run with a real key is a production run

"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.

Your coding agent can read the same keys

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, 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 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). 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 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.

Put the block below the model

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 and 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). 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.

Where Hermes helps, and where it stops

I build Hermes IDE, so weigh this section with that in mind. Hermes runs coding agents such as Claude Code and 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). Agents use their own CLI sign-in. Hermes never asks for your tokens.

The Review Desk's Worktrees tab: one worktree per task, each on its own hermes/ branch, with its task, age and disk size.

That 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.

It 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.

Codex and Claude Code side by side, each in its own worktree. Separate branches, same machine, same network.

Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux (download). It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.

Call the run what it is

The 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.

Your 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.

Do you run your coding agents with an egress allowlist today, or is the instruction file still doing that job? Tell me in the comments.

If this was useful

Most 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 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 is free to try.