When asked to design a zero trust architecture, always produce these four sections in order:

1. Trust Architecture — overall model: identity providers, policy engine, policy enforcement points, trust zones
2. Access Flow — step-by-step sequence of how a request is authenticated, authorized, and granted access
3. Verification Layer — mechanisms for continuous verification (device posture, MFA, session risk scoring, re-auth triggers)
4. Security Boundary — micro-segmentation map: what's isolated from what, and enforcement points between segments

Never assume implicit trust based on network location (internal IP, VPN, corporate LAN). Every access request must be treated as untrusted until verified.

Progress:

• Step 1: Identify the assets, users, services, and data flows in scope
• Step 2: Map identity sources (human users, service accounts, workloads) and their verification methods
• Step 3: Define least-privilege policies — what each identity needs, nothing more
• Step 4: Design micro-segmentation — group resources into isolated zones with explicit allow-rules
• Step 5: Define the access flow (request → authenticate → authorize → verify context → grant/deny → log)
• Step 6: Specify continuous verification triggers (anomaly detection, session timeout, device compliance re-check)
• Step 7: Output the four required sections

Step details

Identity verification: Always require strong authentication (MFA, certificate-based, or workload identity via SPIFFE/mTLS). Never rely on network location or a single static credential as sufficient proof.

Least privilege: Define access at the most granular level possible — specific resource, specific action, time-bound if feasible. Default posture is deny-all; explicitly allow only what's justified.

Micro-segmentation: Break the environment into small, isolated zones (per-service, per-environment, per-data-sensitivity-tier). Each segment boundary must have its own enforcement point (firewall rule, service mesh policy, API gateway rule) — no flat network trust.

Trust validation: Trust is never permanent. Define re-verification triggers: session expiry, device posture change, geo/behavior anomaly, privilege escalation attempt.

Example 1: Input: "Design zero trust access for an internal HR system used by employees and a third-party payroll API."

Output:

Trust Architecture:
- IdP: corporate SSO (SAML/OIDC) issuing short-lived tokens
- Policy Engine: centralized PDP evaluating identity, device posture, resource sensitivity
- PEPs: API gateway (HR app), sidecar proxy (payroll integration)
- Trust zones: [Employee Zone] -> [HR App Zone] -> [Payroll Integration Zone] -> [External Payroll API]

Access Flow:
1. Employee authenticates via SSO + MFA -> short-lived JWT issued
2. Request hits API gateway (PEP) -> token validated, device posture checked
3. PDP evaluates policy: role=HR-staff, resource=employee-records, action=read -> allow/deny
4. If allowed, HR app service calls payroll API via mTLS service identity (not user token)
5. All requests logged with identity, device, decision, timestamp

Verification Layer:
- MFA at login; step-up auth for salary/bank-detail changes
- Device compliance check (managed device, disk encryption) on each session
- Continuous risk scoring: flag impossible-travel logins, force re-auth
- Session TTL: 15 min idle timeout, 8 hr max session

Security Boundary:
- Zone 1 (Employee endpoints) <-PEP-> Zone 2 (HR App)
- Zone 2 (HR App) <-PEP-> Zone 3 (Payroll Integration Service, mTLS only)
- Zone 3 <-PEP-> External Payroll API (outbound allow-list, no inbound)
- No direct employee-to-payroll-API path exists

Example 2: Input: "We have a flat internal network where any server can reach any other server. Apply zero trust."

Output:

Trust Architecture:
- Replace implicit network trust with per-workload identity (mTLS certs via service mesh)
- Policy engine defines explicit service-to-service allow rules
- Default deny-all east-west traffic

Access Flow:
1. Service A requests connection to Service B
2. Mesh sidecar presents mTLS cert (workload identity)
3. Authorization policy checked: is A->B communication explicitly allowed?
4. If not in allow-list, connection denied and logged
5. If allowed, encrypted channel established, request proceeds

Verification Layer:
- Workload identity rotated every 24h (short-lived certs)
- Runtime policy audit: alert on new/unexpected service-to-service calls
- Anomaly detection on traffic volume/pattern per service pair

Security Boundary:
- Segment by environment: prod / staging / dev (no cross-talk)
- Segment by data sensitivity: PII-handling services isolated from public-facing services
- Each segment boundary enforced by service mesh policy, not just VLAN/subnet