Unreleased

Go to desktop to view this case study

The case study includes a detailed software hierarchy and governance workflows designed for a larger screen.

Back to portfolio

Unreleased product · 2026

Exploring clearer controls for Shadow AI and sensitive access

Two research-led workflows from the same unreleased security app: governing unmanaged AI models and rotating API keys without disruption.

Scope
Two focused security workflows, explored through domain research, systems thinking and interaction design.
Stage
The product was not released. Both features reached interactive prototypes.

The context

AI adoption can move faster than an organization’s approval process

The app explored infrastructure risks that startups are actively confronting as their systems mature. This case study begins with Shadow AI: after an unmanaged model is detected, reviewers need to understand where it is being used and decide whether it can remain.

Domain researchShadow AI governance

Model provenance, security review and the risks created by unmanaged AI usage.

Relevant structureSoftware ownership boundaries

The project, repository and deployable-artifact hierarchy needed for this workflow.

Scenario mappingDifferent scopes of action

The consequences of governing one artifact versus every occurrence of a model.

The product challenge

One flagged model can create many governance decisions

Consider vgg16_light_a: a scan finds the same model inside artifacts used across four projects. The relevant hierarchy is limited to what this workflow needs: projects contain repositories, and repositories contain deployable artifacts. Blocking only one location could leave other instances exposed. Blocking every location could interrupt production services.

What the team investigatesvgg16_light_aOne detected model
Where it appearsProject → Repository → ArtifactThe same model can exist across many branches
What the system governsThe containing artifactA package, file or container image

This distinction shaped the experience: the model is the subject of the investigation, while its containing artifacts are the units affected by a governance action.

Ideation

Three ways to make the model’s reach visible

I explored different ways to organize the same locations before committing to the drilldown.

Flat inventoryQuick to scan

But it hides how each artifact relates to its repository and project.

Relationship mapShows every connection

But it becomes difficult to compare locations or act consistently at scale.

Direction takenNested inventoryPreserves ownership and scope

It mirrors project, repository and artifact boundaries while supporting decisions at each level.

The hierarchy gave reviewers both a path to the individual artifact and a predictable way to understand broader actions.

Defining the interaction

The hierarchy had to answer two questions

Where does this model live? And before acting, how far will the decision reach?

What reviewers need to understandWhat the experience needs to do
The same model can appear in several deployed artifacts

Group every occurrence under its project and repository.

The artifact is the actual unit being governed

Keep its type and location visible when a reviewer approves or blocks it.

A decision can begin at different levels of the hierarchy

Make the chosen scope and its inherited outcomes explicit.

A broad decision can interrupt production software

Preview every affected artifact before the reviewer confirms it.

UX and UI decisions

Making scope visible at every step

The broader the scope of a governance action, the more explicitly the product should reveal its consequences. Row controls support focused decisions. A global block first reveals every affected artifact and asks the reviewer to document why the action is needed.

Interactive walkthroughShadow AI governance
Detected model

dbalencar / vgg16_light_a

Security riskHigh
Total reach7 artifacts / 4 projects
First detectedJune 2, 2026
OriginHugging Face

Governance triage

Scope / nameTypeEnvironmentStatusContent
mobile-banking-prod3 artifactsProjectProductionMixed
banking-services-repo2RepositoryProductionMixed
banking-api:v2.4.1Docker imageProductionBlocked
/app/models/vgg16_light_a.pt
banking-api:v2.4.2Docker imageStagingPending
/app/models/vgg16_light_a.pt
payments-infra-repo1RepositoryProductionPending
payments-processor:v3.1.2Docker imageProductionPending
/usr/local/lib/models/vgg16_light_a.pt
mobile-banking-dev1 artifactProjectDevPending
research-cache-repo1RepositorySandboxPending
vgg16_exp_v2.pklPickle modelSandboxPending
/downloads/vgg16_exp.pkl
cloud-migration-project2 artifactsProjectStagingPending
migration-repo2RepositoryStagingPending
service-proxy:v1.0.0Docker imageStagingPending
/opt/models/vgg16_light_a.pt
data-processor:v0.9.0Docker imageStagingPending
/opt/models/vgg16_light_a.pt
legacy-systems-vault1 artifactProjectStagingBlocked
primary-vault1RepositoryStagingBlocked
legacy-model-wrapperDocker imageStagingBlocked
/var/lib/models/vgg16_light_a.pt

API key management

Making API key access and change safer

Across both workflows, the design made credential risk visible at the moment of decision: permissions during creation, and potential disruption during rotation.

Interactive walkthroughAPI key lifecycle
Create a new key
Key permissionsChoose the minimum access this integration needs.
ResourceAccess
Detected modelsModel records, provenance and scan status
ArtifactsModel locations and deployment context
Governance decisionsApproval and blocking actions
ProjectsProject and repository hierarchy

Reflection

The design made consequence part of the decision

Across the feature explorations, the interaction mattered only when it made the consequence of a security action visible: affected scope in AI governance, granted access during key creation, and the transition window during rotation. Because the work remained exploratory, the next step would be validating whether those consequences are understandable without explanation.

What I would validate next

Object clarity

Can reviewers distinguish the detected model from each artifact that contains it?

Scope prediction

Can they predict the reach of an artifact-, repository- or project-level action?

Proportional friction

Does added confirmation feel appropriate as the potential blast radius grows?