Implementation guide
OWASP AISVS v1.01
Training Data Integrity & Traceability · Data Labeling and Annotation Security
Control who can label data
Verify that labeling platforms enforce access controls that restrict who can create, modify, or approve annotations.
OWASP AISVS v1.01, requirement 1.2.1
In plain English
Control who can create, change and approve labels. Labels are training data: anyone who can flip them unnoticed can change what the model learns, and the change is hard to spot afterwards.
What good looks like
- Labellers, reviewers and administrators are separate roles, each with only the permissions the job needs.
- A label cannot be approved by the person who created it.
- Everyone signs in with their own account, through single sign-on where the platform supports it.
- Outside labelling vendors can see only the projects they are working on, and their access ends with the contract.
How teams usually do it
- Role-based access in the labelling platform (for example Label Studio, Labelbox or SageMaker Ground Truth), tied to your identity provider.
- A review workflow that needs a second annotator or a reviewer before labels are accepted.
- A quarterly check of who holds each role, with leavers and finished contractors removed.
Suggested evidence
- Role definitions and the current list of who holds them.
- Platform settings showing that review is mandatory.
- The platform's audit log, showing who created and who approved a sample of labels.
Common mistakes
- Shared vendor logins, so you cannot tell who labelled what.
- Admin rights left with contractors after the project ends.
- Letting labellers export and re-import label files, which bypasses the review step.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.