AI Agent Identity: Lessons from Fedora's Rogue Agent

For roughly two weeks at the end of May, an AI agent worked inside the Fedora project. It triaged bugs, replied to threads, reassigned tickets, and submitted pull requests. Some of its code was merged into Anaconda — the Fedora installer. Nobody had invited it. Nobody knew it was an agent.

LWN published the full account this week. The agent was operating under the account of a real, trusted contributor. When Fedora’s Adam Williamson traced the strange activity back to its source, the account owner said his credentials had been compromised. The agent wasn’t his.

Fedora revoked the account’s privileges. Then came the harder part: working out everything the agent had touched.

The audit that can’t be completed

This is the detail worth sitting with. Part of the agent’s GitHub activity is tied to an account that has since been deleted, so the trail just shows a ghost. Nobody knows the motive. Nobody can produce a complete list of what it changed — in Fedora or in the upstream projects that accepted its PRs.

That’s not a tooling gap Fedora can patch. The agent’s actions were performed with a human’s identity, through a human’s account, carrying a human’s accumulated trust. Until its behavior got strange enough to notice, there was no signal separating agent actions from human actions. And once it was caught, there was no clean way to unwind them.

An identity problem, not a model problem

Most of the agent-safety conversation focuses on model behavior: alignment, guardrails, prompt injection. Those matter — we’ve spent real engineering time on them ourselves, including training a 22MB prompt-injection classifier that runs in front of tool calls.

But the Fedora incident would have played out identically with a perfectly aligned model under malicious direction. The model didn’t fail. The identity layer did — twice:

Detection. An agent acting as a human is indistinguishable from a human until it makes a mistake. Fedora caught this one because its behavior eventually got weird. A more careful operator doesn’t get caught.
Attribution. When the agent acts through a person’s credentials, revocation takes the person down with it, and the audit trail stops at the person — not at the agent, its operator, or its purpose.

Trust is the new attack surface

The top Hacker News comment on the LWN story called this a rehearsal for an xz-style attack, and the comparison holds. The xz backdoor worked because its author spent about two years doing patient, helpful maintenance before shipping the payload. Trust was the expensive part of that attack.

Agents collapse that cost. One operator can now run the long-con contributor playbook across a hundred projects simultaneously — triaging issues, fixing small bugs, building reputation at machine speed. Open source’s core assumption, that consistent helpful behavior signals a trustworthy human, breaks in both directions: attackers can fake the signal, and legitimate agent contributions drown in the resulting suspicion.

Blanket bans aren’t the answer — curl shutting down its bug bounty in January showed that blanket measures mostly punish maintainers. The answer is making agents legible.

What good agent identity looks like

When an agent acts through its own scoped credentials instead of a borrowed human account, every failure mode above inverts:

Its own identity. Every action is attributable to the agent, its operator, and its purpose. No ghosts in the git log.
Scoped permissions. The agent gets the narrowest set of grants that lets it do its job — not the union of everything its operator can do. We’ve written about how OAuth should work for AI agents, and why per-agent token exchange beats credential sharing.
A contained blast radius. If the agent misbehaves or its credentials leak, the damage boundary is the agent’s scopes — not a maintainer’s entire account.
An independent kill switch. Revoking the agent doesn’t take a human contributor offline. Fedora had to disable a real person’s privileges to stop a machine.
A complete audit trail. Agent actions land in downstream systems tagged as agent actions, queryable after the fact. The audit Fedora couldn’t complete becomes a database query.

This is the same model enterprises already use for human contractors: they get their own badge, their own access card, their own entry in the audit log. They don’t borrow an employee’s face. MCP gateways are where this enforcement naturally lives for agent tool access — a single choke point where identity, scopes, and logging happen regardless of which model or framework is behind the agent.

A checklist for teams shipping agents

If you’re putting agents into systems that matter, the Fedora incident reduces to five questions:

Does each agent have its own credentials, or is it borrowing a human’s?
Are its permissions scoped to its actual job?
Can you revoke it without disabling a person?
Can you list everything it did last month, in every system it touched?
Would you notice if it started doing something else?

Fedora’s answer to all five was no — through no fault of their own, because the agent was never theirs. The uncomfortable part is that most internal agent deployments today, running with pasted API keys and shared service accounts, would answer no to most of them too.

The takeaway

Agents should be able to do everything a human can do. Doing it anonymously shouldn’t be on the list.

That’s the principle behind how StackOne connects agents to enterprise systems: per-agent identity, scoped OAuth credentials, and a complete action log across 200+ apps — so the day one of your agents goes rogue, the audit is a query, not an archaeology project.

If you’re building agents that act across real systems, book a demo and we’ll show you what per-agent identity looks like in practice.