Designing permission-aware systems across UI, API, and IaC

Why this mattered at scale

• Addressed widespread misinterpretation where users assumed missing functionality rather than restricted access, suppressing platform adoption.
• Resolved organizational ambiguity that forced Security, Platform, and Product to relitigate permission behavior for every new capability.
• Enabled safer feature rollout by making constraints explicit without hiding what the platform offered.

My role

As Staff Product Designer and acting design lead, I owned the reframing of permissions from a UI enforcement detail into a platform-wide communication system. I partnered closely with Platform Engineering, Security, and Product to define cross-surface access principles spanning the console, APIs, and infrastructure-as-code. This work set the default model for how new capabilities and permissions are introduced across the platform.

Problem

At CoreWeave, permission constraints were enforced correctly, but communicated poorly. By hiding inaccessible resources entirely, the platform prevented users from understanding what capabilities existed at all. This led customers to assume features were missing, made permission requests vague or misdirected, and quietly suppressed adoption, especially for users interacting primarily through APIs and Terraform.

Solution (high level)

I reframed permissions as a product communication problem, defining cross-surface principles that separate awareness from action. The system now signals that capabilities exist while clearly stating that access is restricted - consistently across the console, API responses, and Terraform - so users understand boundaries without being misled or over-informed.

Impact

• Corrected false assumptions about missing functionality
• Improved clarity and specificity of permission requests
• Reduced ambiguity across support, product, and engineering teams
• Established consistent access semantics across UI, API, and automation
• Enabled safer feature rollout without hiding capabilities

Design approach

Details, decisions, and outcomes

When silence erased capability

CoreWeave customers often assumed the platform was missing features it actually supported. They'd ask support whether capabilities existed, request access to things they already had permission to use, or avoid the console entirely in favor of Terraform and custom code - not because the UI was difficult, but because inaccessible resources were completely hidden.

The platform enforced permissions by hiding what users couldn't access. No resource, no action button, no navigation item - technically correct, security-first, defensible. But this approach collapsed two different truths into indistinguishable silence: this doesn't exist and this exists, but you can't access it.

Users who lacked permissions couldn't tell what the platform offered. They couldn't plan infrastructure, request the right access, or even know what questions to ask. The system prevented action but also erased awareness - and for a platform designed to handle complex infrastructure, that misalignment undermined trust.

This wasn't contained to the console. Customers provisioned most infrastructure through APIs and Terraform, where the same pattern surfaced as silent absence or opaque errors. What initially looked like a UI state problem was actually a platform-wide communication failure.

Constraints and non-negotiables

The solution needed to preserve CoreWeave's conservative security posture while working consistently across console, API, and infrastructure-as-code - including for users who never touched the UI. It couldn't rely on role-based assumptions given the variability of org structures and service accounts, and it needed to remain stable as new resources and permissions were added.

Most critically: increasing visibility couldn't weaken security boundaries. The goal was accuracy, not access.

Reframing permissions as a platform communication problem

This wasn't a discoverability problem or a UI-state problem. Permissions were already enforcing access correctly. The failure was that the platform communicated nothing - silence where there should have been clarity.

The solution required separating two things the system had collapsed: awareness and action. Users needed to understand what capabilities existed and why access was restricted, without implying they were entitled to those capabilities or that security boundaries were negotiable.

This reframe changed everything. The design goal wasn't to enable more actions or expose more controls - it was to enable accurate understanding across every surface where users encountered the platform.

Designing a system that communicates constraint without erasing capability

1. Reveal existence without implying entitlement

In the console, inaccessible capabilities surface in a disabled state with concise explanations. In APIs and Terraform, the same intent shows up as explicit error responses rather than silent absence. The pattern is consistent: this exists, access is restricted, here's why.

2. Tune disclosure by context, not by role

Disclosure varies by interaction context, not user role. The console can use progressive disclosure and visual affordances. APIs need structured error codes. Terraform needs actionable plan output. What remains constant is intent: every surface answers the same questions - does this exist, is it restricted, what does that mean now?

3. Design for users who never see the UI

Many CoreWeave users interact exclusively through APIs, Terraform, and automation. API errors, plan outputs, and validation messages carry the same semantic meaning as console states: capability exists, access is restricted, this is intentional. Permissions became a platform property, not a UI artifact.

How the principles showed up across the platform

In the console, the "Create a bucket" action remains visible but disabled, with a tooltip explaining "You have view-only access. Ask an admin to grant bucket creation permissions." Users see what's possible without confusion about whether the feature exists.

API responses use explicit error codes and structured messages:

{
  "error": {
    "code": "PERMISSION_DENIED",
    "message": "Bucket creation requires storage.admin role",
    "resource": "storage.buckets.create"
  }
}

The response confirms the capability exists, states the specific permission gap, and provides the resource identifier needed to request access.

Aligning security, platform, and product around shared semantics

Platform Engineering, Security, and Product initially treated permissions as backend enforcement, not product communication. Early conversations surfaced tension: Security worried that showing restricted resources implied they were negotiable. Product wanted clarity but feared security would veto changes. Platform Engineering needed consistent rules they could implement without case-by-case judgment.

Rather than debating individual UI states, I anchored alignment on the core principle: awareness ≠ entitlement. Security could maintain strict enforcement while users gained visibility. The principles became the shared model for introducing new capabilities - no re-litigation, no exceptions.

Outcomes

Users stopped assuming features were missing. Permission requests became specific - naming the capability and required role rather than asking whether something existed.

Support conversations shifted from "Does CoreWeave support X?" to "What access do I need for X?" API and Terraform users encountered explicit errors with actionable context instead of silent failures.

Internally, product and engineering teams introduced new capabilities without debating how permissions should surface. Access behavior became predictable and reusable across the platform.

Designing systems that tell the truth

Permissions reveal whether a platform is honest. When they hide what exists, they distort understanding and erode trust. When they separate awareness from action, they allow users to reason accurately about capability and constraint - even when the answer is "not for you."

By treating access as a communication problem rather than an enforcement detail, this work made CoreWeave's platform legible without compromising security. Users could see what existed. Teams could ship features without hiding them. And the system could enforce boundaries while telling the truth about what was possible.