Where an open source Telegram agent keeps company logins

The bot token is not the company login

A weekend covers the easy part. A bot answers in a Telegram chat and calls a CRM, a repository and a ticket queue. What takes longer to settle is which process holds the bot token, and which holds the logins the bot uses. Get that wrong, and the friendliest chat in the company becomes the shortest path into every system behind it.

Kortix keeps the two apart. The token comes from @BotFather, gets pasted into Project admin → Connectors under the Channels scope, and stays on the Kortix server. The CRM login is a connector account: connected once, governed by the project, and called on the agent’s behalf. Connector credentials are brokered server-side and never enter the machine. The chat carries a message from a person; the agent asks the server for the call.

One grant per agent, in a file you can read

Access narrows at the agent, not at the bot. In the starter kortix.yaml one agent named worker carries five grants: tools: all, skills: all, connectors: all, secrets: all and kortix_permissions: all. Every one of them shortens to a list of names.

So connectors: all is a grant written on that one agent, not a setting the project hands out. An agent whose block lists a CRM and a repository calls those two. An agent whose block lists none calls nothing, however many connectors the project has connected.

The catalog behind those grants is broad: 3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP. Who may run the agent is a separate question. Per-resource permissions for people and agents. Roles, groups, and an audit trail.

The practical shape is one agent per job. A support agent holds the ticket queue and the order system. An engineering agent holds the repository and the deploy target. The bot in the chat only carries messages between a person and whichever agent the chat runs, and /agent switches that without touching either grant.

What reaches the machine, and what stays behind

A session runs on its own isolated cloud computer, and the connector call happens outside it. The CRM token is not in the session's environment, so a command the agent runs cannot print it and a file it writes cannot contain it.

Files travel the other way. Photos, documents, voice notes and videos a person sends arrive in the session, and Kortix copies up to 8 MB of files per message into the session’s workspace. The agent reads them there, which is where a support ticket export or a screenshot of a broken page belongs.

A secret is a different object from a connector account. A secret granted to an agent is a real environment value in its session, readable by anything the agent runs there. Keep a long-lived company login in a connector account, which is brokered. Use a secret only for the value the agent must compute with itself.

What a Telegram message can and cannot do

Telegram has no account link, so the bot works from a list. The allowed-user list decides who may talk to the bot. A message from a listed person starts a session. Anyone else gets a reply showing their own Telegram user ID, and when the stranger writes in a private chat they also appear under Allowed users → Wants access, where a project manager allows them with one click. In a group, only commands, replies to it and mentions reach the bot.

One chat is one session, and in a forum group each topic is its own. A chat’s agent writes only in that chat and its topics, and a connector call takes only the arguments its action lists. A session started from the web app or an automation can send to any chat of the bot. One started in this chat cannot post anywhere else.

The chat also cannot hide its work from the room. In a group, the reply is visible to every member, including people who are not on the allowed list. A reply can show the project name, model names and a link to the session. Only that link checks who may open it.

In a direct chat with the bot, everything else a person types reaches the agent, including a message that starts with a slash and belongs to another bot. Kortix keeps 11 verbs of its own, among them status, stop, model and agent. They run in Kortix, outside the agent. When the agent needs a decision, the question arrives as buttons and the answer comes back to it in one go.

A call that touches company data should not depend on a person noticing a message. Approval gates you set. Off until you set them.

Two shortcuts that break credential custody

Two shortcuts undo the rest. The first is one bot for the whole company, with every colleague on its allowed list, when the work belongs to one team. The second is one company login pasted into every agent and every workflow. That puts the same key in the busiest chat, the quietest automation and every agent in between.

Neither is a Telegram problem. Both come from treating a grant as a convenience instead of a decision. The alternative is small and readable. The connector sits on the agent whose job needs it. A connector rule set to Ask holds the call. A change the agent makes to the project waits on the Review page until a person merges it. The open source Telegram agent page lists what to inspect in the file before a bot goes live.