Independent Service Authentication & Authorisation

A zero trust architecture assumes no implicit trust based on network location and verifies every access request regardless of its origin. For AI systems, this means that every service component, from data ingestion to model inference to post-processing, authenticates and authorises independently. The model serving layer should not trust the data pipeline simply because both run within the same VPC.

Each component validates inputs against expected schemas, authenticates the calling service, and verifies authorisation before processing. Service identities are managed through SPIFFE/SPIRE, cloud-native workload identity, or equivalent mechanisms. Human identities flow through the entire request chain, so that audit logs capture which operator’s action triggered which model inference.

Session tokens carry the minimum claims necessary, and token lifetimes are short enough to limit the window of compromise. A model serving endpoint that normally processes fifty requests per second should trigger additional verification if it suddenly receives five hundred. The zero trust architecture, identity and access management framework, and continuous verification mechanisms feed into both Module 9 (cybersecurity) and Module 3 (architecture).

Key outputs

• Independent authentication and authorisation per service component
• Service identity management (SPIFFE/SPIRE or cloud-native workload identity)
• Human identity propagation through the request chain
• Module 9 and Module 3 AISDP documentation

Identity-Based Access (SPIFFE/SPIRE)

In a zero trust architecture, identity-based access replaces network-based trust. Service identities managed through SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment), cloud-native workload identity, or equivalent mechanisms authenticate each microservice in the AI system’s architecture. Every component presents a cryptographically verifiable identity, eliminating the assumption that services within the same network are trustworthy.

SPIFFE assigns each service a unique identity (a SPIFFE ID) and provides short-lived X.509 certificates or JWT tokens that the service uses to authenticate itself to other services. SPIRE manages the lifecycle of these identities: registration, attestation (verifying that the service is running on authorised infrastructure), certificate issuance, and rotation. For cloud-native deployments, managed workload identity services (AWS IAM Roles for Service Accounts, Azure Workload Identity, GCP Workload Identity) provide equivalent functionality integrated with the cloud provider’s IAM layer.

Human identities should flow through the entire request chain so that audit logs capture which operator’s action triggered which model inference. Session tokens carry the minimum claims necessary, and token lifetimes are kept short enough to limit the window of compromise. The identity management architecture is documented in both Module 9 and Module 3.

Key outputs

• Service identity management using SPIFFE/SPIRE or cloud-native workload identity
• Short-lived certificates with automated rotation
• Human identity propagation through request chains
• Module 9 and Module 3 AISDP documentation

Microsegmentation

Microsegmentation at the workload level restricts lateral movement within the AI system’s infrastructure. Even if an attacker compromises the feature engineering service, microsegmentation prevents them from reaching the model artefact store, the training data repository, or the logging infrastructure. This granular isolation limits the blast radius of any individual compromise to the affected component.

The security team defines network policies as allowlists; any traffic not explicitly permitted is denied by default. Kubernetes NetworkPolicies provide pod-level enforcement, restricting communication between pods based on labels, namespaces, and ports. A service mesh (Istio or Linkerd) adds mutual TLS to every service-to-service connection, providing both authentication and encryption at the transport layer.

The microsegmentation policy should reflect the AI system’s architectural boundaries. The data ingestion layer communicates with the feature engineering layer; the feature engineering layer communicates with the model serving layer; the model serving layer communicates with the post-processing layer and the logging layer. Each of these communication paths is explicitly permitted; all other paths are denied. The policy is defined as code, version-controlled, and subject to the same review process as infrastructure changes.

Key outputs

• Allowlist-based network policies per workload
• Kubernetes NetworkPolicies and/or service mesh enforcement
• Policy-as-code with version control and review
• Module 9 AISDP documentation

Continuous Verification

Continuous verification replaces one-time authentication. Access decisions are re-evaluated based on context: the requesting service’s current security posture, the sensitivity of the requested resource, the time of day, and the anomaly score of the request pattern. A model serving endpoint that normally processes fifty requests per second should trigger additional verification if it suddenly receives five hundred.

This principle extends beyond network access to data access, model artefact access, and administrative operations. A service account that normally reads feature data from the feature store should trigger an alert if it attempts to write to the model registry. An administrator who normally accesses the logging infrastructure during business hours should trigger additional authentication if access is attempted at 03:00.

The continuous verification framework integrates with the SIEM to correlate access patterns with known baselines and flag anomalies. The framework is documented in Module 9, including the baseline definitions, the anomaly thresholds, and the escalation procedures for triggered alerts.

Key outputs

• Context-based re-evaluation of access decisions
• Baseline definitions per service and user role
• Anomaly detection integration with SIEM
• Module 9 AISDP documentation