The strongest control in the product is the one that removes a category of risk rather than defending against it. Scalegram stores no message content. Not encrypted, not archived, not retained for a window. There is no transcript table, so there is nothing in it to leak, subpoena or hand over. The reasoning and the cost of that choice are set out in the no-message-storage article, and the short version is that the surface area of a worst case is a contact list rather than a conversation archive.
Everything below is the second line, for the data that does exist: contacts, stages, tags, notes, integration credentials and the events the system confirmed.
Getting in
Sign-in uses a one-time code sent to the account's email address rather than a password the operator chose and reused. The reasoning is unremarkable and well established: a stolen password from an unrelated breach is the most common way a small business account is taken over, and a credential that does not exist cannot be reused. There is no password to phish out of somebody either, only a short lived code tied to one attempt.
The trade is that the email account becomes the key, which is worth saying out loud rather than pretending otherwise. Protect that mailbox at least as well as you would have protected the password. Give that mailbox its own strong second factor and treat it as part of your security perimeter.
Sessions expire, and a session that has gone stale is refused rather than half honoured. A tool that quietly accepts an old cookie for read-only work is a tool with two definitions of logged in, and only one of them is written down.
Who can do what once they are in
Access inside a workspace is not all or nothing. Permissions are granted per area at read, add, write and delete level, so a new starter can be given the contact list without the ability to delete records or touch integration settings. That is a security control as much as an organisational one, since most damage in a small team is done by someone with more access than their job needed. The setup is in team permissions.
What the application refuses to trust
The browser side runs under a strict content policy, which is the control that decides what code is allowed to execute on a page. Scripts are permitted only when they carry a value the server issued for that specific page load, so injected script does not run even if it finds its way into the markup. It is a blunt instrument and that is the appeal.
Writes are checked for where they came from. A request that changes something has to originate from an allowed origin, which is what stops another site from riding a logged-in session in a visitor's browser to make changes on their behalf. There is a maintenance cost: every new endpoint has to be registered deliberately, and forgetting is a visible failure rather than a silent hole, which is the correct way round.
Request bodies are capped. An endpoint that accepts an unbounded payload is an endpoint someone will eventually use to make the server do expensive work for free, so limits exist on every route regardless of how unlikely a large body seems.
Payment and integration secrets are write-only once saved. They can be replaced but never read back out of the interface, which means a compromised session cannot be used to harvest the keys to your other systems.
Inbound notifications, which are the soft underbelly
Anything that reaches the system from outside gets treated as hostile until proved otherwise. Payment notifications and platform callbacks are verified against the sending system's signature, and a repeat of a message that was already processed is refused rather than acted on twice. Replaying a valid old payment notification is a genuinely popular attack because it is cheap and the payoff is a free grant of access.
The processing side is written so that a message received twice produces one result, which matters for correctness as much as for security. How that is handled is described in webhook reliability.
The assistant as an attack surface
A bot answering the public is probed constantly by people trying to extract its instructions, a key, or another customer's details. The defence is applied on the way out rather than relying on the model to refuse: the outgoing message is inspected before it reaches Telegram and anything belonging to the system or to another contact is removed. The threat model is written up in what a customer can never extract.
The other half is authority. Bots are blocked from making promises the business cannot keep, and anything that grants access or costs money stops for a human yes. A model that can be talked into a grant is a security problem no matter how well the data is stored.
What this does not cover
Being straight about the edges is part of the posture. Not storing messages does not make your Telegram private from Telegram, and it does not stop a client screenshotting a chat. A teammate with legitimate access can see a contact's name, stage and purchase history, which is why permissions exist and why offboarding matters. Compliance obligations remain the operating firm's own: SINGUARD sells software and is not your data controller of last resort, your broker, your bank or your adviser.
And no security posture is a statement about outcomes. Trading carries a high risk of loss, signals and copied trades are information and tooling rather than financial advice, and nothing in this product promises a result. The same principles run through the sister product at copysignals.io, which handles trading credentials and therefore inherits every rule above with the volume turned up.
"Half of security is engineering and half is refusing to hold things. The parts of Scalegram I worry least about are the parts where there is simply nothing stored."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- No message content is stored anywhere, so the worst case of a breach is a contact list rather than an archive of conversations.
- Sign-in uses an emailed one-time code instead of a password, which makes the mailbox the key and worth protecting accordingly.
- A strict content policy, origin checks on every write, capped request bodies and write-only integration secrets limit what a compromised session can do.
- Inbound payment and platform notifications are signature checked and refused on replay, so an old valid message cannot be used twice.
Frequently Asked Questions
Where are my Telegram conversations stored?
They are not. Scalegram keeps contacts, stages, tags, notes and timing, and links out to the real chat in your own Telegram app. There is no transcript table, so there is no archive to protect or hand over.
Why is there no password on my account?
Sign-in uses a short lived code emailed to the account address. A password that does not exist cannot be reused from an unrelated breach or phished. The trade is that your mailbox becomes the key, so it should carry its own strong second factor.
Can I read back an API key I saved earlier?
No. Integration and payment secrets can be replaced but never displayed again after saving, so a compromised session cannot be used to collect the credentials for your other systems.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.