Summary
Prerequisites
To apply the practices on this page, you need:- The Owner or Admin role in Superblocks. See Organization roles.
- Admin access to your identity provider.
How to use this page
Review each section and apply the practices that match your deployment model. Managed BYOC adds a few responsibilities, listed in Managed BYOC responsibilities.Employee access controls
SSO policy
- Enforce multi-factor authentication for Superblocks in your identity provider.
- Align your SSO policy with your organization’s security standards, and review it regularly.
Access restriction
- Limit Superblocks access to the people who need it, using groups in your identity provider.
- Audit who has access to Superblocks regularly.
User management
- Offboarding: Remove employees and contractors from Superblocks promptly when they leave. With SCIM, removing someone in your identity provider removes them from Superblocks.
- Role-based access control: Assign admin roles by job duty, keep admin permissions as narrow as you can, and review them regularly. See RBAC.
- Network restrictions: In Managed BYOC, restrict access to your instance, for example to your corporate IP ranges, with custom WAF rule groups.
Integrations and credentials
Credential management
- Rotate integration credentials, such as API keys, tokens, and database passwords, on a regular schedule.
- Keep credentials in your own secrets manager. See Secrets management.
User identity for integrations
- Where the data source supports it, connect integrations with OAuth 2.0, including federated identity through your identity provider. Each user then reaches downstream services with their own identity and permissions, and the data source enforces its own access controls. See On-Behalf-Of token exchange and Snowflake External OAuth for examples.
- When a data source doesn’t support per-user authentication, use a dedicated service account instead of an individual’s credentials. Give it only the permissions its integration needs, and audit those permissions regularly.
Environments and data tags
- Link production credentials only to data tags that are allowed in Production, so they aren’t used during development. See Manage environments and data tags.
Network access to data sources
- On data sources that restrict inbound traffic, allowlist your data plane’s IP addresses. In Dedicated Cloud, private networking is coming soon as an alternative.
AI and Clark
Superblocks is responsible for how Clark’s model requests are handled through the Superblocks Inference Gateway:- Zero data retention: Superblocks holds agreements with model providers so they don’t retain prompts or responses.
- No training on your data: Superblocks holds agreements with model providers so your data is never used to train models.
- Secure transmission: Data sent to inference providers is encrypted in transit.
- Decide which data Clark can reach in the Edit environment. See Developing against lower environments.
Audit logs
Superblocks records builder activity, end-user activity in your apps, and integration and platform changes.- Review audit logs regularly, especially permission and credential changes.
- To bring audit events into your own tools, query them through the Superblocks MCP server.
Managed BYOC responsibilities
Managed BYOC runs in your AWS account, so your team takes on a few more responsibilities:- AWS account controls: Prepare the AWS account, control cloud-level access, and apply your IAM policies, service control policies, and security groups. Don’t change the Superblocks-managed resources in the account.
- Break-glass access: Grant Superblocks break-glass administrative access to your AWS account during deployment. Superblocks uses it only for break-glass purposes.
- Outbound traffic filtering: Optionally route outbound traffic through AWS Network Firewall.