> ## Documentation Index > Fetch the complete documentation index at: https://docs.superblocks.com/llms.txt > Use this file to discover all available pages before exploring further. # Shared responsibility Security in Superblocks is a shared responsibility. Superblocks secures and operates the platform: the infrastructure, the software, and the services that run your apps and Clark. Your organization secures how the platform is used: who can sign in, what they can do, which data sources apps connect to, and the credentials those connections use. The split is the same in both [deployment models](https://docs.superblocks.com/enterprise/deployment-overview.md). Superblocks operates the platform in Dedicated Cloud and in Managed BYOC. Managed BYOC adds a few responsibilities for your team, because the instance runs in your AWS account. Neither side can secure your apps alone. Superblocks can enforce only the access rules, roles, and credentials that your admins configure, and your admins depend on Superblocks to keep the platform underneath them patched and available. This page summarizes how responsibility is split, then lists the practices your admins should put in place. ## Summary | Area | Superblocks | Your team | | - | - | - | | Infrastructure and operations | Runs, scales, patches, upgrades, and supports the platform | In Managed BYOC, prepares and governs the AWS account | | Identity and access | Provides SSO, RBAC, and SCIM, and enforces the rules you configure | Configures SSO and MFA, assigns roles, and removes access | | Data sources and credentials | Stores integration resources in encrypted databases with limited internal access | Creates integration configurations, uses per-user OAuth where possible, and rotates any shared credentials | | Network access | Provides endpoints and outbound connectivity to your data sources | Controls which systems accept connections from Superblocks | | AI | Operates the [Superblocks Inference Gateway](https://docs.superblocks.com/enterprise/shared-centralized-services.md#superblocks-inference-gateway), holds zero data retention and no-training agreements with model providers, and transmits data to them securely | Decides which data Clark can reach during development | | Audit | Records platform audit logs | Reviews audit logs | ## Prerequisites To apply the practices on this page, you need: * The **Owner** or **Admin** role in Superblocks. See [Organization roles](https://docs.superblocks.com/admin/org-administration/org-roles.md). * 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](#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 1. **Offboarding:** Remove employees and contractors from Superblocks promptly when they leave. With [SCIM](https://docs.superblocks.com/admin/org-administration/auth/scim/index.md), removing someone in your identity provider removes them from Superblocks. 2. **Role-based access control:** Assign admin roles by job duty, keep admin permissions as narrow as you can, and review them regularly. See [RBAC](https://docs.superblocks.com/admin/org-administration/rbac.md). 3. **Network restrictions:** In Managed BYOC, restrict access to your instance, for example to your corporate IP ranges, with [custom WAF rule groups](https://docs.superblocks.com/enterprise/cloud-prem/configure/waf-rule-groups.md). ## 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](https://docs.superblocks.com/admin/secrets-management/overview.md). ### User identity for integrations * Where the data source supports it, connect integrations with [OAuth 2.0](https://docs.superblocks.com/integrations/auth/oauth-20.md), 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](https://docs.superblocks.com/integrations/auth/guides/on-behalf-of-token-exchange-backend-api.md) and [Snowflake External OAuth](https://docs.superblocks.com/integrations/auth/guides/snowflake-external-oauth-with-okta.md) 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](https://docs.superblocks.com/admin/environments.md). ### 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](https://docs.superblocks.com/enterprise/shared-centralized-services.md#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. Clark chat history is stored where your instance runs: in Superblocks Cloud for Dedicated Cloud, and in your AWS account for Managed BYOC. **Your team** decides what Clark can reach: * Decide which data Clark can reach in the Edit environment. See [Developing against lower environments](https://docs.superblocks.com/building-with-clark/data-access.md). ## Audit logs Superblocks records builder activity, end-user activity in your apps, and integration and platform changes. * Review [audit logs](https://docs.superblocks.com/admin/audit-logs.md) regularly, especially permission and credential changes. * To bring audit events into your own tools, query them through the [Superblocks MCP server](https://docs.superblocks.com/admin/mcp-server.md). ## 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](https://docs.superblocks.com/enterprise/cloud-prem/configure/network-firewall.md). See the [Managed BYOC deployment guide](https://docs.superblocks.com/enterprise/cloud-prem/deployment-guide.md) for how these fit into deployment. ## Related pages * [Shared and centralized services](https://docs.superblocks.com/enterprise/shared-centralized-services.md) * [Security guide](https://docs.superblocks.com/enterprise/security/overview.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.