Your AI Platform Has Your Keys: Fireworks AI’s Secrets Breach, Meta’s GitHub Leak and an Unpatched Agent Flaw (AI Trends, 16 October 2026)

What’s trending in AI on 16 October 2026: The attacks on AI this month have not been about tricking a chatbot. They have been about the keys stored next to it. Fireworks AI, an inference platform that runs open and custom models for developers, says an intruder used internal credentials to read environment variables inside customer evaluation jobs and probably captured the API keys and tokens stored there. Its chief executive said the attacker’s behaviour looked agentic. Meta is notifying about 1,500 people after an employee’s stolen login opened several of its GitHub repositories, where personal data should never have been. Archon, a popular open-source tool for running AI coding agents, has a missing-authentication flaw that VulnCheck rates critical, with no fix yet. And a VentureBeat survey published today found that 44 of 102 enterprises still let AI agents share credentials. If your teams test models, run agents or wire AI tools into code and cloud accounts, this is the week to count your secrets. Below: what happened, what links the incidents, and a set of if-then rules for responding.

Key takeaways

AI platforms are now secrets stores. Fireworks AI believes API keys and tokens kept as secrets in evaluation jobs were captured in a limited number of customer accounts.
Deleting a secret does not revoke it. Fireworks told customers to rotate exposed third-party keys with the issuing provider, even if they see no misuse.
One stolen login is still enough. Meta’s GitHub leak needed no product flaw, just an employee credential and personal data stored where policy said it should not be.
Agent tools ship open by default. Archon’s control API listens on all network interfaces with authentication off on a stock install. No patch existed as of today.
Most firms cannot cut an agent off quickly. In VentureBeat’s survey, only 14 of 102 enterprises said they could revoke an agent’s access within minutes.

Four incidents in ten days, one common thread: credentials sitting where AI workloads can reach them.

1. What happened at Fireworks AI

Fireworks spotted the activity at 9am Pacific on 6 October and began containment straight away, according to its security bulletin. An unauthorised party had used internal Fireworks credentials to reach the environment variables that customers attach to evaluation jobs, the runs that score a model’s outputs against a test set. Evaluation jobs often need to call other services, such as a second model provider acting as a grader, a cloud bucket holding test data or a tracking tool, so they are a natural place for keys to collect.

The company says it has no evidence, within its own perimeter, that anyone touched customer models, datasets, training data, prompts, outputs or personal information. What it does believe is that secrets were taken: API keys and tokens for other services, stored in the affected accounts. Fireworks has not said how many accounts were affected beyond calling the number limited, and it has not explained how its internal credentials were obtained. It says it is reviewing how secrets are made available to evaluation jobs.

The detail that has drawn most attention came from chief executive Lin Qiao. Asked on X whether the intruder was a person or an AI agent, she replied, as reported by security firm Lava, “From the behavior, it seems agentic.” That is an impression, not a finding, and Fireworks has published nothing to support it. It fits a pattern Delana has followed for weeks, from attacks on AI serving infrastructure to flaws in AI gateways and control planes: attackers are going after the plumbing around models rather than the models themselves.

Four days separated detection from the completed first credential review. Rotation was still continuing after that.

The bulletin’s advice is worth reading even if you are not a customer, because it applies to any platform holding your keys. Replace revoked Fireworks keys. Rotate every third-party credential named in your notice with the provider that issued it. Review those providers’ logs for unexpected reads, downloads or changes. Check your account for API keys, users, evaluators, training jobs or datasets you do not recognise.

2. Meta: one stolen login, 1,500 notices

On 13 October, Meta began notifying about 1,500 people, most of them US-based employees, that their personal information was exposed when an outside group used an employee’s stolen credentials to get into several of the company’s GitHub repositories. SecurityWeek reports that Meta detected the intrusion a few weeks earlier, cut off access, and worked with GitHub and law enforcement. Meta says about 99% of what was taken was business material, mainly code for some products. The other 1% was personal data that, according to Cybernews, had been placed in the repositories by mistake and against company policy.

Meta’s statement draws a careful line: “This was not a vulnerability in any Meta product,” it said, and its internal systems were not breached. That is true and also the point. Nothing had to be broken. A valid login reached a code platform where secrets and personal records had collected over time. Meta says it has rotated the secrets it found, added controls to keep user data out of GitHub and is building scanning to catch it when it slips in. It also says some of the apparent personal data was synthetic or anonymised test data, and it does not believe it was specifically targeted.

For smaller organisations, the lesson is that repositories are rarely as clean as policy says. Test fixtures, exported spreadsheets and configuration files with live keys end up in code more often than teams admit, and AI coding assistants that read whole repositories can surface them faster. We covered one version of that risk when GitHub Copilot CLI leaked a secrets file earlier this month.

3. Archon: an agent control panel with no lock

Archon is an open-source workflow engine that drives coding agents such as Claude Code and Codex through YAML-defined steps. On 15 October, VulnCheck published CVE-2026-111322, a missing-authentication flaw affecting versions 0.2.13 through 0.11.1. The control API under /api/* listens on all network interfaces by default, and authentication only turns on when both a Postgres database URL and an auth secret are configured. A stock install using SQLite has neither.

Anyone who can reach port 3090 can therefore start workflow runs, inject messages into agent conversations, approve or reject actions the agent paused on, and manage stored provider keys. How bad that is depends on who you ask. VulnCheck scores it 9.3 under CVSS 4.0, and a mirror lists 9.8 under CVSS 3.1, tying it to command execution through the agent’s permission-bypass mode. The researcher who found it says it is “not remote code execution on the host” and rates it high rather than critical. As of 16 October, the latest release was still affected, no vendor fix had shipped, and there was no public proof of concept.

Severity is disputed, from 9.8 to “high”, but the fix is the same: take the port off the network.

Whichever score you prefer, an internet-reachable agent console that can approve its own paused actions and hand out provider keys is a problem. Check whether anything on your network is listening on 3090, bind it to localhost, switch on authentication and put shared installs behind a proxy that requires a login. This is the same permissions problem we keep seeing with agents, moved one layer down into the tooling.

4. AgentCore: when the agent hands over its own role

The fourth piece is research rather than a breach. On 8 October, Zenity Labs presented work on Amazon Bedrock AgentCore showing that, in its test account, asking a public-facing agent with a web-request tool to fetch the cloud instance metadata service returned the agent’s own temporary AWS credentials. The default execution role covered resources across the whole account and region, The Next Web reports, which let the researchers list other agents, download code, read private conversations and open AWS Secrets Manager, including keys for services outside AWS. They also planted a false memory that made an agent visit a page they controlled before every answer.

AWS disputes the framing. It says the research “inaccurately paints expected and documented behavior as a vulnerability” and that cross-resource access needs permissions a developer grants. It has since moved new agents to IMDSv2, which requires a session token for metadata requests, and Zenity found on 29 September that the default role had been narrowed. Both sides agree on the remedy: give each agent’s role only the permissions it needs. VentureBeat noted that Fireworks posted its bulletin the day after Zenity’s disclosure, a reminder of how quickly theory and practice are converging.

The model is rarely the prize. The keys sitting beside it usually are.

5. The pattern: AI pipelines collect secrets

Put the four stories side by side and the shared weakness is clear. AI workloads need to call many other services, so teams hand them long-lived keys, often broad ones, and store them wherever is convenient: an environment variable on an evaluation job, a repository, an agent’s cloud role, a tool’s settings page. Each copy is a new place to steal from, and most organisations cannot say how many copies exist.

Incident	Where the secret sat	How it was reached	Status on 16 Oct 2026
Fireworks AI (detected 6 Oct)	Environment variables in customer evaluation jobs	Internal Fireworks credentials used by an unauthorised party	Keys revoked and rotated; review of other access continuing
Meta GitHub (notices from 13 Oct)	Code repositories, including secrets and stray personal data	An employee’s stolen login	Secrets rotated; about 1,500 people offered monitoring
Archon CVE-2026-111322 (published 15 Oct)	Provider keys and agent controls behind an open API	Unauthenticated network access to port 3090	No fix released; mitigations available
AWS AgentCore research (8 Oct)	The agent’s execution role and Secrets Manager	A prompt asking the agent to fetch instance metadata	AWS says documented behaviour; defaults since tightened

Sources: Fireworks AI, SecurityWeek, Cybernews, The Hacker Wire, DEV Community, The Next Web. Details reflect public statements as of 16 October 2026.

Today’s VentureBeat survey shows how common the underlying habit is. Of 102 enterprises asked in September, 35 give each agent its own identity, 45 share credentials to some degree (VentureBeat’s headline count is 44), and 22 could not say how their agents authenticate. Even among the 40 that said they enforce scoped identities and runtime permission checks, 17 admitted some or most agents still share credentials. Shared credentials matter in an incident because you cannot cut off one compromised agent without breaking every other workload that uses the same key.

Only 14 of 102 organisations said they could cut off an agent within minutes.

Speed of revocation is the number to watch. Only 14 respondents said they could revoke an agent’s access within minutes. Meanwhile 40 reported a confirmed agent security incident or near-miss in the past year, and 12 do not track agent incidents at all. If an attacker can act in minutes and you need a day, the gap is the breach.

6. Why “we deleted it” is not a fix

Fireworks made a point many teams miss: deleting a stored secret does not invalidate the credential itself. If a key was copied, the attacker still has a working key until the provider that issued it revokes it.

Rotation is also slower than it sounds. Every application using the old key breaks until it is updated, which is why teams postpone it and why Fireworks was still rotating four days after detection. The fix is structural: short-lived tokens where providers support them, one key per workload so a single revocation has a small blast radius, and a written list of where each key lives. Treating agents and AI jobs as insiders with their own access to manage is a useful way to frame the work, and stolen sessions remain the most common way in for attackers generally.

7. If this, then that: rules for AI secrets this week

Rather than another long checklist, here are conditional rules. Find the ones that describe your situation and act on those first.

If you use Fireworks AI, read any incident notice in full, replace revoked keys, rotate every third-party credential it lists at the issuing provider, and review those providers’ logs back to at least 6 October. Do this even if you see nothing suspicious.
If any AI platform holds third-party keys for you, list them today. For each, record the provider, its scope and who can rotate it. Replace broad keys with narrowly scoped ones, one per workload.
If you run Archon anywhere, check for a listener on port 3090, bind it to 127.0.0.1, turn on authentication and test from a second machine that the API no longer answers. Watch the repository for a fixed release.
If your agents run in the cloud, confirm metadata access requires IMDSv2 or the equivalent, and that each agent’s role covers only its own resources. Remove secrets-manager access the agent does not strictly need.
If agents or AI jobs share a credential, split it. Give each agent its own identity so you can revoke one without stopping all of them. Count how many agent identities you have while you are at it.
If you cannot revoke an agent within minutes, write and rehearse the steps: who pulls the key, where, and what breaks. Time the drill.
If code repositories might hold secrets or personal data, run a secrets scanner across full history, not only the latest commit, and rotate anything it finds. Add pre-commit scanning so new keys are blocked.
If staff use unapproved AI tools, assume keys and data have been pasted into them. Our guide to shadow AI covers how to find and govern them.

None of these require new products. They require knowing where your keys are, which is the part most organisations skip. Our broader overview of AI agent security explains why that ownership question so often goes unanswered.

8. The bottom line

The four stories from the past ten days are different in detail but similar in shape. An inference platform’s evaluation jobs, a code repository, an agent orchestration tool and an agent’s cloud role all held credentials that unlocked far more than the AI system itself. The good news is that the response is well understood: scope keys narrowly, keep them short-lived, give every agent its own identity and practise revoking access. Organisations that can answer “where are our AI keys and how fast can we kill them?” will handle the next bulletin calmly.

Frequently asked questions

What happened in the Fireworks AI security incident?

On 6 October 2026, Fireworks AI found that an unauthorised party had used internal Fireworks credentials to access environment variables in evaluation jobs in a limited number of customer accounts. The company believes API keys and tokens stored there as secrets were captured. It says it has found no evidence of access to customer models, datasets, prompts, outputs or personal information within its perimeter.

Was the Fireworks AI attacker an AI agent?

Unconfirmed. Chief executive Lin Qiao said on X that the behaviour seemed agentic, according to security firm Lava, but Fireworks has not published evidence and its investigation is continuing.

What should Fireworks AI customers do?

Replace any revoked Fireworks API keys, rotate every third-party credential listed in the incident notice with its issuing provider, review those providers’ logs for unauthorised activity, and check the account for unrecognised keys, users, evaluators, training jobs or datasets. Deleting a stored secret does not invalidate it.

What was exposed in the Meta GitHub breach?

Attackers used an employee’s stolen credentials to access several Meta GitHub repositories. Meta says about 99% of the data was business material such as product code and about 1% was personal data placed there by mistake. About 1,500 people, mostly US employees, are being notified and offered credit and dark web monitoring.

Is there a fix for the Archon vulnerability CVE-2026-111322?

Not as of 16 October 2026. Versions 0.2.13 through 0.11.1 are affected. Until a fix ships, bind the service to 127.0.0.1, enable authentication by setting DATABASE_URL and a BETTER_AUTH_SECRET of at least 32 characters, and put shared installs behind an authenticating proxy.

How can businesses reduce the risk of AI platforms leaking their keys?

Inventory every credential given to AI platforms, agents and tools; scope each key to one workload; prefer short-lived tokens; give every agent its own identity; scan repositories, including history, for secrets; and rehearse revoking an agent’s access so it takes minutes rather than days.