Spotlight

The Keys Were in the Logs: How AI Coding Agents Are Leaking Credentials Into Your Security Data

Your MSSP has "read-only" access to your SIEM? You may have just handed over full control of your entire organization.

Matan Caspi

Matan Caspi

Co-Founder & Chief Architect at Mars Security

March 29, 2026

Every security team's worst nightmare isn't a sophisticated zero-day or a nation-state APT. It's discovering that the keys to the kingdom have been sitting in plain sight, buried in a data source nobody was looking at, for who knows how long.

That's exactly what we found.

Using our platform, which lets us search across an organization's entire security stack in seconds, we uncovered a critical exposure in a customer environment that turned low-level read access to a secondary data lake into full administrative control of the entire enterprise. Cloud, endpoints, domain controllers, SaaS. Everything.

None of it required any exploitation. The credentials were just... there.

What happened

Over the past two years, developers have started handing credentials directly to AI coding agents like Claude Code and Cursor. AWS keys, API tokens, bearer tokens, anything to make life easier. "Here's my key, go check that S3 bucket." The agents happily oblige, they run curl, aws-cli, and other tools with full secrets right there in the command line.

The problem? Security tools, such as EDR agents log full command lines. That's their job. So every time a developer asks an AI agent to run something with a pasted secret, that secret ends up in security telemetry. Some vendors try to redact this stuff, but the sheer variety of key formats and naming conventions makes reliable redaction basically impossible.

DeveloperPastes secret into AI coding agentAI coding agentRuns aws-cli / curl with secret inlineEDR agentLogs full command line + secretForgotten data lakeUnmonitored · credentials accumulateread accessAttackerFinds AWS keys + EDR admin tokensEDR platformExecute on any endpointFull enterprise compromiseAD · Entra ID · email · CI/CD · CRM · SaaS

What we found

While onboarding this customer, our platform automatically connected to a second-tier security data lake that had been collecting endpoint telemetry for months. Not a single person in the organization had ever queried it. Not once. No alerts, no dashboards, no scheduled searches. It was completely dead data, lying in wait, until we plugged in.

When we made it searchable alongside everything else, what surfaced was alarming: AWS keys granting access to the company's core services, API keys to their data lake, and admin-level tokens for their EDR platform, the same platform protecting every endpoint in the environment, including domain controllers.

Those EDR tokens alone were enough to execute commands on any endpoint running the agent. Domain controllers included. From there, an attacker owns Active Directory, pivots to Entra ID, and reaches every SaaS app behind organizational SSO. Email, source control, CI/CD, CRM, everything.

Read access to a forgotten data lake that nobody was using = full compromise of cloud, on-prem, and SaaS. The entire organization.

Why it matters

All of this was sitting in a data source the customer didn't even know was useful. It had been collecting logs the whole time. The credentials were being written to disk every day. But because nobody was querying it, the exposure was completely invisible.

The only reason we found it was because our technology treats all data sources the same. When you can search across everything at once, there's no such thing as a "secondary" data lake. There's no dead data. There's just data you haven't looked at yet.

What you should do

If your developers are using AI coding agents, you should assume credentials have leaked into your security telemetry.

Treat your SIEM and log infrastructure as a sensitive asset. Any system that records full command lines now potentially holds the keys to your entire organization. Most companies don't think of their SIEM that way when they do risk assessments. They should. Apply the same access controls and monitoring you'd give a credential vault.

Scan your logs for accumulated credentials on a regular cadence. Search for patterns matching API keys, bearer tokens, AWS secrets, and other credential formats in your process execution telemetry. This shouldn't be a one-time exercise. Make it periodic.

Rotate everything you find. Treat any credential that shows up in logs as compromised. Rotate it, audit its usage history, and check for anomalous access during the exposure window.

Take a hard look at the data sources nobody's been watching. The data lake that nobody queries might be the one hiding your biggest exposure. If you can't search it, you can't secure it. At least audit what's sitting in those forgotten corners.

Next spotlight drops soon. Stay tuned.