Please read my blog post about how bot communications work to get an understanding of the request-response process. As it explains, although the response looks kind of "synchronous" from the bot, it's actually not and is sent via a reply to the Bot Framework services itself. In order to do this, your bot code (dotnet, node, whatever) actually needs TWO things - the app id AND the app password, in order to authenticate itself internally. Without these, no-one can run another bot on your behalf, even on that same id. Note that this is a 'regular' bot scenario, and does NOT require the user to actually Sign In to the bot in any way (that is only required if you want to, for example, access resources on the Graph on the user's behalf, like to fetch a file from SharePoint Online).

Separately, but perhaps related, if someone DID have your app id, they could possibly register an app that would result in more messages coming TO your bot (a kind of "DOS" attack, if you like), but that still wouldn't enable them to 'act as' your bot, as mentioned above. [Update: Note that your bot would still end up responding to these messages, as it wouldn't know it wasn't your own Teams app. I'd struggle to understand why someone might want to do that though. No one would be able to develop and host a bot that impersonated your bot, however - they would need (a) you app password and (b) to change the registered endpoint where you host your bot, in the Bot Framework].

So, albeit that the App Id alone is not enough, you should of course try to protect it (e.g. KayVault), and all the more so with the app password.

On a separate note, it is also possible to restrict your bot to only being used from a single (or restricted set of) tenants. Please see my answer at MS Teams app manifest file Tenant restriction.