Built to hold other people’s keys.
Arc0 stores your users’ credentials so your agents can act for them. That makes security the product, not a page at the end of the site. Here is how it is designed, and what isn’t done yet.
How your users’ credentials are handled.
Each of your customers gets its own encryption key. A problem in one tenant can’t expose another’s credentials.
Arc0 executes the call server-side and returns only the result. Tokens never pass through the agent or the LLM.
Users grant only the scopes your agent asks for. Policies can narrow them further per agent.
Tokens refresh before they expire. Users can revoke from their connected-apps page; you can revoke by API.
Use your own OAuth client for each provider, so the provider’s consent screen names you and the grant is yours.
Export your tokens whenever you want. Tokens issued to your own OAuth apps keep working after you export them, so leaving never means a mass reconnect.
What you control.
Allow or deny by app and scope: read, write, destructive. Set them per customer and per agent.
Route risky actions to a human before they run. The agent waits; nothing executes until someone approves.
Set a policy to block the call when a check can’t be evaluated, rather than let it through.
Every call and every decision, with the policy that made it. On every plan, including free.
On paid plans, stream audit events into the observability and security tools you already run.
Request and response payloads aren’t stored by default. Turn on short retention when you need to debug.
What we store, and what we don’t.
Stored
Encrypted credentials for each connection; connection metadata such as the app, the scopes granted and when; and audit entries recording which agent acted for which user, in which app, with which scope, and the policy decision.
Not stored by default
The content of requests and responses: the emails your agent sends, the records it reads. You can turn on short retention for debugging, and turn it off again.
Never
Used to train models, sold, or shared with anyone other than the app your user connected. For how connections and policies fit together, see the concepts.
Where we are, honestly.
| ITEM | STATUS | NOTES |
|---|---|---|
| SOC 2 Type II | PLANNED | Not yet audited. We will publish the report when we have it. |
| Third-party penetration test | PLANNED | Before general availability. |
| EU data residency | PLANNED | Planned for the Scale plan. |
| Responsible disclosure | OPEN | security@arc0.ai |
Security questions.
Can Arc0 staff read my users’ tokens?
Credentials are encrypted with per-tenant keys and decrypted only inside the services that execute calls and handle token exports. If you need more isolation, the Scale plan will offer a VPC or self-hosted deployment.
Do you store the data my agents read or write?
Not by default. Arc0 stores credentials, connection metadata and audit entries: who acted, in which app, with which scope, and the decision. Request and response bodies are only kept if you turn on retention.
Do you train models on customer data?
No. Arc0 does not train models, on your data or anyone else’s.
Are you SOC 2 compliant?
Not yet. Our audit plans are in the status table on this page. We will not claim a certification before we hold it.
How do I report a vulnerability?
Email security@arc0.ai with the details and steps to reproduce. We acknowledge reports within two business days and will keep you updated while we fix it.
Bring us your security review.
New teams get a walkthrough of the architecture with an engineer, and answers to their questionnaire before they connect a single user.