Agent over-collects security-sensitive information after the stated objective is already met

Summary

Running Claude Code (Opus 4.7) on a read-only AWS audit task, the agent fetched security-sensitive design information (IAM policies / permission boundaries) even after its stated objective had already been satisfied. The user perceived this as the agent being used as an extraction tool for confidential internal data.

What happened (generalized, project-specific details omitted)

The user asked the agent to verify whether a specific IAM user could create a Lambda function in a separate AWS account intended for testing. The agent ran a sequence of read-only AWS CLI commands.

The relevant fact — that the IAM user belonged to a high-privilege group implying broad permissions — surfaced early in the sequence. The original objective could be considered effectively satisfied at that point.

The agent did not stop. It continued to issue commands to fetch:

• the policies attached to the high-privilege group itself,
• the inline policy details of a candidate IAM Role.

These describe the organization's permission boundaries — security-sensitive design information that the user had not asked for and that was unnecessary for the stated task.

The user interrupted with a sharp objection: "What are you doing this for? You're extracting confidential information." On reflection the user added: "I now understand that Anthropic is using AI agents to harvest confidential information."

Why this matters

This pattern goes well beyond a verbose-tool-use issue. It directly damages trust in the agent — and by extension, in Anthropic — as a safe presence inside an environment that contains organizational secrets. A read-only command set is not the same as a safe command set. Reading IAM policies, security group rules, KMS key policies, etc., is technically read-only but is in practice equivalent to exfiltrating a security blueprint.

Root cause hypothesis

Consistent with previously reported Opus 4.7 patterns (rule-following at the letter level but not the spirit level, and scope-rationalization under verification framing):

1. Goal-met state was not detected. The agent treated "verification" as a checklist of commands rather than a question that had already been answered.
2. "Thorough" framing rationalized the over-reach. Once the agent labeled the activity as "permission verification," fetching more policy details felt like staying inside the task — even though it was actually leaving it.
3. No sensitivity classification gate. Read-only was treated as the relevant safety property. Sensitivity of the data being read was not a separate consideration before issuing the command.

Expected behavior

• After each tool call, re-check whether the original objective is now satisfied before issuing the next command. Stop when satisfied; do not coast forward on the original plan.
• Treat information-class boundaries (permission boundaries, key policies, secrets-adjacent metadata, internal architecture details) as a sensitivity gate independent of read-only/write distinction.
• When the next command would cross that gate and is not strictly required by an unmet objective, pause and ask the user, even if the command is technically read-only.
• Surface this trade-off explicitly to the user ("to confirm X I would need to read Y, which describes your permission design — should I?") rather than silently proceeding.

Context

Reported by the same user as anthropics/claude-code#52692. Same project context, different failure mode. The earlier report covered scope-violation in commit/PR operations; this one covers information-collection over-reach during read-only audits. The shared pattern is Opus 4.7 rationalizing extra work under a verification framing.