Model and data access control

What it does

It applies to AI assets the access discipline already expected for sensitive data and production systems. Weights and training sets are treated as high-value assets with named owners. The practical test is whether the organisation can say, for any model, who could copy it today and who accessed it last month. Security owns the standard; the model owner and data owner approve access to their assets, which is reviewed on the normal entitlement cycle.

How to implement it

• Inventory where weights, adapters, datasets and pipelines are stored.
• Define roles for those who may read, modify, deploy and query each.
• Separate the ability to train a model from the ability to deploy it.
• Encrypt artefacts at rest and in transit.
• Log all access to artefact stores and alert on bulk transfer.
• Require the same of suppliers who hold these assets.

Evidence it operates

Design: an asset inventory with owners and an access model. Operation: current access lists that match approved roles; the latest review with removals; logs of access to artefact stores; an alert raised by a test bulk download.

Where it fits

Set up with the development environment and maintained in production. It is the primary control for model weight theft and AI development environment compromise.

Limits

It does not prevent misuse by someone with legitimate access, nor copying of a model through its public interface. Development environments tend to accumulate exceptions; the control decays without review. Shared storage set up for convenience during a project is the usual source of over-broad access and should be closed when the project ends.