EAAPL-MDL008 — Model Access Governance

1. Executive Summary

Model access governance controls who can invoke, export, copy, and administer AI models within and outside the organisation. Without it, proprietary fine-tuned models — which represent significant IP investment — can be accessed by unauthorised internal users, extracted through overprivileged API keys, or shared with external parties without appropriate legal and technical controls. For CIOs, model access governance is a category of information security and IP protection that sits alongside data governance but requires distinct controls because models, unlike data, are executable assets that can generate unlimited inferences at trivial marginal cost if accessed without restriction. For CTOs, the pattern establishes three model access tiers (Restricted, Internal, Public), API key scoping to specific model versions, and per-model usage auditing — a consistent framework that applies across the model portfolio. For risk officers, model access governance directly satisfies APRA CPS 234 information security obligations, EU AI Act operator access obligations, and provides the audit trail required to respond to model access incidents or external share disputes. The pattern is medium-complexity: it requires identity-aware API management, a secrets management layer, and a usage audit store, all of which are available as managed cloud services in every major cloud environment.

2. Problem Statement

2.1 Business Problem

AI models represent a new category of enterprise IP asset. A fine-tuned model trained on proprietary enterprise data embodies that data in a form that can be extracted through inference attacks or directly through weight theft. Internal access controls for models are typically absent: any developer with a service account can invoke any model, any API key can access any version, and there is no record of who used what model for what purpose. When an employee leaves, their API keys continue to work until someone notices.

2.2 Technical Problem

AI model APIs are stateless HTTP endpoints: without an access governance layer, there is no mechanism to enforce who can call which model, to scope keys to specific model versions, or to record usage for auditability. Traditional API management provides authentication but not the model-specific authorisation, version scoping, and audit record required for AI model governance.

2.3 Symptoms

• A single API key is shared across multiple teams and cannot be attributed to a specific user or purpose.
• There is no record of which models were accessed by which team or individual last quarter.
• An external partner was given access to a model endpoint without a data processing agreement or acceptable use policy.
• API keys for deprecated models are still present in production code — the models may no longer serve, but the keys are live.
• A model that should only be accessible to named security researchers is listed in the same API management system as public-facing models with no access differentiation.

2.4 Cost of Inaction

3. Context

3.1 When to Apply

• Any organisation with two or more AI models serving different internal or external consumers.
• Organisations deploying models with any combination of internal and external consumers.
• Models containing IP derived from proprietary enterprise data (fine-tuned models).
• Regulated organisations subject to APRA CPS 234, EU AI Act, or equivalent.

3.2 When NOT to Apply

• Research sandbox environments where all users have equivalent high-trust access.
• Single-model deployments with a single consumer service account where additional access governance adds overhead without value.

3.3 Prerequisites

3.4 Industry Applicability

4. Architecture Overview

4.1 Model Access Tiers

Tier 1 — Restricted: The highest protection tier. Applied to models trained on classified or highly sensitive data, models used for regulated decisions, and pre-production models undergoing security review. Access is limited to named individuals approved by the board or CISO. Access requests require written justification, manager approval, and AI Governance sign-off. Keys are individually issued (one per named person) and expire after 90 days. Export of artefacts from this tier is prohibited without CTO approval and legal review. Typical models: credit scoring model, clinical decision support model, security intelligence model.

Tier 2 — Internal: Standard internal access tier. Available to all employees and approved internal service accounts via a standard access request process (manager approval, 30-minute automated provisioning). Keys are scoped to specific model versions and expire after 180 days. Artefact export requires a data handling assessment and manager approval. Typical models: internal search model, employee productivity assistant, internal analytics model.

Tier 3 — Public: External API access for approved external partners and public API consumers. Access requires execution of the organisation's API Terms of Service and, for partners accessing models trained on enterprise data, a Data Processing Agreement. Keys are issued per external organisation (not per individual). Usage is capped per key (rate limiting, token quota). Audit logging records usage per external organisation. Artefact export is prohibited — API access only. Typical models: customer-facing recommendation model, public developer API.

4.2 API Key Scoping to Model Versions

API keys carry a scope claim that defines which model versions they may invoke. A key issued for model-credit-score:v2.1.0 cannot be used to call model-credit-score:v2.2.0 or any other model. Version scope is enforced at the API gateway layer — the key is validated against the model version in the request path before the request reaches the inference backend.

When a model version is deprecated, all keys scoped to that version are automatically invalidated on the sunset date. Consumers receive advance notice (per the deprecation management process in EAAPL-MDL001) to rotate their keys to the new version.

This per-version scoping prevents two failure modes: (a) a key issued for an old, known-safe version being used to access a new version with different capabilities; (b) a compromised key providing unlimited access across all model versions.

4.3 Usage Auditing Per Model

Every model inference request is logged to the usage audit store with: key identity (maps to a named user or service account), model ID and version, timestamp, request method, token count (input and output), stated purpose (from the purpose claim in the key metadata), and client IP. The audit log is write-once and retained for 7 years for regulated decisions models, 3 years for other models.

Monthly usage reports are generated per model and per consumer, providing: total queries, total tokens, cost attribution (for chargeback), and anomaly flags (usage outside normal business hours, usage spikes, requests from unusual IP ranges). These reports are provided to model owners and reviewed by the information security function quarterly.

4.4 External Partner Model Sharing Governance

Sharing model access with an external partner — a vendor, client, or research institution — requires a governance process separate from internal access provisioning: (1) Legal review: Does the partner have an executed Data Processing Agreement covering the model's training data? Is the acceptable use policy signed? Are there export control restrictions on the model (e.g., if the base model has restricted export controls)? (2) Technical controls: External partner access is Tier 3 only. Rate limiting and token quotas are applied. No artefact export. Keys are scoped to the specific version and purpose agreed in the contract. (3) Audit rights: The organisation retains the right to audit partner usage logs. The partner's key scope includes an explicit purpose field that is logged with each request. (4) Renewal: External partner keys expire after 12 months; renewal requires re-execution of the governance process.

4.5 Model Export Controls

Model artefacts (weights, adapters) are subject to IP classification and export controls independent of API access controls. Three export control categories: No export — applies to models trained on classified or sensitive data, or models where the base model licence restricts redistribution. Controlled export — applies to models that may be shared under a signed IP transfer or licence agreement with appropriate restrictions. Open export — applies to models released under open-source or permissive licences. Export control classification is recorded in the Model Register for each version and is enforced by artefact storage access controls (IAM policies on the artefact bucket).

4.6 Response to Model Access Breach

A model access breach is declared when: an API key is used by an entity other than its registered holder; a key is used for a purpose not stated in its scope; a model artefact is accessed or exfiltrated without authorisation. Response steps: (1) Immediately revoke the compromised key and all keys sharing the same credential lineage. (2) Query the usage audit log to determine: what was accessed, how many inferences were made, what outputs were generated. (3) Assess whether the access constitutes a notifiable breach under APRA CPS 234 Paragraph 36 or Privacy Act Section 26WH (eligible data breach). (4) Notify affected parties per the organisation's data breach notification plan. (5) Root cause analysis: how was the key compromised? (6) Update access controls to prevent recurrence.

5. Architecture Diagram

6. Components

7. Data Flow

7.1 Primary Flow

7.2 Error Flow

8. Security Considerations

8.1 Controls Summary

8.2 OWASP LLM Top 10 Relevance

9. Governance Considerations

9.1 Responsible AI

Model access governance must consider the fairness implications of access tiering: if Tier 1 models are only accessible to a small group of senior employees, and those models make better decisions than the Tier 2 models that frontline workers use, the tiering may perpetuate internal inequality. Tier classification should be based on security and IP risk, not on user seniority.

9.2 Model Risk Management

The access audit log is the evidence record that supports model risk reviews: which models are in use, by which teams, at what volume. The MRM review panel uses this data to prioritise validation resources toward the most heavily-used models.

9.3 Human Approval Gates

Tier 1 access requests require human approval from two named individuals (CISO + AI Governance) before keys are issued. Automated provisioning is not permitted for Tier 1. Tier 2 requires one human approver (manager). Tier 3 requires legal review sign-off before any key is issued.

9.4 Governance Artefacts

10. Operational Considerations

10.1 SLOs

10.2 Monitoring and Logging

Key metrics monitored: API key usage anomalies (sudden spike for a previously low-volume key); usage outside normal business hours for internal service accounts; access attempts with expired or invalid keys (indicates stale consumer integrations); rate limit threshold approach (alert at 80% of quota — indicates consumer may need quota review); external partner usage vs contracted quota.

10.3 Incident Response

Model access incidents are security incidents. The security function owns the response. Model owners are notified and consulted on the impact assessment (was sensitive model output generated? what business function was affected?). The incident response team must have documented authority to revoke keys without model owner approval in an emergency.

10.4 Disaster Recovery

10.5 Capacity Planning

The usage audit store must handle: (peak inference requests/second) × (log record size ~500 bytes) × (retention period in seconds). For a service with 1,000 requests/second and 3-year retention: approximately 50 TB. Columnar storage (BigQuery, Snowflake, Redshift) with compression is appropriate — typical compression ratio 10× reduces to 5 TB effective storage. Plan for analytical query performance: monthly report generation should complete in < 5 minutes.

11. Cost Considerations

11.1 Cost Drivers

11.2 Scaling Risks

Audit log storage scales with inference volume. For very high-volume models (> 100M requests/month), audit log costs can be substantial. Optimise with columnar compression and tiered storage (hot for recent 90 days, cold archive for remainder).

11.3 Optimisations

• Use serverless API Gateway (AWS API Gateway, Azure APIM consumption tier) for variable-volume models — pay per request, not per month.
• Archive audit logs to cold storage (Glacier, Azure Archive) after 90 days for cost reduction of ~80%.
• Implement bulk key audit quarterly rather than continuous monitoring for Tier 2 models — continuous monitoring for Tier 1 only.

11.4 Indicative Cost Range

12. Trade-Off Analysis

12.1 Access Tier Granularity Options

12.2 Architectural Tensions

13. Failure Modes

13.1 Cascading Failure Scenarios

If the Secrets Manager is unavailable, the API Gateway cannot validate keys and will either deny all requests (fail closed — safest) or serve requests without validation (fail open — catastrophic). The architecture must be configured to fail closed: if Secrets Manager is unreachable, the gateway returns 503 and logs the service unavailability. This is the safer default — a brief service outage is recoverable; unvalidated model access is not.

14. Regulatory Considerations

15. Reference Implementations

15.1 AWS

• Identity: AWS IAM Identity Centre for internal users; Cognito for external consumer identity.
• API Gateway: Amazon API Gateway with Lambda authoriser for key validation + version scope check.
• Secrets Manager: AWS Secrets Manager (key storage, rotation, expiry).
• Audit Log: API Gateway execution logs to CloudWatch Logs (write-once); Kinesis Firehose to S3 (immutable, Glacier transition).
• Anomaly Detection: Amazon GuardDuty (threat detection); CloudWatch Anomaly Detection on usage metrics.
• Access Workflow: AWS Service Catalog for self-service access requests; Step Functions for approval routing.

15.2 Azure

• Identity: Microsoft Entra ID (formerly AAD) for all identity; Entra External Identities for partners.
• API Gateway: Azure API Management (APIM) with custom policy for key validation + scope.
• Secrets Manager: Azure Key Vault (key storage, rotation, expiry).
• Audit Log: APIM diagnostic logs to Azure Monitor Log Analytics (immutable workspace setting).
• Anomaly Detection: Microsoft Sentinel with custom analytics rules on model access logs.
• Access Workflow: Azure AD PIM (Privileged Identity Management) for Tier 1 access; Power Automate for request routing.

15.3 GCP

• Identity: Google Cloud Identity for internal; Workload Identity Federation for service accounts.
• API Gateway: Apigee API Management (enterprise) or Cloud Endpoints with ESP for key validation.
• Secrets Manager: Google Secret Manager (version-enabled; rotation).
• Audit Log: Cloud Audit Logs (Admin + Data access) to BigQuery (immutable with dataset lock).
• Anomaly Detection: Chronicle SIEM or Security Command Centre with custom detections.
• Access Workflow: Google Cloud IAM Conditions for scope enforcement; custom approval workflow via Workflows.

15.4 On-Premises / Hybrid

• Identity: On-premises Active Directory or LDAP; integrate with Kong or NGINX via LDAP auth plugin.
• API Gateway: Kong Gateway (enterprise) or NGINX Plus with Lua scripting for key validation + scope.
• Secrets Manager: HashiCorp Vault (dynamic secrets, lease-based expiry, audit log).
• Audit Log: Elasticsearch + Kibana (immutable index lifecycle policy); Splunk for SIEM integration.
• Anomaly Detection: Splunk UEBA or custom Python anomaly detector on Kafka audit event stream.
• Access Workflow: ServiceNow IT Service Management; HashiCorp Vault policies for automated provisioning.

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History