[Bug] CowAgent have risk leaking user's privacy and executing destruction commands on user's computer

[EvanProgramming]

Self check

• I'm on the latest version and searched existing issues (incl. closed) — no duplicate.

Environment

Version: Newest Version
Platform: macOS 26.4
Form: Desktop App
Model: Deepseek / Claude Opus ... This applies for any models.

What happened?

1. Invite the CowAgent bot to Feishu(Lark).
2. use"@" to call the bot, and let it find something in the group or some tasks that needs to use local files.
3. Your data will expose.

---

Another Condition

1. Invite the CowAgent bot to Feishu(Lark).
2. use"@" to call the bot, and let it find something in the group or some tasks that needs to use local files. Or executing some commands that allows attacks from attackers.
3. The bot may do that.

What is expected: CowAgent should disagree and don't expose any private data and files to others in the group, unless the owner user asked it to.
What happened: CowAgent directly find documents on my computer and sent them in the group.

• I will fix this issue.

Logs

缺口
说明
❌ 无提示词攻击防护专业规则
没有「识别伪装系统/管理员/授权任意操作」这类注入面的明确防御策略
❌ 无全局覆盖
原铁律只在单个群有效，其他群/渠道是裸奔的
❌ 无「攻击面」防范清单
没明确列出「凡涉及运行命令/读文件/调API/发消息/透露信息都要先核实来源」
❌ 无敏感信息「永不披露」红线
只有模糊的「别泄露密钥」

[EvanProgramming]

Fix PR #2999 has been submitted. The core approach implements actual capability gating at the BaseTool.execute_tool level (the unified entry point for all tools, including MCP): unrecognized senders in group chats are classified as GUESTS and restricted to conversational tools only; file system tools are confined to the workspace; and unknown or MCP tools are denied by default. Additionally, irreversible commands require confirmation, and key files are restricted from being read by anyone. Owners and existing standalone deployments remain unaffected (fail-open behavior), and the system can fully revert to the previous state by setting security_enabled=false. Please refer to the PR for details.

[EvanProgramming]

If needed, I can also implement the features mentioned by Correctover bot

[forevercrab321-svg]

PR 说明里 "unrecognized senders → GUEST" 和 "fail-open" 是并排写的，那要看「认不出来」是哪一种。

一种是解析成功、身份不是 owner —— 这种后面接着 GUEST，闸门是关的。
另一种是解析这一步本身没成：转发过来的消息、没带 user id 的回调、重放的 webhook。这时候拿到的不是「陌生人」，是空。空落到哪一档？

我们自己刚栽在这个形状上：一个查询接口返回 HTTP 200，body 里装的是一张 HTML 错误页。调用方按 JSON 解，解出来是空，于是「没查到」变成了一个看起来合法的答案。它没报错，它只是不干活了。

所以建议回归测试除了断言「群成员拿不到 owner 的文件」，再钉一条：sender 解析失败时走哪条分支，以及这次拒绝有没有留下带原因的记录。 一个拦住了人的闸门，和一个没人来闯的闸门，日志里长得一模一样。

想问一句：现在这版里，「解析不出 sender」和「解析出一个非 owner 的 sender」，是同一条分支吗？

[forevercrab321-svg]

拆成两条分支之后,还有一层要跟着拆:返回给调用方的那一层。

日志里分 STRUCTURE_ERROR 和 IDENTITY_MISMATCH 是给人看的。上游拿到的如果还是同一个状态码、同一个错误对象,那对机器来说这两件事仍然是一件事 —— 而会自动重试、自动降级、自动放行的是机器,不是读日志的人。

我们自己前两天刚在这上面栽过一次,方向还是反的:报告头条已经改成"证据不足,不发等级"了,API 那边照样返回 grade: "A"、composite: 96.6。我们文档里那行 CI 示例 assert composite >= 75,就这么绿着过去了。人看到的是诚实,流水线看到的是旧答案。

你那四条回归测试,第 3 条建议再钉死一点:断言"这个请求被拒了"是不够的,调用链在更前面崩掉,测试一样绿。要断言的是它是因为 missing_identity 被拒的。

想问一句:CCS 里 Case A 和 Case B,在返回给调用方的那一层是不是也分得开?还是只在日志里分得开?

[EvanProgramming]

Thanks @forevercrab321-svg and @Correctover — this is exactly the failure mode I wanted caught, and you're right that the original PR collapsed two different faults into one branch. I've pushed a fix (commit on PR #2999) that separates them at the root.

Case A vs Case B, now distinct

The hole was precise: "could not resolve the sender" and "resolved a non-owner sender" both fell through to GUEST (usable), and on a private channel with no owner list, an unattributable request even slipped through to OWNER. Resolution errors also fell back to GUEST. So a forwarded message, a callback missing the user id, or a replayed webhook was treated as a usable guest.

What changed:

• Authoritative identity is actual_user_id (the human). In a group, from_user_id is the group id, not a person, and is never used as a human identity. So a group message whose actual_user_id is missing is no longer mistaken for "known" just because the group id is present.
• A channel request with no identifiable sender → UNTRUSTED + identity_status="unidentified", fail-closed. Every tool is refused, including conversational ones like web_search.
• Resolution errors also fail closed to UNTRUSTED (was GUEST).
• Local / no-context runs stay OWNER (identity_status="local") — that is the legitimate fail-open, because there is genuinely no requester.

The return-to-caller layer is also split (your second point)

You're correct that differentiating only in the log is not enough — the machine that auto-retries / auto-degrades / auto-escalates sees one error otherwise. So the denial now carries a structured code, not just prose:

• the Decision.category is identity.missing for Case A, vs capability.not_allowlisted for a real stranger — different strings;
• the returned ToolResult.ext_data carries security_denial_category and security_identity_status, so a caller can branch without parsing the message;
• the audit JSONL records identity_status, so unidentified and identified denials are separable in monitoring.

Tests assert the specific reason, not just "denied"

tests/test_security_group_access.py::TestMissingIdentity pins down:

• an empty-identity group message is UNTRUSTED even though a group id is present;
• it is denied with category == "identity.missing" (not merely "denied");
• identity.missing ≠ capability.not_allowlisted;
• a known stranger is still GUEST and can converse;
• a resolution exception → UNTRUSTED;
• local invocations are unaffected.

On the CCS framing: I agree the dimension (structure vs identity) should map to distinct machine-actionable codes rather than only distinct log strings, and that's what identity.missing / capability.not_allowlisted + the ext_data codes now provide within CowAgent's tool contract. I haven't adopted the JSON-RPC -320xx codes since CowAgent's tool result isn't JSON-RPC, but the same principle holds: the code is in ext_data, not buried in text.

Regression: the 56 pre-existing security tests still pass, and the command analyzer stays at zero false positives on everyday commands.

[forevercrab321-svg]

The Case A guard is conditioned on a field from the same payload it distrusts.

_resolve reads is_group = bool(context.get("isgroup", False)) once, and every defence after that is downstream of it. Take a group message where isgroup is absent or false-y — a replayed webhook, a forwarded payload, an adapter that never set it — on a deployment with no security_owner_users and no admin_users, which is the default:

• user_id = actual or (from_id if not is_group else "") → actual_user_id is missing, is_group is now False, so it borrows from_user_id. On a group message that is the group id — the exact identity the comment above that line says must never be borrowed. The clause that prevents it is if not is_group.
• _identify matches nothing, no lists are configured.
• is_channel and not user_id → user_id is not empty any more. It holds the group id. The fail-closed branch is skipped.
• not is_group, not a local channel, owners or trusted is empty →

trust=OWNER, identity_status="identified",
reason="private chat, no owner list configured (single-user deployment)"

Which is the sentence from your own write-up: "on a private channel with no owner list, an unattributable request even slipped through to OWNER." It still gets there. It just goes through isgroup instead of through actual_user_id. And it arrives labelled identified, so the monitoring split that came out of this thread reports nothing — there is no identity.missing record to count.

We shipped the same shape and it took three occurrences to see it. Our automation measured a page's coordinates, then clicked them. Between the measure and the click the viewport resized itself, 1489×812 → 1533×784, so the click landed below the target box and document.activeElement was a placeholder SPAN — focus never entered the editor at all. Our own rules file had that page recorded as coordinate-stable, so the guard we were running was aimed at a hazard that was not the one present. Twice we blamed the editor. The check was correct. It was just reading a fact that something else was allowed to change underneath it.

The question I cannot answer from outside your adapters: can group-ness be derived from the bot's own state — the room or session it knows it joined — rather than from a field on the inbound message? If any channel can tell you "this session is a group" without asking the payload, then is_group becomes something the sender cannot flip, and both branches close with one change instead of two.

Small separate thing, since it documents the exact property this thread produced: the UNTRUSTED docstring in trust.py reads "so it is indistinguishable in logs/metrics from a real stranger's capability.not_allowlisted refusal." The inline comment in _resolve says distinguishable, and distinguishable is what the tests pin. The docstring is the copy a future reader is most likely to implement against.