> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Policies overview > How a sandbox resolves against the policy that governs its cluster, and what a policy can constrain. A **policy** is the governance an administrator sets for sandboxes on a cluster. It combines a permissive base layer of defaults that every sandbox inherits with typed constraints that bound what a sandbox may request. One policy governs a cluster, and it is required, so the security posture is always something an administrator declared rather than something the platform chose. Users do not select a policy, and they do not need to know one exists. A user describes the sandbox they want. If the policy permits that sandbox, it launches. If the policy forbids part of it, the request is rejected and the error names what was denied. ## How a sandbox resolves against a policy A sandbox resolves in two stages. 1. **Base.** The policy supplies runtime defaults and attachments, merged in the order runtime defaults, then policy base, then the sandbox spec. Your spec wins for individual values. 2. **Constraints.** Typed clamps are validated against the fully resolved spec. A spec that violates a constraint is rejected, never silently rewritten. The order matters more than it looks. Because constraints validate the resolved spec rather than the submitted one, a value the base supplied is checked on the same terms as a value you supplied. An empty policy is valid and meaningful. It declares a fully permissive posture with no base defaults and no constraints, while platform-level safety gates still apply. ## What a policy can constrain Constraints are grouped by what they govern. Every group is optional, and an unset group imposes no constraint of that kind. | Group | Governs | | - | - | | `resources` | CPU and memory minimums, maximums, defaults, and ceilings, and whether limits are required. | | `image` | Which registries and images a sandbox may run. | | `network` | The egress and ingress a sandbox may request, and what it gets when it requests none. | | `security` | Privileged containers, Linux capabilities, seccomp profiles, host namespaces, and runtime classes. | | `instance` | Which node instance types a sandbox may land on. | | `lifecycle` | How long a sandbox may live. | | `metadata` | Which annotation prefixes are denied. | | `volumes` | Which storage media are permitted and the maximum volume size. | Network constraints define allowlists for the access a sandbox can request. A sandbox declares the access it needs, the policy validates that request against what the cluster permits, and the policy separately defines what an absent request means. Declaring access is also how a sandbox restricts itself, which is useful when you run an untrusted agent and want to narrow its reach below what the policy would allow. ## What changed from profiles Policies replace profiles. The difference is not only the name, and two changes are worth understanding before you migrate. **Users no longer choose anything.** Under profiles, a user picked a profile by name, which meant knowing which profiles existed and having permission to look. When no profile fit, the user asked an administrator to author one. Under policies, the user declares the sandbox they want and the platform either allows it or explains what it denied. **Resolution runs the other way.** A profile overrode the values in your sandbox spec. A policy does the opposite: your spec wins, and the policy constrains the result. Configuration that a profile silently replaced is now either honored or rejected with a reason. The inverted resolution is a behavior change, not a rename. A request that a profile would have quietly reshaped may now be rejected outright. Review existing profile configurations against the constraint groups before you migrate them. Policies are set per cluster. There is no per-team or per-user granularity, so every user of a cluster resolves against the same policy. ## Where reusable configuration lives Profiles served a second purpose beyond governance. They were a convenient way to save a set of options and reuse it, one per team or per application. That role now belongs to sandbox templates, which hold a reusable partial sandbox specification that you can override when you create a sandbox. Templates carry no authority: they are a starting point, and the policy remains the only thing that enforces anything. See [Sandbox templates](/products/sandboxes/profiles/templates) for the workflow and complete example templates. ## See also * [Sandboxes architecture](/products/sandboxes/architecture): the resources that build a sandbox and the gateway that brokers every request. * [Deploy and manage a runner](/products/sandboxes/operations/managed-runners): the runner lifecycle and the configuration a runner carries. * [Control plane API overview](/products/sandboxes/reference/control-plane-api): authentication, field masks, heartbeats, and the endpoint contract.