September 30, 2026 • 4 min read

How Arkis Governs Operator Access

Part of a series on how Arkis approaches risk.

The previous piece described how we extend the Arkis risk boundary onto centralized exchanges. We hold a master account at each venue, borrowers trade through sub-accounts beneath it, and off-exchange settlement leaves client assets with a custodian instead of the exchange. Between them, those two mechanisms settle what happens to a position and what happens to the assets behind it.

Some of the work at those venues is done by hand, by our operators. They open master accounts and the sub-accounts beneath them, issue and rotate the API keys our trading systems run on, maintain transfer whitelists and withdrawal addresses, and intervene during a liquidation if an automated route degrades. Each of those actions moves capital or changes what an account is permitted to do.

An exchange account is a single identity with a single set of permissions, and it carries none of the monitoring, alerting or transparency logging an enterprise system would provide. Credentials are shared across a team, and the operational cost of that arrangement falls on Arkis rather than on the venue.

When an employee leaves the company, there is no individual account to close, so every credential that person used has to be rotated at every venue. When a credential is compromised, the investigation is slow, because the venue records the account rather than the person: its logs cannot show who used the credential, at what time, or which of the recorded actions belonged to an attacker rather than to a colleague. The same arrangement offers no protection against a password observed over someone's shoulder, or a session opened from a network we do not control.

We set out to reduce those risks. All of this work happens in a browser, on the exchange's own interface, so the browser is the one place every operator passes through whatever venue they are working on. That led us to enterprise browsers, which the company administers rather than the person using them.


arkis-island-schema.png


The Island Enterprise Browser sits between our operators and the venues they work in. Our traders open the same dashboards they always did, and the controls run underneath, deciding who reaches which venue, what they can do once they are there, and what is recorded while they do it.

How the access is provisioned

The Island Enterprise Browser carries the controls we were looking for to protect access to the exchanges: session protection, a secure password manager, control over what a user can do and what the page renders, security policy per venue, and granular monitoring.

Secure Password Manager

With Island Browser Arkis operators never handle the passwords - the browser submits a placeholder token at login and swaps it for the real credential at the network layer, in the moment before it reaches the exchange, so the password never renders on the page and cannot be replayed anywhere outside the Island.io runtime.

That also changes what we do when an Arkis employee departs. Rotating venue passwords stays part of normal practice, but it no longer has to happen the moment someone joins or leaves. We withdraw their access to the browser instead, and the shared venue account is reachable only through Island.io. Access expires on a schedule we set, and an attempt to use a credential outside the approved path is restricted and raises an alert.

Fine-grained Access Control

An Arkis operator holds only the credentials their job requires. We grant access one venue at a time, and each venue has its own policy describing how we use it. The Arkis security team pins every operator to a trusted perimeter by IP address and device fingerprint, so a session opened from an unfamiliar machine or location will not connect. Every session is encrypted, developer tools are blocked, and session memory is protected.

Within each session, what can leave the page is governed by the policy as well. Copying, downloading, uploading and screen capture are permitted or blocked according to what is being moved, which keeps account configuration, API keys and position data inside the venue interface.

Because the browser renders the page, Island.io can change what is on it. Withdrawal address books, security settings and the other pages that govern an account's own safety are stripped out for operators whose role does not cover them.

Alerts and Advanced Monitoring

Given that access to venue accounts is shared, it is important that the usage record can be connected to each Arkis operator using the account. Every session in Island.io is recorded against a named operator with the device, network location and timestamp. Privileged sessions are captured in full, and the attribution survives on accounts several people share. Session events feed our security monitoring in real time.

Master accounts and off-exchange settlement secure the position and the assets. Island.io is where we secure the people who reach them.

Stay in the loop

Get the latest insights, product updates,and announcements from Arkis delivered to your inbox.

Subscribe

Subscribe

Stay in the loop

Get the latest insights, product updates,and announcements from Arkis delivered to your inbox.

Subscribe

Borrowers

Access capital-efficient leverage through a unified margin framework

LIQUIDITY PROVIDERS

Deploy capital through a governed, transparent risk framework

Borrowers

Access capital-efficient leverage through a unified margin framework

LIQUIDITY PROVIDERS

Deploy capital through a governed, transparent risk framework

Borrowers

Access capital-efficient leverage through a unified margin framework

LIQUIDITY PROVIDERS

Deploy capital through a governed, transparent risk framework

Borrowers

Access capital-efficient leverage through a unified margin framework

LIQUIDITY PROVIDERS

Deploy capital through a governed, transparent risk framework