Perimeters in Anaconda Platform: One Policy Boundary Around Your Code, Data, Models, and Compute

Anaconda introduced Perimeters in the Anaconda Platform, a policy boundary that governs the code and its full dependency tree, data sources, models, compute, users and agents, and security credentials for an AI system, with administrators defining the boundary once. Perimeters let teams develop inside an experimentation perimeter and promote to production through CI/CD without changing the code, applying separate policies for software supply chain (blocking packages with known CVEs in production), data (mapping existing Databricks or Snowflake governance), models (via a model catalog), compute (smaller GPUs for experimentation, larger reserved for production), and role-based access control for human users, machine users, and agents.

If you build AI systems inside a company, you know the question that stalls a project: which code is this thing allowed to run, which data can it read, which models can it call, and what hardware can it burn through? Someone has to answer that for every environment, and the answer for an experimentation environment is rarely the answer for production. Perimeters https://www.anaconda.com/platform/ai-orchestration are how the Anaconda Platform answers it. A perimeter is a policy boundary drawn around every building block of an AI system: the code and its full dependency tree, the data sources, the models, the compute, the people and agents allowed in, and the security credentials it all runs on. An administrator defines the boundary once. What a perimeter contains An AI dev factory, a place where you define custom agents and custom AI systems with your own data behind them, needs a set of inputs. In an enterprise, every one of those inputs comes with a trust question attached. Code covers more than what your team writes. Every third-party package in the environment counts, which makes this a software supply chain problem, and Anaconda has worked more than a decade securing and governing the open-source software supply chain: vetted sources, a secure build process, and the environment you run. Models are heading the same way; a model catalog with policies attached now sits inside the same boundary. Then come the resources. Which compute should this environment reach? Should everyone get GPUs for experimentation, or should production be limited for cost reasons? Who has access at all, and is it execution access or read-only? And which identity and access management IAM policies govern the cloud resources underneath? A perimeter wraps all of that in one governance boundary. You might have one perimeter for experimentation and another for production, each with its own policies. You could also cut them by project, by geography, or along any other line your organization needs to draw. From experimentation to production without changing the code Do your development inside the experimentation perimeter. When it’s ready, promote it to production through your continuous integration and continuous delivery CI/CD system, with whatever human-in-the-loop steps you want in the pipeline: code review, test runs, sign-offs. The code itself doesn’t change. The perimeter around it does, and with it the packages, data, models, compute, and credentials it’s allowed to use. Defining perimeters in the user interface UI In the platform UI, perimeters show up as a list, including experimentation and production, but there’s no fixed number. Each entry opens into its own policy set. The policies, one at a time Every perimeter carries the same categories of policy. The values differ; the shape is identical, so once you understand one perimeter you understand all of them. Software supply chain In production, block any package with known Common Vulnerabilities and Exposures CVE . In experimentation, allow more. The policy applies across the whole chain, from source to build to the resulting environment. Data Map your existing data governance onto the perimeter. If your warehouse is Databricks or Snowflake, you can expose certain tables to production and a different set to experimentation, using the boundaries your data team already maintains. Models The model catalog lets you write policies like “production only runs open-weight models built in the US” or “this project only uses this model family.” Same idea as the package policy, applied to model weights. Compute Give experimentation access to smaller GPUs and reserve the larger, more expensive ones for production. Compute policy sits in the same place as everything else, so the cost boundary and the security boundary are the same object. Access Role-based access control covers human users, machine users, and agents. You set who can enter the perimeter and what they can do once inside. A common setup: every developer has execution access in experimentation and read-only access in production. Your existing IAM policies Your IT team attaches the IAM policies already in place in AWS, Google Cloud, or Azure to the perimeter, so nobody writes a second set of security policies for the AI platform. The admin defines it once and every user inherits it. That policy then governs access to buckets, databases, deployment targets, and whatever else lives in your cloud account. In many other systems, users manage IAM policies themselves and sometimes switch between them by hand. Here they don’t see them at all. Secrets API keys for third-party models and other external services live in a secrets manager scoped to the perimeter. Production credentials stay in production. What you see day to day Almost nothing. The admin sets up the perimeters; you open the platform and see your projects. If you have access to more than one perimeter, the project picker is where you switch. If you only have access to experimentation, you only see projects defined there. How projects and perimeters fit together Projects are the semantic container: the work you’re doing, grouped the way your team thinks about it. Perimeters are the security boundary the administrator draws around those projects. A project moves between perimeters through CI/CD, which is how the same code goes from experimentation to production with a different set of rules attached. That combination is what lets you build demanding, custom AI systems in your own environment with the controls your security and IT teams already trust. Request a demo https://www.anaconda.com/request-a-demo to see perimeters configured against your own cloud account.