MFA, RBAC & Service-to-Service mTLS
Multi-factor authentication (MFA) should be mandatory for all operator accounts and all administrative access to the AI system’s infrastructure. This covers the human oversight interface, the model registry, the data pipeline administration, the monitoring dashboards, and any other system that a human accesses. MFA prevents credential compromise from granting immediate access.
Role-based access control (RBAC) enforces the principle of least privilege. Each user and service account is assigned only the permissions required for their current function. The RBAC model should distinguish between roles with different access needs: operators (read access to inference outputs and explanations), data engineers (read/write access to data pipelines), model developers (read/write access to training code and experiment tracking), the AI Governance Lead (read access to all modules, approval authority for deployments), and administrators (infrastructure management).
Service-to-service communication uses mutual TLS (mTLS) or equivalent, ensuring that both the client and server authenticate each other. Combined with the identity-based access described above, mTLS prevents man-in-the-middle attacks and ensures that only authorised services communicate with each other. The access control configuration is documented in Module 9 and subject to quarterly review.
Key outputs
- MFA enforcement for all human access
- RBAC model with role definitions and permission matrices
- mTLS for all service-to-service communication
- Module 9 AISDP documentation
Model Artefact, Training Data & Config Access
Access to model artefacts, training data, and system configuration requires specific controls beyond the general RBAC framework. These three artefact categories are uniquely sensitive: model artefacts are valuable intellectual property and a potential attack vector; training data may contain personal information and is the primary target for data poisoning; configuration changes can alter the system’s behaviour as materially as code or model changes.
The security team restricts access to model artefacts to the CI/CD pipeline service account (for deployment), the model registry administrators (for maintenance), and named personnel with a documented business need (for investigation or audit). Training data access is restricted to authorised data engineers and model developers, with every access event (read, write, delete) logged in an immutable audit trail. Configuration access follows the same governance as code changes: modifications require pull request review and approval.
Access to all three artefact categories is auditable. The audit logs record who accessed what, when, from where, and for what purpose. The logs are immutable and retained for the ten-year period. Penetration testing should specifically test whether unauthorised access to model artefacts, training data, or configuration is possible through any path.
Key outputs
- Access controls specific to model artefacts, training data, and configuration
- Immutable audit logging for all access events
- Quarterly access reviews
- Module 9 AISDP documentation