Model Access Control List (ACL)

Permissions are attached directly to a specific model version or artifact, not to an API endpoint. This means authorization travels with the model through staging, production, and rollback scenarios.

• Access is evaluated against the model's unique identifier (e.g., model:v2.3-prod)
• Revoking access to a deprecated version does not affect the new one
• Enables immutable audit trails tied to specific model artifacts

ACLs define who can invoke a model by binding permissions to distinct principal types:

• User Accounts: Individual data scientists or engineers performing ad-hoc inference
• Service Accounts: Machine identities for automated pipelines or microservices
• Group Claims: RBAC groups or OIDC claim-based groupings for team-level access
• Anonymous Principals: Explicitly denied by default; public access must be explicitly granted

Model ACLs support more than a binary allow/deny. They define specific verbs that map to inference operations:

• invoke: Permission to submit data and receive predictions
• read_metadata: Permission to view model card, version history, and performance metrics
• manage_acl: Permission to modify the ACL itself (typically restricted to model owners)
• export: Permission to download model weights or artifacts (often disabled in production)

When a request arrives, the ACL engine evaluates permissions in a deterministic order to resolve conflicts:

1. Explicit Deny: If any rule explicitly denies the principal, access is blocked immediately
2. Explicit Allow: If a rule explicitly grants the required action, access proceeds
3. Group Inheritance: Principal inherits permissions from group memberships
4. Default Deny: If no rule matches, the request is rejected (fail-secure posture)

This mirrors AWS IAM policy evaluation logic, ensuring predictable security outcomes.

Model ACLs rarely operate in isolation. They integrate with centralized authorization systems for unified governance:

• Open Policy Agent (OPA): ACL decisions can be delegated to OPA using Rego policies for complex, cross-service rules
• Policy Enforcement Points (PEP): Sidecar proxies or API gateways enforce ACL decisions at the network layer
• Token Introspection: OAuth 2.0 tokens are validated and mapped to ACL principals via RFC 7662-compliant introspection endpoints
• SPIFFE: Workload identities from SPIFFE are resolved to ACL service accounts in Kubernetes-native deployments

Every ACL evaluation generates a cryptographically signed audit event, stored in append-only storage for non-repudiation:

• What was logged: Principal ID, model version, action requested, timestamp, decision (allow/deny), and the specific rule that matched
• Compliance use cases: SOC 2 evidence, GDPR access reporting, and forensic investigation of model extraction attempts
• Tamper-proofing: Logs are written to WORM-compliant storage with HMAC integrity checks

An authorization model that simplifies Model ACL management by grouping permissions into named roles rather than assigning them to individual users. For model serving:

• Data Scientist role: invoke inference on staging models only
• Production App role: invoke inference on specific released model versions
• Auditor role: read-only access to query logs, no inference permission RBAC reduces the administrative burden of maintaining per-user ACL entries.

A compact, URL-safe token format used to transmit claims securely between the client and the model serving endpoint. A Model ACL evaluates the claims embedded within a JWT—such as sub, iss, and custom model:invoke scopes—to make authorization decisions. JWTs enable stateless authorization: the PEP can validate the token and enforce the ACL without a synchronous call to an external identity provider on every request.

A chronological, tamper-proof record of every access and query event against a model serving system. Each entry captures:

• The authenticated principal that invoked the model
• The specific model version and endpoint accessed
• The ACL rule that permitted or denied the request
• A cryptographic hash of the request payload Stored in WORM-compliant storage, this ensures non-repudiation for compliance frameworks such as SOC 2 and the EU AI Act.

The security concept that a service account or user should be granted only the minimum permissions necessary to perform its function. Applied to Model ACLs, this means:

• A billing service can invoke the fraud detection model but not the customer churn predictor
• A staging environment cannot access production model endpoints
• Temporary credentials are scoped to a single model version This limits the blast radius of a compromised credential, preventing lateral movement across the model inventory.