Designing Role-Based Access for Who Can Touch Your Models

• Deploying a model version to production, which should require a different permission than deploying to staging.
• Viewing raw prompts and completions, which often carry customer data and shouldn't be bundled with general engineering access.
• Pulling model weights, especially fine-tuned ones, which is closer to accessing a trained asset than to normal read access.
• Changing routing or rate-limit configuration, which can silently redirect traffic to the wrong model version.
• Reading cost and usage dashboards, which is low-risk and can be far more widely granted than the others.

Most teams collapse all five into one engineering role. Separating them costs a little setup time and prevents a lot of accidental damage.

Start with three roles instead of two: viewer, for dashboards and non-sensitive logs; operator, for deploying to staging, adjusting routing, and viewing redacted logs; and admin, for deploying to production, viewing raw prompts, and pulling weights. Add a fourth, read-only-sensitive, for people who need to see raw prompts for support or compliance reasons but shouldn't be able to change anything.

Resist adding a role for every job title. The moment you have more roles than genuinely distinct permission sets, people start getting assigned roles based on convenience instead of what they actually need, which defeats the purpose.

A simple test helps when someone asks for a new role. Write down the exact actions the person needs, then check whether an existing role already covers them. If it does, assign that role. If the request is narrower and lower risk, ask whether the extra permission can be time-boxed instead of creating a permanent role. Only create a new role when a distinct set of permissions will be reused by several people. For example, a support lead who needs to read raw prompts for escalations fits the read-only-sensitive role, not a custom admin variant, because the risk being controlled is viewing customer data, not changing production.

Setting up roles once and never revisiting them is the most common failure mode. People change teams, contractors roll off, and admin access granted for a one-time migration quietly becomes permanent.

Run a review on a fixed schedule, quarterly is reasonable for most small and mid-sized teams, where someone actually confirms that every admin and operator still needs that level of access. Vanta and similar platforms can automate the reminder and evidence-collection side of this, which removes the excuse of forgetting, but a person still has to make the actual judgment call on each name.

Say a contractor is brought in for a short integration project and given operator access to deploy and test against a staging model endpoint. The short project runs long, and nobody revisits the grant when it should have ended.

Time-box access grants at creation, not just at review. An expiration date on the grant itself, even a generous one, means the default is access ending rather than access persisting until someone notices and removes it.

Most teams don't need more than the four roles above, but a genuine exception is a break-glass role for incident response: temporary, logged, elevated access that lets someone fix a production issue overnight without waiting on the normal approval chain.

Make break-glass access loud rather than quiet. It should notify someone else automatically the moment it's used, and it should expire on its own within hours, not linger as a permanent elevated grant because the incident got resolved and nobody circled back to revoke it.

• Sharing a single admin credential across a team because provisioning individual accounts felt slower.
• Granting production access for a one-time task and forgetting to time-box it.
• Treating read access to raw prompts as low-risk because it's just viewing, when it's often the most sensitive permission in the whole system.

A good role model on paper doesn't help if the actual grants drift away from it within a few months.