Once a security team accepts that Arcade.dev keeps credentials away from the model, the next question usually turns to the credentials themselves. Where do they actually live, who can read them, and can we hold the keys? These are the right questions, because a token store is a high-value target. The short answer is that Arcade stores tokens in an encrypted, per-user vault that the model never touches, and you decide whether that vault sits in Arcade’s cloud or entirely inside your own environment.
Tokens live in an encrypted vault, not in the agent
Arcade brokers the OAuth flow and holds the resulting tokens on your behalf. Those tokens sit in an encrypted vault, encrypted at rest through a key management service (KMS) and protected by TLS in transit. Each token is scoped to a specific user, so the vault holds per-user credentials rather than one shared key for everything. At execution time, Arcade injects the credential into the action and returns the result. The token is never handed to the LLM or the MCP client, so it never enters a prompt, a context window, or a model response. A prompt injection attempt has nothing to reach for.
You choose where the vault lives
Where your tokens are stored comes down to a single decision: does Arcade hold the vault, or do you?
With Arcade Cloud, the managed service, tokens sit in Arcade’s encrypted vault, with storage and processing running in United States infrastructure. If you self-host, that same vault runs inside your own environment instead, whether that’s your private cloud, on-premises, or a fully air-gapped network. In that case the credentials stay in your KMS, and Arcade processes each action without storing any of your customer data.
Keep in mind that choosing where your tools, or the rest of the runtime, runs doesn’t move the vault. Unless you self-host, the token store is Arcade-managed.
Can you bring your own key?
If holding the encryption keys yourself is a requirement, the self-hosted deployment is the direct answer. The vault runs in your environment, the tokens stay in your KMS, and the keys never leave your control. Arcade operates the runtime logic without ever holding your secrets. This is also where “bring your own auth” fits: you connect your own identity provider and your own OAuth applications, so the entire credential path, from the app registration to the stored token to the encryption key, belongs to you. For regulated teams, that combination is often what turns a hard “no” into an approved deployment.
Why security teams are satisfied
“Where are tokens stored?” shows up on nearly every enterprise security review, and this model answers it cleanly. Tokens are encrypted at rest in a KMS, encrypted in transit with TLS, scoped per user, and revocable, so removing a user’s access cuts the agent off on its next action. Nothing runs as a shared service account, which means every action traces back to a real person when an auditor asks who did it. Deploy the runtime behind your own VPN and SSO, and the credential store lives inside the same controls your other production systems already answer to.
The headline: an encrypted vault ensures the model never sees your tokens
Your tokens live in an encrypted, per-user vault that the model never sees, protected by KMS at rest and TLS in transit. You choose whether that vault runs in Arcade’s managed cloud or entirely inside your own environment, and if you need to hold the keys yourself, self-hosting keeps the tokens and the keys in your KMS. The credentials stay locked down, and the agent still gets its work done.
