Most AI agent security incidents share a common pattern: a stranger messages the bot, and the bot simply complies. No sophisticated hacking. No prompt injection attacks. Just a random person sending a DM and getting full access to whatever the agent can do. This is why understanding DM policies is essential for anyone running an autonomous AI agent.

Through building and deploying Clawdbot across multiple environments, I have seen firsthand how access control determines whether your agent becomes a helpful assistant or an open door for anyone on the internet. The good news is that proper configuration takes just a few minutes and prevents the vast majority of unauthorized access attempts.

The Four DM Policy Modes

Clawdbot provides four distinct modes for handling direct messages, each serving different use cases and security requirements.

Pairing mode is the default, and for good reason. When someone sends your bot a DM, they receive a six digit pairing code. This code expires after one hour, creating a time limited window for authorization. The bot owner must explicitly approve the pairing using the command clawdbot pairing approve followed by the channel name and code. Until approval happens, the stranger gets nothing but a polite message explaining how pairing works.

Allowlist mode takes a stricter approach. Only users you have explicitly added to the allowlist can interact with your bot via DM. Everyone else gets ignored entirely. This works well for team deployments where you know exactly who should have access.

Open mode does what it sounds like: anyone can DM your bot and start interacting immediately. I only recommend this for public facing bots with carefully constrained capabilities, and even then you should think twice. Most bots should never run in open mode.

Disabled mode turns off DM handling completely. Your bot only responds in group contexts where you have configured it. This is the most secure option if you genuinely do not need one on one interactions.

Why Pairing Is the Correct Default

The pairing system strikes the right balance between security and usability. Consider what happens without it: anyone who discovers your bot’s username can start giving it commands. If your bot has access to your files, your calendar, your email, or your browser, that access extends to every random person who messages it.

The one hour expiration on pairing codes prevents a common failure mode. Someone requests a code, you forget about it, and weeks later they use it to gain access. With expiration, old codes simply stop working. If a legitimate user needs access, they request a fresh code and you approve it promptly.

The explicit approval step also creates an audit trail. You know exactly when you granted access and to whom. When something goes wrong, you can trace back through your approvals rather than wondering who might have stumbled onto your bot.

This matters more than most people realize. I have talked to developers who ran agents in open mode for “convenience” and discovered their bots had been sending emails, making API calls, or browsing websites on behalf of complete strangers. The fix is simple, but the damage from skipping it can be significant.

Session Isolation and Multi User Support

Even after granting access to multiple users, you probably do not want them sharing context. My conversation history should not leak into your session, and your files should not appear in my responses.

Clawdbot handles this through dmScope, which isolates sessions per channel peer. Each user who DMs your bot gets their own isolated conversation context. Their message history, their memory, their tool outputs stay separate from everyone else.

This isolation extends beyond just chat history. If you configure your bot with access to personal files or credentials, each user session operates independently. One user cannot query another user’s documents or see their conversation threads.

For teams, this creates a useful pattern: multiple people can interact with the same bot instance while maintaining complete privacy from each other. The bot remains a shared resource, but the sessions remain private.

Group Policies vs DM Policies

Understanding the distinction between group and DM policies prevents confusion during configuration. These are separate systems with different purposes.

Group policies control how your bot behaves in shared spaces like Discord servers, Slack workspaces, or Telegram groups. You might want the bot to respond to everyone in a specific channel, or only to users with certain roles, or only when explicitly mentioned.

DM policies control one on one conversations. The pairing, allowlist, open, and disabled modes only apply to direct messages. A user who can interact with your bot in a group does not automatically get DM access, and vice versa.

This separation matters for practical deployments. You might run a bot that answers questions in a public Discord channel while requiring pairing for private DM conversations. Or you might disable DMs entirely while allowing unlimited group interaction. The policies are independent, so you can configure each to match your actual needs.

For deeper understanding of how these policies fit into overall agent safety, the Clawdbot safety principles guide covers the broader security model.

Practical Configuration Steps

Getting DM policies right starts with understanding your threat model. Ask yourself: who should be able to talk to my bot privately, and what damage could an unauthorized user cause?

For personal bots with access to sensitive resources, pairing mode with prompt approval works well. When someone requests access, you evaluate whether to grant it. If you do not recognize them or cannot verify their need, you simply ignore the request.

For team bots, allowlist mode eliminates the pairing overhead while maintaining strict control. Add your team members to the allowlist and know that only those specific users can interact via DM.

For bots with constrained capabilities and public purposes, open mode becomes viable. But constrained is the key word here. If your bot can only answer questions about your public documentation, the risk from strangers is low. If it can send emails or execute commands, open mode is asking for trouble.

For remote access, consider layering network-level controls on top of these policies. Tailscale provides secure mesh networking that ensures only authorized devices can reach your gateway, adding defense in depth beyond DM policies alone.

Beyond DM Policies

Access control through DM policies is just one layer of agent security. Browser automation introduces additional considerations around what websites your agent can access and what actions it can take. External tool integrations expand your agent’s capabilities, which means expanding the potential impact of unauthorized access.

The pattern I recommend: start restrictive and open up deliberately. Pairing mode for DMs, explicit tool grants, constrained browser access. As you understand how your bot gets used and who actually needs access, you can adjust policies accordingly.

Most security problems in AI agents are not sophisticated attacks. They are configuration oversights that leave doors open. A stranger messages your bot, your bot responds helpfully, and suddenly you are dealing with consequences you never anticipated. Proper DM policy configuration prevents the entire category of “someone I did not know could access my bot.”

Understanding these fundamentals prepares you for the broader challenges of building secure autonomous systems where access control intersects with tool use, memory systems, and real world actions.

Sources

Clawdbot official documentation on channel policies and access control configuration.

Anthropic research on AI agent security and access management best practices.

Production deployment patterns from the Clawdbot community Discord and user reports on access control incidents.