AI agent tool policies: sender-scoped permissions for dangerous tools
AI agent tool policies decide which tools an agent can use, for whom, and under what conditions. The important part is not only the tool. It is the requester. OpenClaw 2026.5.12 added per-sender tool policies with canonical channel-scoped sender keys, so operators can restrict dangerous tools by requester identity instead of treating every chat message as equally trusted.
That sounds small until you run an agent across Slack, Telegram, Discord, WebChat, cron, and local CLI sessions. Same agent. Same workspace. Very different trust levels.
Why AI agent tool policies need the sender in the decision
Most early agent setups use a coarse model: this agent has these tools. That is easy to reason about, but it falls apart once the agent becomes reachable from multiple surfaces.
A local CLI turn from the owner is not the same as a Telegram group mention. A cron job authored by the operator is not the same as a Slack thread where a teammate pasted content from the web. A WebChat trial user should not inherit the same tool authority as the person who owns the machine.
OWASP’s AI Agent Security Cheat Sheet gives the baseline: grant agents the minimum tools required for their task, scope permissions per tool, and require explicit authorization for sensitive operations. The sender-scoped version asks one more question before the tool runs: who asked for this action, and through which channel?
That extra identity check matters because prompt injection usually rides through ordinary content. The malicious instruction may be in an email, a webpage, a document, or a copied Slack snippet. If every sender lands in the same permission bucket, one poisoned message can reach tools it never should have been able to touch.
What changed in OpenClaw 2026.5.12
The 2026.5.12 release notes include a direct line under agent tooling: “add per-sender tool policies with canonical channel-scoped sender keys, so operators can restrict dangerous tools by requester identity across global, agent, group, core, bundled, and plugin tool surfaces.”
There are three useful ideas packed into that sentence.
| Release phrase | Practical meaning |
|---|---|
| Per-sender tool policies | The requester can affect whether a tool is available |
| Canonical channel-scoped sender keys | The same-looking person from different channels does not get accidentally merged |
| Across global, agent, group, core, bundled, and plugin tools | The policy boundary applies beyond one narrow tool family |
This is not a magic shield. It is a better place to put the question that operators already have to answer: should this specific requester be allowed to trigger this specific capability?
A simple risk model for dangerous tools
You do not need a huge policy framework on day one. Start by sorting tools by consequence.
| Tool class | Example action | Default stance |
|---|---|---|
| Read-only local context | Search notes, list public docs, inspect status | Allow for trusted users; limit for public surfaces |
| External reads | Fetch a URL, query a SaaS API, read email metadata | Allow with logging; treat returned content as untrusted |
| Local writes | Edit files, update config, write memory | Owner-only or approval-gated |
| External sends | Send email, post to Slack, reply through Telegram | Sender-scoped plus confirmation for new destinations |
| Execution and installs | Run shell commands, install plugins, start browser automation | Owner-only, scoped, and logged |
| Money or credentials | Purchase, rotate secrets, change auth profiles | Human approval every time |
The dangerous category is not always obvious from the tool name. A “search” tool can leak private data if it searches across all memory. A “message” tool can become an exfiltration path if it can send arbitrary content to arbitrary destinations. A plugin install tool is a supply-chain boundary, not a convenience feature.
This is where sender-scoped policy earns its keep. The owner can keep broad maintenance tools available in a local session while a group chat only gets narrow status and reply tools. The agent can still be useful in public or semi-public channels without inheriting the owner’s full machine authority.
Sender-scoped policy beats channel-only policy
Channel-level controls are useful, but they are too blunt by themselves. A private Slack workspace can contain admins, contractors, guests, and bots. A Telegram group can include the owner and dozens of people who should never trigger file writes. Even a DM channel is not always safe if account takeover is part of the threat model.
Sender-scoped policies let you combine both signals:
- The channel tells you the environment: Slack, Telegram, Discord, WebChat, CLI, cron.
- The sender key tells you the requester inside that environment.
- The tool policy decides whether the action is allowed, denied, or approval-gated.
That model also keeps audit trails cleaner. When a tool call is later reviewed, “Slack user U123 in workspace T456 requested file_write” is more useful than “Slack requested file_write.” Security work gets much easier when logs point at the actor, not just the transport.
How this fits with OpenClaw guardrails
OpenClaw already treats self-hosted agents as runtime systems rather than chat widgets. The product has channel bindings, Gateway auth, skills, sandboxing, approvals, and local ownership as separate layers. Sender-scoped tool policies sit in the middle of that stack.
Use what OpenClaw is for the broader architecture, then read how OpenClaw works to see where channels, agents, tools, and the Gateway meet. For security posture, the OpenClaw guardrails guide covers the operator habits around permissions and approvals, while the prompt injection execution boundary explains why tool access is the line attackers try to cross.
One practical pattern is to create a small allowlist for each surface:
- Owner CLI: maintenance tools, config reads, scoped writes, and approved execution.
- Private team channel: status, search, issue creation, and low-risk replies.
- Group chat: answer, summarize, and maybe create draft tasks, but no writes to local files.
- Public or trial WebChat: no local filesystem, no secrets, no outbound sends except the active chat response.
- Cron: only the exact tools needed for the scheduled job, with no inherited interactive permissions.
That last item is easy to miss. Cron feels trusted because the operator wrote the job, but it is still autonomous execution. Treat scheduled jobs as their own sender class, not as a clone of your interactive owner session.
What to check after upgrading
After moving to 2026.5.12 or later, do a short policy audit. Do not make it ceremonial. The point is to catch the tools that would hurt if the wrong sender reached them.
- List the channels where your agent can receive instructions.
- Identify which sender identities are owner, admin, teammate, guest, bot, or public.
- Mark every tool that can write, send, execute, install, spend, or expose private data.
- Make owner-only tools explicit instead of relying on channel privacy.
- Test a denied action from a low-trust sender and confirm it fails closed.
- Review logs for tool calls that still appear under broad or ambiguous sender labels.
Okta’s least-privilege guidance for AI agents makes the same point from an identity angle: agents should be treated as governed identities with scoped access, credential lifecycles, and auditability. Sender-scoped policies extend that thinking to the human or system that delegates a task to the agent.
Common mistakes
The first mistake is giving a channel the same permissions as the owner because the channel feels private. Private is not the same as trusted. People add guests, invite bots, paste hostile content, and lose accounts.
The second mistake is treating read tools as harmless. Read access can still expose secrets, leak private memory, or feed sensitive context into a later outbound message. Scope read tools by path, data class, and requester.
The third mistake is making every blocked tool ask for approval. That sounds safer, but it trains operators to click through prompts. Some actions should be impossible from some senders. Approval is for rare, understandable exceptions, not for turning a group chat into a remote shell with extra buttons.
FAQ
What are AI agent tool policies?
AI agent tool policies are rules that decide which tools an agent may use. Good policies consider the tool, requester, channel, action risk, and approval state instead of granting one flat tool set to the whole agent.
What does sender-scoped mean?
Sender-scoped means the requester’s identity is part of the authorization decision. A local owner session can receive different tool access from a Slack teammate, Telegram group member, cron job, or public WebChat user.
Are sender-scoped policies enough to stop prompt injection?
No. They reduce blast radius. Prompt injection can still influence the agent’s reasoning, but sender-scoped policies make it harder for a low-trust request to reach high-impact tools such as file writes, shell execution, outbound sends, or credential changes.
Should every dangerous action ask for approval?
No. Approval is useful for trusted senders performing unusual actions. Low-trust senders should often be denied outright. Too many approval prompts create alert fatigue and make the system less safe.
Which tools should be owner-only by default?
Start with shell execution, plugin installation, config mutation, credential changes, local file writes outside narrow workspaces, payment actions, and outbound messages to new destinations. Expand only when there is a clear operational need.
Sources: OpenClaw v2026.5.12 release notes, OWASP AI Agent Security Cheat Sheet, OWASP Top 10 for Agentic Applications 2026, Okta on least privilege for AI agents