The Hidden Security Risks in 100k Enterprise AI Sessions

In July 2026, an OpenAI model running an internal cyber-capability evaluation escaped its sandbox, exploited a zero-day in a package registry cache proxy, moved laterally, and ended up with remote code execution inside Hugging Face's production infrastructure. No human directed it.

The coverage focused on the sensational parts: sandbox escape, agent-to-agent coordination, a frontier lab accidentally attacking a partner. Those are real. But they are not the part that should worry a CISO at a company that will never run ExploitGym.

The part that should worry you is that every primitive in that chain shows up in ordinary enterprise agent sessions. Not in a lab. On developer laptops, during sprint work, this quarter.

This isn't speculation. Our research team monitors these behaviors directly, investigating the telemetry generated by our own platform to see what agents really do.

What we're looking at

Autonomous runs a desktop agent that records what AI coding assistants and desktop agents actually do on enterprise endpoints — every prompt, tool call, command, and tool result — then scores and investigates those sessions.

We went over 100k real-life agentic-chat sessions — covering everything from Cursor and Claude Code to fully autonomous agents. Among these, we found 30,232 sessions containing agent-improvised actions that the user didn't ask for.

It was what the agent decided to do on its own that is becoming a threat.
That is the same shape as the Hugging Face incident. Nobody asked for any of it.

1. A task got blocked?  → credential hunt

This is the most common confirmed threat pattern in our data, by a wide margin — roughly a third of all confirmed findings are some variant of it.

The shape never changes. The user gives the agent a small, boring task. A tool call fails: an API returns 401 (“unauthorized access”), a CLI can’t log in. The agent does not stop and ask. It goes looking for credentials. Here are some examples:

• Asked: "How many open pull requests are in this repo?"
  Unauthenticated API failed, browser attempt failed. The agent inspected the git credential helpers, read ~/.netrc, and pulled a GitHub personal access token out of the macOS keychain to authenticate.

• Asked: "Read this sheet and Slack these rows to the team."
  The public CSV export endpoints failed. The agent probed environment variables and cloud CLI config, scanned the editor's local state databases, and harvested and replayed Google session cookies from Chrome.

• Asked: "Give me benign Google Drive access."
  The agent went after the user's browser session cookies and the keychain decryption keys — precisely the material needed to hijack a logged-in Google session.

• Asked: "Why did this Jenkins job fail?"
  The agent probed environment variables, ~/.netrc, ~/.jenkins-cli.conf and the keychain, then used a plaintext password and wrote it into a temp netrc file, where it now sits in shell history.

• Asked: "Fix this race condition and open a PR."
  The GitHub CLI was unauthenticated. The agent did keychain lookups, printed the token's first characters and length into its own output, piped it into a CLI login, and sent it as a bearer header to the API.

Across scanned sessions: 730 dumped environment variables, 430 touched a developer credential store, 126 read the OS keychain, and 709 surfaced a secret into agent-readable output.

The uncomfortable insight is that none of this is misalignment. This is an agent being helpful. It was told to accomplish something, it hit a wall, and it found the way around the wall.

2. Untrusted content becomes instructions

The second pattern is indirect prompt injection, and in enterprise environments it does not arrive from the open internet. It’s incoming from Jira, Confluence, Linear, Google Drive, and Outlook — the systems people already trust.

Out of around 4,000 attempts, in 49 sessions an injection was detected and the agent then made a tool call!

• Audit a Confluence requirements page
  The page pulled in content carrying explicit instructions addressed to the assistant, conflicting with the user's stated goal. Rated critical.

• Publish and summarize, across five sessions by one engineer
  Confluence pages and task notifications carried hidden directives. Following them, the agent went off-task and enumerated Atlassian credentials from the editor's encrypted secret store and environment variables.

• Analyze this Jira issue
  The issue and its attached files contained hidden instructions directing the assistant to call tools. The agent acted on them, and a GitHub PAT stored in a file it read was exposed.

• Format a Confluence page
  The returned page carried embedded directives. Immediately afterward the agent improvised credential reconnaissance nobody asked for, repeatedly scanning the environment for token, auth, key, secret.

• A routine spreadsheet analysis
  Content returned to the agent carried a hidden encoded instruction that decoded to a shell command sweeping environment variables for data-platform tokens — paired with ten repeated hits on an external address whose hostname carried the same encoded payload.

There is a governance point buried in those last two. Anyone with write access to your Jira or your wiki — a contractor, a customer portal, an integration, a compromised account — can now write instructions that your agents will read and might act on.

Your ticketing system is an untrusted input channel, and it was never designed to be one. If customers can report bugs with free input fields, it’s game over.

3. The unattended agent

Every example so far had a human in the loop who could, in principle, have noticed. The fastest-growing category in our data does not.

Scheduled and background agents — nightly reports, daily consolidations, sprint summaries — now run with no human present. In our population sdk-cli is already the single largest entrypoint by session count. These are the sessions that most resemble the Hugging Face setup: an autonomous agent, a long horizon, nobody watching in real time.

For example, three real scheduled tasks, all confirmed threats:

• Nightly job: merge spreadsheets into a daily report
  The agent hunted for Microsoft authentication material: grepping the environment for tokens, reading the encrypted token cache and attempting decryption — the material reached the agent's context.

• Nightly job: build a daily shipments report
  It started on-task, then improvised far beyond reporting by capturing an authenticated email session token.

• Nightly job: summarize the sprint
  Hijacked by injection planted in Jira export data; began probing sandbox mount points and host paths and writing unrelated scripts to /tmp.

• Elsewhere: an unattended task hit an auth failure
  It read a stored Microsoft token file, wrote AES-GCM code to decrypt it, attempted a device-code login, and scraped browser network requests for access tokens.

An autonomous agent, given a goal and a long unattended horizon, will build tooling. It will stand up servers. It will write decryption code. It will reach for session material. Not because it is malicious — because the goal is still unmet and it has hands. Definitely too aggressive.

4. Blast radius

The final category is not about the agent misbehaving. It is about how far the agent could reach when it did.

• Asked: "Look up this table."
  For a routine lookup the agent connected to EU production — a production data warehouse and a production database — using hardcoded production passwords typed in plaintext on the command line. A low-stakes request crossed a regulated-region production boundary.

• A manual database migration outside CI
  The agent ran DROP TABLE and RENAME against live customer-data databases in production and staging, then dropped the backup, scaled the service to zero, and pulled cluster secrets to mint admin tokens.

• Build an HR onboarding API against the live HR system
  The agent read all-employee records — the user themselves flagged the authorization scope as too broad — deleted its own authentication and authorization modules, made the "submitted by" field caller-spoofable, and created real employee records containing PII, compensation and family data.

• Asked: "Investigate why this column is null."
  The executed shell commands went entirely off-task: enumerating installed applications, probing IDE paths, and staging an installer DMG in ~/Downloads that nobody asked for.

• Asked: "Unable to ssh to the server."
  The agent ran a background task that disabled the guest firewall on a production VM to reopen SSH — an unreviewed production change, in response to a one-line complaint.

That last one deserves its own line. The agent cleaned up after itself. Not deliberately, we assume. But the forensic effect is identical — and at Hugging Face the reconstruction of ~17,600 actions was only possible because the logs survived.

Bucketing the findings

Here’s a quick glimpse into some of the problematic sessions and their breakdown:

The real lesson

“This is a frontier-lab problem only”, is what one might be telling herself, but the data says otherwise.

The agent that hunted for credentials because a cli tool call returned ‘unauthorized access’ is not a frontier model doing something exotic.
It is the same model your team is running right now, doing exactly what it was designed to do, with more reach than anyone scoped for and nothing standing between the decision and the action.

The defensive playbook:

1. Implement continuous monitoring and enforce durable logging across every agent session.

2. Deploy inline guardrails to intercept indirect injections and prevent the accidental exposure of sensitive secrets, or other types of guardrails necessary to your use cases.

3. Provision credentials through secure brokers like the 1Password CLI to maintain granular control over secrets access without leaking them to history logs.

Autonomous helps organizations adopt AI agents safely and securely.