Feature request: zero-trust forwarding for Lark/Feishu bot private chats

[Ma233]

Feature request: zero-trust forwarding for Lark/Feishu bot private chats

Note: This may not be the right place to submit this kind of feedback. If there is a better repository, forum, or support channel, please let me know.

Use case

We use one approved Lark/Feishu bot inside the team. Each team member pairs their own backend from inside this bot. The backend runs an AI agent on the member's local machine or cloud environment.

The shared access layer holds the bot identity and credentials, talks to the official Lark/Feishu platform, and routes messages between each team member and their paired backend.

We need this because we do not want every team member to separately create, approve, and maintain their own Lark/Feishu bot.

Security concern

The shared access layer currently sees plaintext private-chat messages. It could technically modify or forge messages.

In our case, those messages may trigger AI agent commands, such as reading project files, editing code, running tests, executing scripts, or calling internal tools. Some AI agents may also run in a high-permission mode similar to yolo. If the proxy is compromised, an attacker could impersonate a team member and send dangerous commands to that member's AI agent.

Request

We want to keep the shared access layer for Lark/Feishu communication and routing, but prevent it from reading, forging, or tampering with the private-chat control channel.

Ideally, the paired backend can verify that messages really came from Lark/Feishu and were not changed by the proxy, for example through end-to-end signing/encryption. Replies from the backend should also be protected, so the proxy cannot forge or modify them.

flowchart LR
    Member[Team member] --> Bot[Lark/Feishu bot]
    Bot --> Proxy[Shared access layer<br/>bot credentials + routing]
    Proxy --> Backend[Member backend<br/>AI agent]
    Backend --> Proxy
    Proxy --> Bot
    Bot --> Member

    Backend --> Env[Codebase / shell / internal tools]
    Risk[Proxy compromise = forged member commands<br/>to the AI agent]
    Risk -.-> Proxy

Loading

[Ma233]

Actually, there may be a simpler approach. Since the backend and the Lark side may belong to the same person, they could configure a shared symmetric key on both sides to encrypt the communication.

[liangshuo-1]

Thanks for the detailed write-up! 🙏

Before we dig into evaluating this, we'd love to understand your use case a bit better. If you don't mind sharing a little more:

• What kind of product or service are you building, and what do your users primarily use it for?
• In what situations do you need to forward a bot's private-chat messages through this "shared access layer"? A concrete example would be really helpful.

Mainly we'd like to get a clearer picture of the scenario, so the evaluation can be more focused. Thanks!

[Ma233]

@liangshuo-1 To better align with the team's communication requirements, I have translated my previous messages in this issue into English. I will continue in English here.

To clarify our use case:

We use one approved Lark/Feishu bot inside the team. Each team member pairs their own backend from inside this bot. The backend runs an AI agent on the member's local machine or cloud environment.

Let's forget the poorly named shared access layer and simply call it a proxy. It holds the bot identity and credentials, talks to the official Lark/Feishu platform, and routes messages between each team member and their paired AI agent backend.

We need this proxy because we do not want every team member to separately create, approve, and maintain their own Lark/Feishu bot.

The security concern is that the proxy currently sees plaintext private-chat messages. It could technically modify or forge messages. In our case, those messages may trigger AI agent commands, such as reading project files, editing code, running tests, executing scripts, or calling internal tools. Some AI agents may also run in a high-permission mode similar to yolo. If the proxy is compromised, an attacker could impersonate a team member and send dangerous commands to that member's AI agent.

What we want is simple: keep the proxy for Lark/Feishu communication and routing, but prevent it from reading, forging, or tampering with the private-chat control channel. Ideally, the paired backend can verify that messages really came from Lark/Feishu and were not changed by the proxy, for example through end-to-end signing/encryption.

A simplified structure is:

flowchart LR
    Member[Team member] --> Bot[Lark/Feishu bot]
    Bot --> Proxy[Proxy<br/>bot credentials + routing]
    Proxy --> Agent[Member backend<br/>AI agent]
    Agent --> Proxy
    Proxy --> Bot
    Bot --> Member

    Agent --> Env[Codebase / shell / internal tools]
    Risk[Proxy compromise = forged member commands<br/>to the AI agent]
    Risk -.-> Proxy

Loading

[Ma233]

@liangshuo-1

If you find key exchange too cumbersome, we can allow users to configure a symmetric encryption key and grant the bot permission that only allows it to subscribe to encrypted user messages.

Further, we can allow users to use this key to decrypt the messages sent back by the bot, so that the message itself cannot be touched by the proxy that transmits the message. Users can configure the key on the devices they need in advance.

[Ma233]

@liangshuo-1

If you find key exchange too cumbersome, we can allow users to configure a symmetric encryption key and give the bot a permission that only allows it to subscribe to encrypted user messages.

Further, we can allow users to use this key to decrypt the messages sent back by the bot, so that the message itself cannot be touched by the proxy that transmits the message. Users can configure the key on the devices they need in advance.

Of course, this is not a good solution, as it cannot prevent malicious proxies from carrying out replay attacks or other similar actions.