How do you control access to experiment and artifact stores?

Control access to ML experiments and model artifacts at every layer: the tracking API, experiment resources, artifact storage, and automation credentials. Protecting the dashboard alone is insufficient if someone can read or overwrite model files directly in object storage.

Question 82 covered how multiple teams organize shared tracking. This lesson focuses on the actual security controls and verification tests that enforce access.

Beginner-friendly example

A company has Delivery and Fraud ML teams.

• The Delivery team should read its own experiments and candidate models.
• The Fraud team should read and write its restricted fraud experiments.
• A deployment service should read only *approved* model artifacts.
• A platform administrator manages access but does not need raw customer data for ordinary troubleshooting.

Suppose Fraud has 20 experiment runs, each with a 150 MB model file. Their artifacts total 3,000 MB (about 3 GB). A read-only analyst authorized to view a validation metric must not automatically gain download access to all 3 GB of model files unless policy permits that access.

Access must be evaluated against the specific action, identity, resource, and sensitivity, not just the team's name.

The three protection layers

1. Authentication — who is calling?

• Require a verified human or service identity before accepting requests.
• Use corporate SSO/OIDC where supported, or another approved authentication mechanism.
• Give automated jobs their own identities; do not distribute a shared administrator password.
• Require TLS for network traffic and protect credentials in a secret manager.

2. Authorization — what can the caller do?

• Define privileges separately for experiments, runs, registered models, and any workspace.
• Distinguish read, create/log, update/delete, model approval, and administration.
• Apply least privilege. A validation dashboard generally needs read access, not permission to delete runs or promote models.
• Explicitly test denied operations; friendly resource names and workspace labels are not access-control rules.

3. Artifact storage — can the files be reached independently?

• Restrict buckets and object prefixes with cloud IAM, bucket policies, and network controls.
• Encrypt stored model artifacts and traffic using approved key-management policies.
• Avoid public buckets and long-lived credentials in training scripts.
• Audit direct reads, uploads, deletes, and generated download links where supported.

A user denied a run through MLflow must not be able to bypass that denial by navigating to a public object URL.

MLflow: proxied versus direct artifact access

MLflow supports two common storage access patterns.

Proxied artifact access

Authorized client
      │
      ▼
MLflow tracking / artifact proxy
      │ service identity
      ▼
Private object storage

The tracking server mediates artifact uploads/downloads. Clients need access to the server, while the server holds credentials for its configured artifact destination. Configure server authentication and resource permissions so the proxy does not become an unrestricted gateway.

Direct artifact access

Authorized client → MLflow metadata API
        │
        └────► private object storage
                (separate cloud IAM identity)

Clients receive or use storage locations and must have appropriate storage permissions themselves. This pattern can reduce proxy load but introduces a separate authorization surface: tracking API permission does not automatically prevent direct bucket access. Official MLflow documentation distinguishes --artifacts-destination for server-proxied artifacts from --no-serve-artifacts plus a direct artifact root.

Concrete permission policy

For a sensitive experiment named fraud/transaction-risk, a possible policy is:

• Fraud engineer: Read experiments, log runs, write artifacts within the approved Fraud prefix.
• Fraud reviewer: Read permitted metrics and review approved artifacts; no delete or model-promotion permission.
• Delivery engineer: Denied access to Fraud tracking resources and backing Fraud artifacts.
• Training service identity: Write run outputs to scoped paths, not global admin credentials.
• Promotion service identity: Read eligible artifacts and update only the designated approved model reference.
• Platform administrator: Manage access and infrastructure under audited procedures.

If metrics are public to internal analysts but model files are restricted, use a platform architecture that can enforce that difference. Do not assume any particular MLflow version provides per-file permissions within a run; use separate experiments, artifact locations, dedicated services, or custom authorization boundaries when needed.

A practical verification exercise

Test the system with three identities and two resources:

Resource A: delivery/eta-experiment
Resource B: fraud/risk-experiment

Delivery identity:
  Read A    → ALLOW
  Log A     → ALLOW
  Read B    → DENY
  Download B artifact directly → DENY

Fraud reviewer:
  Read B    → ALLOW
  Modify B  → DENY
  Delete B  → DENY

Check both UI and API behavior, then attempt access to the actual artifact URI with the identity that should be denied.

This is an authorization test specification, not a claim that these permissions have already been applied by the server.

Illustrative Python check of a tracking permission boundary

PYTHON
import mlflow
from mlflow.exceptions import MlflowException

mlflow.set_tracking_uri("https://tracking.example.org")

# Run under a deliberately restricted test identity.
try:
    experiment = mlflow.get_experiment_by_name("fraud/risk-experiment")
    if experiment is not None:
        print("Unexpected visibility: review authorization")
except MlflowException:
    print("Tracking request was rejected; inspect status and audit logs")

Important: Returning None or an error does not prove an authorization policy works; a resource could be missing or the server unreachable. Validate the *specific* unauthorized status and separately test a known existing resource, read/write actions, and direct artifact access.

Do not embed user passwords or cloud access keys in notebooks. Obtain short-lived credentials through an approved secret/identity system.

Operational security checklist

1. Scope storage identities. Restrict client and proxy credentials to necessary prefixes and actions; avoid wildcard object-store permissions.
2. Check newly created experiment locations. MLflow records an artifact root when an experiment is created. Changing the server's artifact mode does not automatically update older experiments.
3. Restrict download URLs. Short-lived presigned links can be shared by anyone who possesses them until expiration; use short TTLs and avoid exposing links in logs.
4. Audit changes. Record identity, action, target, result, and time for permission changes, model registration, and artifact deletion.
5. Protect backups and exports. A perfectly secured live server is undermined by a publicly accessible backup.
6. Apply retention and deletion rules. Backups, object versions, and experiment data can have distinct retention and removal behavior.
7. Review access periodically. Remove orphaned service identities and unused credentials when staff or projects change.

Common mistakes

• Assuming a login screen automatically protects the backing object store.
• Giving every ML job the same administrator token.
• Relying on experiment naming conventions rather than enforced permissions.
• Using s3://bucket/team/ as a security boundary without an IAM policy.
• Treating model promotion as equivalent to ordinary experiment logging.
• Letting old training identities retain unrestricted access indefinitely.
• Testing permitted actions but never checking that unauthorized downloads fail.

In short: Secure identities, tracking resources, and artifact storage independently, then verify that they work together. Least-privilege roles, private storage, audited service accounts, and explicit negative-access tests prevent both accidental sharing and direct artifact-store bypasses.