If only all these agentic entry points could be guarded by the protector troll. (Photo by me.)

After people accepted generative AI as useful (which is debatable, but that’s an argument for another time), the obvious next step was to develop agents that could first automate tasks, then practice reasoning and make decisions. Those are the functions of AI that we now see in most production systems. A 2025 PagerDuty survey found that “51% of companies have already deployed AI agents at their organization.” Developing and using agents as autonomous actors is new, but the access control systems being used for them are not.

Agents with inaccurate or improper access credentials can create measurable (and also not-yet-measurable) risk. In the incident at Moltbook, malicious actors were reportedly able to access exposed API keys to impersonate agents and issue commands.

What actually happened at Moltbook?

A caveat: not everyone thinks Moltbook is a big deal, but let’s treat it like one for this discussion.

API keys were exposed at Moltbook because of a basic failure to limit access control. Moltbook uses Supabase as a datastore, and Row Level Security was not enabled on tables that store authentication artifacts. In Supabase, tables in exposed schemas (like public) are reachable through the Data API unless row-level security policies explicitly restrict access to them.

Those security controls were missing, so sensitive records could be read by unauthorized users. Reports indicate that the exposed data included agent API keys, claim tokens, and verification codes. Users with these credentials could reportedly authenticate as an agent and issue commands as that agent.

Weak access controls mean that security wasn’t a focus during implementation, so sensitive tables were easily accessible. When engineers are under pressure to prioritize speed and functionality over basic security, this happens a lot. The underlying rationale is that engineers can add protections when a system is in production… and malicious actors love it when teams make that assumption.

This annoyingly prevalent “ship fast, secure later” ethos allows for bigger risks with AI agents than it did with traditional systems. This type of security failure used to simply compromise static data; now it increases behavioral risk, including how models make calculations and respond to inputs. This clears a path for bad actors to copy, manipulate, or abuse the agent in ways that key rotation or patched data leaks might not fix.

Why no one is checking the agents’ IDs

For starters, due to either a lack of resources or a rush to release, many teams grant broad access by default instead of practicing the least-privilege principle. Organizations like the CNCF have often noted that machine identities, including service accounts and agents, are overlooked during access reviews. In a 2025 paper, the OpenID Foundation said that “ambitions for highly autonomous agents raise complex long-term questions regarding scalable access control, agent-centric identities, AI workload differentiation, and delegated authority.”

As one might expect, vibe coding and the rise of AI-assisted IDEs also support a mindset of speed over security. This enables (and sometimes encourages) engineering teams to skip the process of making thoughtful decisions about identity boundaries or privilege separation. It lets static credentials and permissive defaults go unquestioned.

Legacy identity and access management systems weren’t designed to manage these challenges. They’re good for predictable, user-based actions, like people clicking through applications. But autonomous agents can act based on learned inputs. They can trigger workflows and call other tools independently. This builds a kind of complexity that older access management approaches don’t address.

Think about taking away that access badge

Most AI agents are still given static API keys or hardcoded secrets with broad permissions. That approach works for simple scripts, but agents can adapt behavior based on prompts, chain actions together, and operate across infrastructure. They should be treated as identities and granted short-lived, automatically rotated credentials that are tied to specific workloads.

The system should be able to assess “who” an agent is and what it’s allowed to do. Engineers should be able to trace what an agent did, which credentials it used, and what resources it touched. Every request should be explicitly authenticated and authorized. Internal location (or past behavior!) is not a substitute for access control, especially when agents can work across complete systems or environments.

When you play chess with AI agents, consider every possible move

Engineering managers can set expectations for their teams, stating that AI agents are first-class identities with scoped permissions and short-lived credentials. But teams should still review access before agents move into production, just like they would for any other user. Teams should also use logging tools to trace which agent acted, what it did, and what permissions it used.

Thinking carefully about agent access, and designing it properly during the development and provisioning phases, is easier than mitigating a security issue after something goes wrong. Good access design might even help you avoid receiving a Darwin Award.

Postscript: I wrote this in February 2026. Obviously, other big, um, "agentic incidents” have happened since then. I’ll get to that soon.

Home

Credentials for AI agents aren't enough