What Broker Permissions a Trading Bot Actually Needs
A trading bot needs exactly two permissions: read access to see your account, positions, and market data, and trade access to place orders. It never needs withdrawal or money-movement permission, and no legitimate automation asks for it. It also should not need your brokerage password — modern broker APIs issue separate credentials that can be revoked without changing your login. Scoping correctly limits what an attacker can do with a stolen credential, but it does not make one safe: the 3Commas breaches drained accounts using trade-only permissions.
Permissions are the part of a broker integration where the defaults are usually wrong in the permissive direction, because granting everything makes setup work on the first try.
This covers what a bot actually needs, what it never needs, what scoping does and does not protect you from, and how to evaluate a tool that asks for more.
The two permissions a bot needs
Read. Account details, balances, buying power, positions, order history, market data. Everything the software needs to know what state it is in. A monitoring or analytics tool needs only this.
Trade. Submit, modify, and cancel orders. Required for anything that executes. Note that a credential does not need elevated permissions to be used heavily — a client polling account state on a tight loop stresses high-concurrency I/O and the broker's rate tolerance, not its permission scope.
tastytrade expresses these as read and trade scopes selected when an OAuth application and grant are created. Other brokers name them differently, but the split is near-universal because it maps to a real boundary: seeing an account versus acting in it.
Grant only what the software uses. A grant minted without trade will authenticate cleanly, return balances and positions, and reject order submission — which produces one of the most misdiagnosed failures in broker integrations, because everything except the one thing works. The fix is a new grant, not a token refresh. That is an argument for getting scope right at setup, not for granting everything to avoid the problem.
What a bot never needs
Withdrawal or money movement. There is no automated trading function that requires the ability to move funds out of a brokerage account. None. If a tool requests it, that is the end of the evaluation — not a question to ask support about.
Your brokerage password. This one deserves emphasis because it used to be normal. tastytrade retired username-and-password session authentication on December 1, 2025 in favour of OAuth2. If a tool asks for your brokerage login credentials rather than API credentials, it is either built against a retired mechanism or storing your password, and both are disqualifying. API credentials can be revoked independently; a password cannot be revoked without changing it everywhere.
Account settings or profile access. Nothing about executing a strategy requires the ability to change your account configuration.
What scoping actually protects you from
Here is where most security advice stops one step short.
Trade-only scope means a stolen credential cannot transfer money out. That is a real bound and worth having. It is not the same as safe, and the industry has already run the experiment.
In December 2022, roughly 100,000 API keys tied to the 3Commas trading platform were leaked. The accounts were drained — but not by withdrawal, which the keys did not permit. Attackers used trade permissions to execute coordinated market manipulation, buying illiquid assets in compromised accounts against their own positions. The value left the accounts through the market rather than through a transfer. A further wave in December 2024 through January 2025 drained a reported 65 million dollars using stolen keys. Analysis of keys exposed in public repositories found the overwhelming majority carried trade permissions.
The lesson is precise, and it is the one worth internalising: trade-scoped credentials bound the loss, they do not prevent it. A credential that cannot withdraw can still cost you the account balance.
So scope is necessary and insufficient. The other half is storage.
Where credentials live matters as much as what they permit
A refresh token or API secret is a bearer credential. Possession is access. Treat it like a private key rather than a config value.
Not in source. Not in a committed environment file. Not in a container image layer. Not in a log line — authentication errors are precisely the errors people paste into issue trackers and support chats. Environment variables or a secrets manager, and redaction in error output.
Then there is the question of who holds it at all.
On a vendor-hosted platform, connecting a broker means giving your credentials to a company that stores them in their database and trades from their infrastructure. Your credential security is now their credential security, and you inherit their access controls and their breach history. The 3Commas incidents are what that dependency looks like when it fails.
On a self-hosted deployment, the software runs in your own cloud environment and credentials live in that environment's variables. StaxInvesting holds no member API keys or refresh tokens in any vendor database and has no access to running member instances. A vendor breach cannot expose a credential the vendor never held.
The honest counterpart, again: this relocates responsibility rather than eliminating it. You own the environment and the hygiene. A member who commits their own credentials to a public repository has the same outcome by a different route, and there is no vendor to escalate to. It favours operators comfortable running infrastructure, and it is a worse fit for people who want someone else to be responsible.
Revocation is the actual kill switch
Refresh tokens on some brokers carry no documented expiry, which makes them durable credentials. Durable is not permanent — grants can be revoked, and revocation is the intended mechanism for cutting off a compromised client.
Two things follow. Know how to revoke before you need to, because discovering the procedure during an incident is expensive. And understand that revocation only works if you notice, which means credential compromise is a detection problem as much as a prevention one. Unexpected orders, unexplained positions, or activity outside your configured schedule are the signals.
Rotate on a schedule and on every departure, device loss, or suspected exposure.
Evaluating a tool that asks for more
A short checklist for any automation platform:
Does it ask for withdrawal permission? Disqualifying.
Does it ask for your brokerage password? Disqualifying.
Where are credentials stored? If the answer is their database, you are accepting their breach risk. That may be an acceptable trade for convenience; it should be a decision rather than an assumption.
Can you revoke access without their cooperation? If revoking requires filing a support ticket, that is a bad answer.
Does it request scopes it cannot explain? Every permission should map to a function you can name.
What happens to your credentials if you cancel? Worth asking before signing up rather than after.
The honest limits
Correct permissions are a floor, not a guarantee.
Minimal scope, good storage, and prompt revocation reduce the blast radius of a compromise. They do not prevent one, and as the 3Commas incidents showed, a bounded blast radius can still be the whole account.
Nothing here addresses whether the software should be trusted with trade permission on competence grounds rather than security grounds. A perfectly scoped credential attached to badly written automation loses money through entirely legitimate orders.
And permissions do not bound loss. Position sizing does. The divide-by-20 rule is deliberately blunt for that reason: available trading capital divided by twenty as the ceiling on any single position. It is the one control that keeps working when the credential model, the software, or the broker does not.
Frequently asked questions
What permissions does a trading bot need? Read access for account data and market data, and trade access to place orders. Nothing else.
Should a trading bot have withdrawal access? Never. No automated trading function requires it, and a request for it should end the evaluation.
Is trade-only access safe? Safer, not safe. The 3Commas breaches drained accounts using trade permissions alone, through market manipulation rather than transfers. Scope bounds the loss without preventing it.
Does trading software need my brokerage password? No. Modern broker APIs issue separate credentials. tastytrade retired password-based session authentication on December 1, 2025.
Where should API keys be stored? Environment variables or a secrets manager, never in source, committed files, image layers, or logs. On a self-hosted deployment they stay in your own environment rather than a vendor database.
How do I revoke access? By revoking the grant or key at the broker. Learn the procedure before you need it.
Disclaimer: This article is educational content about software engineering and API integration. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security. Any instruments named are used solely to illustrate mechanics. Options trading involves substantial risk of loss and is not suitable for all investors. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading systems carry additional risks including software defects, order construction errors, credential compromise, network and connectivity failures, broker API changes, rate limiting, access restrictions, and outages that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no configuration, order type, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.
StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, their compliance with third-party API terms of service, and every trade executed in their account. Third-party API details described here reflect publicly available documentation as of publication and are subject to change by the vendor without notice; always verify against current official documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.