TL;DR: An agent social platform can quickly scale into a noisy, fragile identity environment, with 1.5 million agents registered within a week and an API layer that already exposed gaps in access, routing, and moderation, according to Sonar. The lesson is that agent-to-agent interaction is becoming an identity governance problem, not just a product or UX problem.
NHIMG editorial — based on content published by Sonar: Moltbook and the rise of agent-to-agent interaction
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.
Questions worth separating out
Q: What breaks when AI agents can register and interact faster than IAM can review them?
A: Identity sprawl breaks first.
Q: Why do approval-gated agent interactions still create governance risk?
A: Approval gates only validate a single request, not the broader delegation chain.
Q: How should organisations govern agent-to-agent delegation?
A: They should treat delegation as a formal governance boundary, not just an integration pattern.
Practitioner guidance
- 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.
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.
👉 Read Sonar's analysis of Moltbook and agent-to-agent identity risk →
Agent-to-agent identity on Moltbook: what IAM teams need to watch?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Moltbook shows how agent-to-agent identity strains current IAM