Moltbook shows how agent-to-agent identity strains current IAM

At a glance

What this is: Sonar’s Moltbook write-up shows an AI-agent social platform scaling rapidly while exposing fragile API access, noisy interactions, and early governance gaps.

Why it matters: IAM teams need to treat agent registration, delegated access, and approval flows as governance issues before agent ecosystems create unmanaged access sprawl.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read Sonar's analysis of Moltbook and agent-to-agent identity risk

Context

Agent-to-agent platforms create a new identity layer, because software entities can now post, message, request access, and trigger actions on behalf of humans. In that model, the governance problem is not just authentication, but inventory, delegated authority, and the lifecycle of machine-like actors that behave at runtime.

Moltbook is a useful stress test because it mixes rapid agent registration, direct messaging, approval-gated interactions, and a developer API in one environment. That combination makes it easier to see where existing IAM assumptions break down when the subject is an AI agent rather than a person.

The article also shows an early-stage reality that is typical of emerging agent ecosystems: growth outpaces control design. That is exactly when identity teams need to separate experimentation from production-grade governance.

Key questions

Q: What breaks when AI agents can register and interact faster than IAM can review them?

A: Identity sprawl breaks first. When agents can self-register, post, message, and join communities faster than owners can validate them, the environment fills with unowned actors. That creates a governance gap in lifecycle control, because access is granted before purpose, scope, and retirement are established.

Q: Why do approval-gated agent interactions still create governance risk?

A: Approval gates only validate a single request, not the broader delegation chain. An approved message or token exchange can still lead to repeated actions, onward access, or uncontrolled reuse if scope and expiry are not enforced. That is why point approvals do not replace lifecycle governance.

Q: How should organisations govern agent-to-agent delegation?

A: They should treat delegation as a formal governance boundary, not just an integration pattern. That means defining what data can move between agents, how inherited permissions are recorded, and when delegated actions require review. Without that, one agent can extend another's access in ways the original control model never saw.

Q: What is the difference between agent automation and agent autonomy for IAM teams?

A: Automation follows a predefined workflow, while autonomy implies runtime decision-making about actions, tools, and timing. For IAM, that difference matters because autonomous behaviour can change scope mid-session and outpace human review cycles. Governance has to match the actor’s decision speed, not just its API usage.

Technical breakdown

Agent registration and profile binding in social platforms

Moltbook-style systems bind an AI agent profile to a human owner handle, then expose posting and messaging functions through an API. That makes the agent a governed actor, not just a feature. The technical risk is that registration can happen faster than entitlement review, so the platform accumulates active identities before anyone can validate purpose, ownership, or allowed interaction scope. In identity terms, the system is mixing authentication, delegation, and discovery in a single control plane, which increases the chance of shadow AI and unowned access paths.

Practical implication: require explicit ownership and lifecycle state for every agent before it can post or message.

Scheduled execution and proxy-mediated tool access

The article describes a four-hour scheduler that wakes the agent, checks DMs, browses communities, posts, and then sleeps. That is not autonomy in the strict sense, but it is still a repeatable identity workflow with tool access routed through a proxy layer. Proxy mediation concentrates control, yet it also creates a single enforcement point for tokens, request forwarding, and rate limits. When that layer is brittle, the platform inherits the blast radius of every downstream call the agent makes.

Practical implication: treat proxy layers as policy enforcement points and instrument every forwarded identity action.

Delegated third-party access for agent-to-agent collaboration

The forward-looking part of the article is the most important: agents may soon install other agents, exchange temporary credentials, and hand off code review or delivery tasks without a human in the loop. That model moves from simple automation to delegation chains, where one agent acts on behalf of another system and possibly on behalf of a human owner. The governance challenge is not just who authenticated, but who can authorize onward access, what the delegated scope includes, and when that scope ends.

Practical implication: design agent delegation controls around scope, expiry, and revocation rather than durable trust.

Threat narrative

Attacker objective: The objective is to obtain persistent, scalable interaction capability across agent communities and use that channel for attention, outreach, or delegated access abuse.

1. Entry occurred through rapid agent ecosystem growth, where a developer API and self-registration path created many new identities before controls could mature.
2. Escalation came from delegated access paths, where the platform’s proxy model and approval-gated DMs expanded what each agent could attempt inside the environment.
3. Impact was noisy but real: spam, weak moderation signals, flaky APIs, and the risk that agent interactions become a durable access channel rather than a controlled workflow.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent-to-agent platforms turn identity governance into a lifecycle problem, not a login problem. Once agents can register, message, and later delegate tasks, the critical questions become ownership, scope, and retirement. That is a classic governance pattern, but the actor is now a non-human system that can scale faster than manual review. Practitioners should stop treating agent registration as product onboarding and start treating it as identity lifecycle control.

Approval gates reduce noise, but they do not solve delegated trust. The article shows human approval on DMs and proxy-mediated routing, which helps with spam and abuse filtering. But approval on one action does not govern what an agent can do after it is admitted into the interaction chain. The practical conclusion is that point-in-time approval is a weak substitute for explicit access boundaries.

Agent ecosystems create a new form of identity sprawl. Rapid registration growth, multiple interaction modes, and external API access produce a population of actors that looks more like unmanaged service accounts than like human users. That means existing IAM metrics such as login success or MFA coverage do not tell the full story. Teams need inventory, ownership, and revocation discipline for every agent identity.

Delegation chains are where accountability starts to blur. The article’s future-state discussion, where one agent installs or hands off work to another, is the real governance pressure point. Once an agent can pass temporary access onward, the organisation must know who is accountable for the original grant, the onward use, and the end of that session. That is where identity governance either becomes explicit or disappears into platform noise.

There is a clear governance assumption collapse here: access review processes were designed for actors whose privileges persist long enough to be reviewed. That assumption weakens when an agent can self-initiate actions, sleep, wake, and exchange access in short cycles. The implication is that identity programmes need a different mental model for time-bound, machine-paced delegation.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a forward look at AI-agent exposure patterns, see Moltbook AI agent keys breach, which shows how fast identity material can accumulate in agent ecosystems.

What this signals

Agent identity programmes will increasingly fail at the edges, not in the core directory. The real pressure point is not whether an agent can authenticate once, but whether it can be continuously owned, scoped, and retired across interactions that happen faster than human review cycles. That is why agent governance needs lifecycle states, not just registration events. With 75% of organisations still overconfident in secrets management, according to The State of Secrets in AppSec, the same overconfidence is likely to repeat in agent identity.

Non-human identity sprawl is now a programme design problem. When platforms add DMs, APIs, proxy routing, and future delegated installs, the control surface expands faster than traditional IAM recertification can track. Teams should expect more shadow AI, more unowned accounts, and more short-lived access artefacts that never make it into standard review queues.

The useful next step is to connect agent identity governance to established NHI controls and then extend them for runtime delegation. That means treating agent discovery, ownership, token scope, and revocation as one operating model rather than separate projects. The governance question is no longer whether agents will need identities. It is whether the organisation can keep up when they start giving access to each other.

For practitioners

• Define an ownership record for every agent identity Tie each agent to a named business owner, approved purpose, interaction scope, and retirement condition before it can register or interact with others.
• Instrument proxy layers as policy checkpoints Log every forwarded API call, token exchange, and delegated message so the proxy becomes an auditable enforcement point rather than a blind relay.
• Separate experimental agents from production access Keep proof-of-concept agents away from real repositories, DMs, and third-party credentials until lifecycle controls and revocation paths are defined.
• Set expiry on delegated agent access Use short-lived tokens and explicit revocation triggers for any agent that can hand work to another system or act after initial approval.

Key takeaways

• Moltbook is a reminder that agent ecosystems create identity sprawl long before they create mature governance.
• The practical control gap is not authentication alone, but ownership, delegation scope, and revocation for every agent identity.
• IAM teams should prepare for short-lived, machine-paced access flows that outgrow human review cadences.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
• Protocol Mediation: Protocol mediation is the use of an access layer that terminates one side of a session and relays approved actions to the target system. In industrial environments, it allows security policy to sit between the user and the asset, but it also creates a control point that must be audited and protected.

What's in the full article

Sonar's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact proxy architecture used to route agent calls through the backend and the failure modes it introduced.
• The six Moltbook tools built for browsing, posting, DM handling, and lead capture, including how they were wired into the agent loop.
• The debugging notes behind the scheduler bugs, API errors, and rollout issues that affected the experiment.
• The authors' future-state ideas for agent authentication, delegated code access, and federated review workflows.

👉 The full Sonar post covers the experiment details, platform failures, and future agent delegation ideas.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.