TL;DR: Many apparent social and autonomous actions in MoltBook-style agent behaviour are actually prompt-driven routines, according to Knostic’s analysis, while the real security risk comes from exposed instructions, remote skill updates, and the lethal trifecta of private data, untrusted input, and external actions. The governance problem is no longer whether agents seem intelligent, but whether their prompts, tools, and update paths are controlled as NHI-like execution surfaces.
NHIMG editorial — based on content published by Knostic: MoltBook-style AI agent mechanics and security implications
Questions worth separating out
Q: How should security teams govern AI agents that can change behaviour at runtime?
A: Security teams should govern runtime-changing AI agents like privileged non-human identities.
Q: Why do AI agents create identity governance problems for IAM teams?
A: AI agents create identity governance problems because they can hold credentials, access sensitive data, and take actions without a person in the loop for every step.
Q: What breaks when prompt files are not treated as controlled assets?
A: When prompt files are not controlled, the agent’s behaviour can drift without a corresponding access review or security approval.
Practitioner guidance
- Govern prompt and rule files as controlled policy objects Place agent prompts, system rules, and skill files under formal change control with approval, version history, and rollback.
- Restrict remote instruction retrieval Block unauthenticated or unverified remote skill loading, and require integrity checks before any fetched instruction is executed.
- Segregate data access from action authority Limit what the agent can see, what it can infer from untrusted content, and what it is allowed to do externally.
What's in the full article
Knostic's full blog covers the operational detail this post intentionally leaves for the source:
- Prompt excerpts and code-level mechanics showing how MoltBook and OpenClaw actually drive agent behaviour.
- The remote SKILL.md update pattern and why scheduled instruction fetching creates a supply-chain style risk.
- The practical parallels between AI agents, MCP servers, and coding agents in enterprise environments.
- The product context for Kirin, including validation, allowlisting, and drift detection details.
👉 Read Knostic's analysis of MoltBook-style AI agent mechanics and security risks →
MoltBook-style AI agents: what the control gap means for teams?
Explore further
Prompt files are becoming identity controls, whether security teams recognise them or not. The article makes clear that behaviour in agentic systems is shaped by prompts, timers, and rule files rather than by stable autonomy. That means the control plane is shifting into configuration assets that many organisations still treat as content, not policy. For IAM and NHI programmes, that is a structural change in where authority lives, and it demands governed lifecycle control.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
A question worth separating out:
Q: How can organisations reduce risk from untrusted AI agent inputs?
A: Organisations should separate untrusted inputs from privileged actions and require policy checks before the agent can act on them. That includes limiting what data the agent can access, constraining the tools it can call, and monitoring for instruction changes delivered through extensions or remote files. The key control is not trust in the model, but containment around the model.
👉 Read our full editorial: MoltBook-style AI agents expose the control gap in agentic security