Security Research Program

At Arcade, security is fundamental to our mission of building safe and reliable tools. We recognize that the security research community plays a valuable role in identifying potential vulnerabilities.

Scope

Our program covers security issues in:

• Arcade production services and APIs
• Agent authentication and authorization mechanisms
• Data handling and storage systems
• Published open-source components

What we’re looking for

We’re interested in reports about:

• Authentication or authorization bypasses
• Data exposure or leakage
• Injection vulnerabilities
• Logic flaws affecting agent behavior
• Issues that could compromise user data or agent integrity

A finding that shows one tenant reading or changing another tenant’s tokens, secrets, or data is in scope. Send that.

Reporting process

Please email our security team with:

• A clear description of the issue
• Steps to reproduce
• Potential impact assessment
• Any relevant proof-of-concept code (please be responsible)

We’ll acknowledge receipt within 72 hours and aim to provide an initial assessment within one week.

Guidelines

• Please allow us reasonable time to address issues before public disclosure
• Avoid automated scanning that could impact service availability
• Do not access or modify other users’ data
• Keep any discovered vulnerabilities confidential until resolved

Recognition

While we’re a small team with limited resources, we appreciate the effort researchers put into improving our security. We’ll credit researchers (with permission) in our security updates and may provide modest rewards for significant findings on a case-by-case basis.

For questions about this program, please contact our security team.

Common questions

Researchers most often ask about mail authentication, DNS, and OAuth reports that describe the Arcade Cloud data model.

Arcade’s DNS settings are intentional

Arcade manages email authentication with SPF, DKIM, and DMARC. The SPF record ends in ~all (SoftFail), while DMARC uses p=reject. Receivers reject unaligned mail that claims to come from arcade.dev. Valimail manages this configuration.

Reports that only recommend -all, DNSSEC, RRSIG, or CAA describe hardening choices, not vulnerabilities. Include a demonstrated security impact if you believe the configuration is exploitable.

Public discovery documents are public

auth.arcade.dev/.well-known/openid-configuration publishes standard OpenID metadata for clients. Its contents are not sensitive, and Arcade does not support dynamic client registration.

A project API key is an administrator credential

Arcade Cloud isolates data by tenant and by project. A project is the trust boundary. Everyone with project membership is an administrator. Project administrators and anyone with an API key share access to that project’s users, brokered tokens, and secrets. They can also start authorization for those users. Invite people you trust, and join projects you trust.

A project API key authenticates as the administrator who created it. It can start authorization and read tokens for that project’s users by design to support offline and background workloads. A report that uses a project key to read data from the same project describes expected administrator access.

Projects scope user IDs

user_id is an opaque, caller-supplied string. The same value can appear in many projects, but each project has its own authorization records. Using ada@example.com in one project does not grant access to records for ada@example.com in another project.

Completing a flow stays in the project that started it

To complete authorization, the user verifier must use an API key from the project that started the flow and submit the same user_id supplied at the start. The user ID does not travel through the browser redirect.

A custom auth provider replaces the platform provider for your tenant

You can add an auth provider whose ID matches a platform provider, such as google. Your provider then handles authorization for your tenant, and its client ID appears in the authorization URL. The identity provider still validates the client and redirect URI.

A broken provider configuration can disrupt that tenant’s tools. This reflects expected administrator access, not a cross-tenant outage.

Default OAuth apps follow project membership

Arcade’s default OAuth apps work with the Arcade user verifier. The verifier asks the end user to sign in to an Arcade account that is a member of the project. Membership means the project may act for that account on connectors that use the default app.

A default-app token can appear in a second project only when that Arcade account is also a member of the second project. Project membership is a trust relationship.

For a multi-user production app, add your own OAuth client and a custom user verifier. Default apps fit development and single-tenant use.

Read Confused deputy attacks on OAuth  for a related consent-binding issue and Arcade’s control.

Secret names are public

Platform secret names are public so customers can replace defaults with their own values.

A response that returns secret values, or another tenant’s secret material, is a different finding. Send that.

Health-check tokens authenticate the health check

Worker health checks use a credential limited to that check. Steady-state calls use a secret for the worker deployment.

Include evidence that the token succeeds on a real worker request or reaches another tenant’s data.

Plan limits are soft

Arcade uses soft plan limits and allows overages. Exceeding a listed limit does not indicate an authorization bypass.

Archived examples

Archived example repositories are samples. A static scan of an archived repo, with no impact on Arcade Cloud, is outside this program.

Files on a developer laptop

The Arcade CLI stores credentials on the machine where it runs. A local file-permission finding must expose another user’s data or affect Arcade Cloud to fit this program.