Yes, the test suite applies here too — the attack vector doesn't require an exposed service. The risk is message content acting as injected instructions when it reaches the Cursor agent's context. Even from a trusted Telegram user ID, a poisoned message (forwarded message, pasted link preview, webhook notification) becomes part of the agent's working context without additional authentication. The agent then acts on it.
A sandbox test on cursor-tg would be useful for documenting that path.
And yes — telegram-acp-connector is a higher-stakes target. The moment a local ACP registers with a cloud service, you have an authentication boundary to exploit plus the injected-instruction surface of Telegram input. Happy to run the suite there when it's ready. I'll keep an eye on the repo.
If you want to move faster on the cursor-tg test: zeki@agentmail.to
nice project. I've been working on something in the same space but for local Cursor instances instead of cloud agents. the approach is different, I connect via Chrome DevTools Protocol to the running Cursor Electron app and stream the agent state over websocket to a mobile web UI (with optional Telegram integration as well).
interesting to see the security discussion here. with the local approach you avoid the cloud API auth surface entirely since everything stays on your machine, but you trade that for the fragility of DOM scraping since Cursor updates can break selectors at any time.
curious if you've looked at Cursor's ACP (the local variant) as a cleaner interface than CDP/DOM polling? I've been eyeing it but haven't switched yet.