Skip to main content
Back to blog
AWS credentials exposed

Cursor .env leak

November 2025. AWS credentials exposed.

An AI agent in Cursor was asked to “check the database configuration.” It read the project’s .env file, which contained AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and DATABASE_URL with embedded credentials. The secrets were included in the agent’s response and visible in the conversation history.

What happened

  1. A developer asked their AI agent to debug a database connection issue.
  2. The agent read .env to understand the configuration.
  3. The file contained AWS credentials, a database connection string with password and API keys for third-party services.
  4. The agent included the credentials in its response context. The secrets were now in the conversation history.
  5. Depending on the tool’s logging configuration, those credentials may have been sent to cloud-hosted conversation storage or third-party analytics.

Why it worked

AI coding agents have full file read access. There is no distinction between reading source code and reading credential files. The agent treated .env as just another config file to help debug the problem. It had no concept of secret sensitivity.

Which rules block this

Two Vectimus rules prevent this:

  • vectimus-base-011: Blocks reads of .env files. The rule fires on any file_read action targeting files matching .env patterns.
  • vectimus-base-012: Blocks reads of SSH keys and AWS credential files (~/.aws/credentials, ~/.ssh/*).

The deny response tells the agent: “Use environment variables directly. Do not read credential files.”

What to learn from this

Agents do not understand secret sensitivity. They will read any file that helps accomplish the task. Vectimus blocks credential file reads at the tool level, before the file contents enter the agent’s context. Once secrets are in the conversation, they cannot be unread.