What Happens to Your Brokerage Credentials: API Key Scoping, Storage, and Verification

Every discussion of trading software security eventually reduces to a single object: the API credential that connects the tool to your brokerage account. What that credential is permitted to do is the entire boundary between a piece of software and your money. Architecture diagrams, security pages, and vendor assurances are all commentary on that one question.

This is an operational manual for managing that credential — how permissions work, which ones to grant, where keys should and should not live, how to check what access exists on your account right now, and what to do in the first sixty seconds if something looks wrong. It applies to any trading tool you connect to any brokerage, including this one.

What the Credential Actually Is

An API credential is normally a pair: a key that identifies the account it acts for, and a secret used to cryptographically sign each request. Together they let a program act on your behalf without a human logging in.

That last property is the source of the risk. A browser login is interactive, session-bound, and typically protected by two-factor authentication. API access is continuous and automatic by design — it works at three in the morning, it works without anyone present, and it does not prompt for a second factor. If the credential leaks through a code repository, a debug log, a screenshot, or a compromised third party, an attacker can begin acting on your account within seconds, and nothing about the request looks unusual to the broker. It is a valid credential doing what valid credentials do.

The Permission Taxonomy

Terminology differs across brokers and exchanges, but permissions map onto three consistent risk tiers.

Read access allows viewing balances, positions, order history, and market data. It cannot change anything. This is the correct scope for portfolio trackers, analytics dashboards, and tax tools — anything that observes without acting. Lowest risk, though it is still account data and worth protecting.

Trade access allows placing, modifying, and cancelling orders. This is the minimum required for any execution automation, and it is the scope a trading bot legitimately needs. Medium risk, and the section below explains why medium is not the same as low.

Withdrawal or transfer access allows moving funds out of the account. This is what separates a bad day from an unrecoverable one, and no trading tool has any legitimate need for it.

The governing principle is least privilege: grant the narrowest permission set that allows the tool to function, and nothing beyond it. A tool that only needs to place orders should be unable to do anything else.

Why Withdrawal Permission Should Never Be Granted

This deserves to be stated without qualification: no trading tool should ever hold withdrawal or transfer permission on your account, for any reason, under any explanation offered.

The reasoning is arithmetic rather than ideological. With withdrawal disabled, the worst outcome from a compromised credential is unauthorized trading — damaging, but bounded by your account's liquidity and partially mitigable through loss limits and manual intervention. With withdrawal enabled, the worst outcome is an emptied account in seconds, with no recovery path and no meaningful recourse.

This is not theoretical. Attackers exploiting stolen exchange API keys drained more than $65 million through unauthorized trades and withdrawals between December 2024 and January 2025. In January 2026, researchers documented a malicious browser extension posing as a legitimate connection tool for a major exchange: it injected a script into the user's already-authenticated session on the exchange's own API management page and generated keys carrying both trading and withdrawal permissions, giving the attacker the ability to execute trades and drain balances from any account accessed through that browser.

The specific thing to watch for is permission creep — a tool requesting elevated access with a plausible-sounding justification. One documented example involved a platform requesting withdrawal permission to support a rebalancing feature. Rebalancing does not require moving money off the platform. Any request for withdrawal access, however it is framed, is a reason to stop and reconsider the tool entirely.

The Uncomfortable Part: Trade-Only Is Bounded, Not Safe

Most security guidance in this category stops at disable withdrawals and implies the problem is solved. It is not, and the gap matters enough to be specific about.

In December 2022, the automated trading platform 3Commas confirmed that roughly 100,000 users' API keys, secrets, and passphrases had been disclosed by a third party. Attackers proceeded to drain accounts — and they did it without withdrawal permission, through market manipulation. The mechanism is straightforward once you see it: an attacker with trade access on your account and their own orders on the other side can make your account buy an illiquid asset at an absurd price, or sell one far below value. Your balance transfers to them through the trades themselves. No withdrawal is required, because the money leaves as a series of terrible fills.

Security researchers investigating credentials exposed in public code repositories found accounts collectively worth over a million dollars, with more than 90 percent of the exposed keys carrying trade permissions — sufficient, on its own, to empty them.

Two honest qualifications for readers trading equities and listed options rather than crypto. First, this attack depends heavily on illiquidity: the manipulation works because the attacker can control both sides of a thin market. Deep, liquid instruments — major index options, large-cap equities — are far more resistant, because an attacker cannot cheaply position themselves opposite your order flow. Second, resistant is not immune. Illiquid strikes and wide-spread contracts exist in every options chain, and an attacker choosing the venue for the attack will choose the thinnest one available.

The correct conclusion is not that trade-only scoping is pointless. It converts an unrecoverable catastrophe into a bounded, partially defensible problem, and that is an enormous improvement. The conclusion is that scoping alone is the floor rather than the ceiling, and everything that follows is what closes the remaining gap.

The Credential Lifecycle

Create. Generate a separate credential for every tool. Never reuse one key across multiple services — shared credentials mean a compromise anywhere is a compromise everywhere, and they make it impossible to determine which integration leaked. A dedicated key per tool also means you can revoke one without disrupting the others.

Scope. Enable trading. Explicitly deny withdrawal and internal transfer. Grant read access only where a tool genuinely requires it. Read the permission descriptions your broker provides rather than assuming the defaults are conservative — they are not always.

Test before trusting. Most brokers offer paper or demo environments with their own separate credentials. Connect any new tool to one of those first and confirm it behaves as you expect — that it places the orders you anticipate, respects the limits you configured, and does nothing you did not authorize — before generating a credential against the account holding real money. A tool that misbehaves in a demo environment has told you something valuable at no cost. This sequencing also means your live credential is created later, exists for less time, and has been exposed to fewer configuration mistakes along the way.

Store. A credential is only as protected as the least careful place it has ever been written down. It should never appear in source control, a browser extension, a chat message, a support ticket, an email, a screenshot, or a spreadsheet. It belongs in environment variables or a dedicated secret manager on the machine that uses it, and it should never be written to application logs — logging frameworks capture far more context than people expect.

Where a tool stores your key on its side is a question worth asking directly, and it is where architecture matters most. Platforms that hold user credentials in a central database concentrate risk: one intrusion exposes every user at once, which is precisely what the 3Commas incident demonstrated at hundred-thousand-user scale. A model where the credential lives only in infrastructure you control has a blast radius of one account — yours — because there is no central store to breach. That structural difference is the strongest practical argument for self-hosted architecture, and it is an argument from incident history rather than from principle.

Restrict by address. Where your broker supports IP allowlisting, use it. Binding a credential to the specific server that legitimately uses it means a leaked key is inert from anywhere else — an attacker with your key and secret still cannot authenticate from their own infrastructure. After correct scoping, this is the single highest-value control available, and it is frequently skipped because it takes ten extra minutes.

Monitor. Enable your broker's account activity notifications. Periodically review API access logs where they are offered. The signals worth watching for are trades you did not authorize, order activity outside your configured trading hours, unfamiliar instruments, and access from unexpected addresses. API abuse is quieter than a login-based intrusion precisely because it does not trigger the alerts a suspicious login would.

Rotate. Replace credentials periodically, and always after any of the following: a suspected exposure, a security incident at any platform you have connected, a change in who has access to your systems, or the decommissioning of a tool. Rotation limits how long a quietly leaked credential remains useful. Generate the replacement, update the tool, confirm operation, then delete the old key — in that order, to avoid downtime while positions are live.

Revoke. Deletion is immediate and unilateral. You do not need the vendor's cooperation or knowledge, and no legitimate tool can prevent it. Know where this control lives in your broker's interface before you need it, because you will want it at a moment when you are not calm.

The Revocation Drill

If you suspect a credential has been compromised, sequence matters more than diagnosis. Work in this order.

One: revoke the key immediately. Not after investigating, not after confirming — first. This is the action that stops further activity, and every minute spent establishing what happened is a minute an attacker still has access.

Two: cancel all open orders. Revoking a credential does not cancel orders already resting at the broker. Anything an attacker placed remains live and can still execute.

Three: review and address open positions. Determine what you actually hold versus what you expected, and close anything unauthorized.

Four: check account activity and any transfer history. Confirm whether funds moved and whether any withdrawal or bank instruction was created.

Five: secure the account itself. Change your brokerage password and verify your two-factor settings, in case the compromise extends beyond the API credential.

Six: audit every other connected credential. If one key was exposed through a shared machine or a compromised service, others may be as well.

Seven: notify your broker. They can advise on recourse, flag the account, and may have logs you cannot see.

Eight: only now, determine how it happened. Diagnosis is important, and it is worthless performed while access remains open.

How to Verify Access Scope on Any Platform

This takes a few minutes and should be repeated quarterly. Critically, it happens inside your broker's interface, not on any vendor's website — a vendor's description of what it requests is not evidence of what your account actually granted.

Open your broker's API management section. Review the list of active credentials and confirm you recognize every one — orphaned keys from tools you abandoned are a common and unnecessary exposure. For each key that remains, check the permissions attached and confirm that withdrawal and transfer are not among them. Check whether IP restrictions are configured and whether they still match the infrastructure actually using the key. Look at creation dates and last-used timestamps where available; a key that has not been used in months is a key that should be deleted. Then delete everything you do not recognize or no longer need.

Anything unexpected — a permission you did not grant, a key you did not create, activity from an unfamiliar address — should trigger the revocation drill above rather than further investigation.

Red Flags in How a Tool Asks

How a platform requests access tells you a great deal before you have evaluated anything else.

A tool that asks for your brokerage username and password rather than an API credential is requesting full account access, including anything your broker's web interface can do. There is no scoping, no restriction, and no clean revocation short of a password change. This is disqualifying.

A tool that requests withdrawal or transfer permission, regardless of the feature it claims to need it for, is disqualifying.

A tool that requires you to enter credentials into a browser extension deserves particular suspicion given the documented attack pattern of extensions operating inside authenticated exchange sessions to generate over-permissioned keys.

A tool that will not explain what permissions it needs, or that stores your credentials centrally without describing how they are encrypted and isolated, has not earned the access. A tool that asks you to send a key through chat, email, or a support ticket is demonstrating that it does not take credential handling seriously anywhere in its organization.

How This Applies Here

Measured against the manual above: StaxInvesting connects using a trade-scoped credential that you generate inside your own brokerage account. It never requests withdrawal or transfer permission, because the software has no function that requires moving money. The credential is stored in the instance running in your own cloud environment rather than in a central vendor database, which means there is no aggregated credential store for an intrusion to reach — the 3Commas failure mode structurally does not apply. You can revoke access unilaterally, from your broker, at any time, without notifying anyone.

And the honest residual, consistent with the rest of this page: a trade-scoped credential is bounded, not harmless. Everything in the lifecycle section — separate keys, IP allowlisting, careful storage, monitoring, rotation — is work that remains yours regardless of which platform you use. A vendor can design so that it never needs dangerous permissions. It cannot manage your credential hygiene for you.

Related reading: the security model in depth covers the custodial versus non-custodial distinction and how to evaluate any tool's access, the self-hosted model explained covers what runs where and what fails when components go down, and the legitimacy page addresses the harder objections directly.

The Bottom Line

Grant trading permission. Never grant withdrawal permission, to any tool, under any justification. Use a separate credential per integration, restrict it by IP address where possible, store it somewhere that is never logged or committed, rotate it periodically, and know where the revocation control lives before you need it.

And hold the accurate mental model rather than the comfortable one: disabling withdrawals converts a total loss into a bounded loss. It does not make a leaked credential harmless, because trade permission alone has been sufficient to empty accounts through manipulation. The credential is the boundary. Everything else — every architecture diagram, every security page, this one included — is a description of how carefully that boundary is drawn.

Past performance does not guarantee future results, and nothing here is financial, legal, or security advice. This article describes general credential management practices; specific permission names, capabilities, and controls vary by broker and change over time, so verify all settings directly with your broker and consult their documentation. Security practices reduce risk but do not eliminate it, and no configuration guarantees an account cannot be compromised. Incidents described are summarized from public reporting and are included to illustrate risk categories. Options trading involves substantial risk of loss and is not suitable for all investors; no software, permission scope, or security control prevents trading losses. StaxInvesting provides self-hosted trading software — not signals, financial advice, or a managed account — that runs on the member's own connected brokerage; StaxInvesting never accesses member funds, credentials, or trades. Details reflect information available as of July 2026.