Security and compliance

AgentKit holds your users’ OAuth tokens and API keys, and makes API calls with them on your agent’s behalf. This page explains how Scalekit protects those credentials and the data that passes through a tool call, and what your app is responsible for. Use it for a security review, or as a checklist before you onboard real users.

• SOC 2 Type II and ISO 27001 certified.
• GDPR and CCPA compliant. The Data Processing Agreement includes Standard Contractual Clauses and lists sub-processors.
• HIPAA eligible, with a Business Associate Agreement on Enterprise plans.

Audit reports and penetration test summaries are available under NDA from the Trust Center.

Every OAuth token and API key a user connects is encrypted before it’s written to the database:

• A key per environment. Scalekit encrypts credentials with AES-256-GCM under a data encryption key that belongs to one environment. No two environments share a key.
• Keys wrapped by Google Cloud KMS. Each environment’s key is itself encrypted by a master key in Google Cloud KMS, which is held apart from the database and the application. A copy of the database alone yields nothing usable.
• Scoped by environment. Every read and write of stored credentials is filtered by environment, so one environment’s context can’t reach another’s credentials.
• Rotation without downtime. When a key rotates, new values are encrypted with the new key and Scalekit re-encrypts existing values in the background, so existing credentials keep working. To re-encrypt existing data right away, use Re-encrypt Data on Encryption keys.
• Your own key, optionally. Hold the master key in your own Google Cloud KMS. Revoking Scalekit’s access to it makes the stored credentials unusable to Scalekit. See Encryption keys.

Scalekit never returns a user’s raw tokens in API responses. Your agent calls tools with execute_tool or the API proxy, and Scalekit adds the token to the outgoing request.

• Users’ OAuth tokens and API keys. Stored: Yes, encrypted as above. Kept for: Until the connected account is deleted.
• Connection settings, including your OAuth app’s client secret. Stored: Yes. Kept for: Until the connection is deleted.
• Tool call responses. Stored: No. Returned to your agent and not kept. Kept for: Not stored.
• Tool call inputs. Stored: No. Sent to the app and not kept. Kept for: Not stored.
• Tool call logs. Stored: Tool name, connection, connected account, identifier, status, error code, duration and time. Also the app’s error response, when Store connector error details is on. Kept for: 90 days.
• Your API client secrets. Stored: A one-way hash. The secret is shown once, when you create it. Kept for: Until you delete it.

Tool call logs show in AgentKit > Logs. They never contain a tool’s successful response. When a call fails, they keep Scalekit’s own error message, and keep the error the app returned only when Store connector error details is on in AgentKit > Logs. That error can include data from the app, so leave the setting off unless you’re debugging a connector.

Tool call logs also contain the user’s identifier, so use an internal user ID rather than an email address. See Choose an identifier.

Scalekit runs two independent regions on Google Cloud, with no shared application state:

Region	Location
US	us-west2 (Los Angeles)
EU	europe-west3 (Frankfurt)

You choose the region when you sign up, and your workspace’s data stays in it. See Environments and regions.

To keep credentials, tool calls and logs inside your own infrastructure, self-host AgentKit with an enterprise license.

All Scalekit endpoints require HTTPS with TLS 1.3. If an app only accepts traffic from known addresses, allow Scalekit’s outbound IP addresses for your region.

Scalekit protects credentials once a user connects. Your app decides who connects and who can act as whom:

• Verify users in production. Set AgentKit > Settings > User Verification to Custom user verifier, so the person who approves access is the user your app meant. With None, anyone who opens an authorization link activates the account. See Verify users.
• Use a stable, internal identifier. Pass your app’s user ID, never an email address or anything a user can choose. Take it from your server-side session, not from the request body, so one user can’t act as another.
• Keep one user’s credentials with that user. When you hand a credential to an agent runtime, such as a Virtual MCP session token, store it per user and never share it across users.
• Keep API credentials on the server. Load your client ID and secret from environment variables or a secret manager, never from browser or mobile code. Rotate a secret by creating a new one before you delete the old one. See API credentials.
• Request only the scopes you need. A narrower scope limits what a leaked token can do. See Configure scopes.
• Give agents only the tools they need. Start with read-only tools, and ask the user before a destructive call. Tool definitions carry read_only_hint and destructive_hint for this. See Use built-in tools.
• Verify webhook signatures. Scalekit signs every webhook. Check the signature before you trust a payload. See Verify each request.
• Limit who can use the dashboard. Give teammates the least access their work needs. See Team members and roles.