@raishin/vanguard-frontier-agentic 2.2.0 → 2.5.0

package/skills/salesforce/salesforce-validation-rule-writer-skill/references/validation-patterns.md

@@ -0,0 +1,214 @@
+# Validation Rule Patterns
+
+## Pattern 1: Required Field When Another Field Has a Value
+
+**Use case:** Require field B when field A is filled.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  NOT(ISBLANK(Field_A__c)),
+  ISBLANK(Field_B__c)
+)
+```
+
+**Error message:** "Field B is required when Field A has a value."
+
+---
+
+## Pattern 2: Required Field When Picklist Equals Value
+
+**Use case:** Require phone when Lead Source is "Outbound Call".
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  TEXT(LeadSource) = "Outbound Call",
+  ISBLANK(Phone)
+)
+```
+
+**Error message:** "Phone is required for Outbound Call leads."
+
+---
+
+## Pattern 3: Prevent Bypass by Profile
+
+**Use case:** Allow only specific profiles to leave a field blank.
+
+```
+AND(
+  NOT(OR(
+    $Profile.Name = "System Administrator",
+    $Profile.Name = "Data Migration User",
+    $Profile.Name = "Integration User"
+  )),
+  TEXT(Stage) = "Closed Won",
+  ISBLANK(Win_Reason__c)
+)
+```
+
+**Guidance:** Always include System Administrator. Add Integration User if
+automated processes (Apex, Flow, REST API) should bypass the rule.
+
+---
+
+## Pattern 4: Conditional Requirement by Record Type
+
+**Use case:** Require additional fields only on "Enterprise" record type.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  RecordType.DeveloperName = "Enterprise",
+  ISBLANK(Executive_Sponsor__c)
+)
+```
+
+**Guidance:** Use `DeveloperName` not `Name`. DeveloperName is stable across
+org refreshes; Name is not.
+
+---
+
+## Pattern 5: Prevent Date in the Past on New Records
+
+**Use case:** Close Date cannot be in the past when creating a new Opportunity.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  ISNEW,
+  NOT(ISNULL(CloseDate)),
+  CloseDate < TODAY
+)
+```
+
+**Error message:** "Close Date must be today or a future date."
+
+---
+
+## Pattern 6: Prevent Stage Demotion
+
+**Use case:** Once Opportunity reaches "Contract Sent", prevent moving back
+to an earlier stage.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  NOT(ISNEW),
+  ISCHANGED(StageName),
+  OR(
+    AND(PRIORVALUE(StageName) = "Contract Sent", StageName = "Proposal/Price Quote"),
+    AND(PRIORVALUE(StageName) = "Contract Sent", StageName = "Needs Analysis"),
+    AND(PRIORVALUE(StageName) = "Closed Won", StageName <> "Closed Won")
+  )
+)
+```
+
+**Error message:** "Stage cannot be moved backwards once Contract Sent. Contact Sales Ops."
+
+---
+
+## Pattern 7: Dependent Picklist Validation (Not Native Dependent Picklist)
+
+**Use case:** Sub-type field must match parent type value combinations.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  NOT(AND(
+    TEXT(Type__c) = "Hardware",
+    OR(
+      TEXT(Sub_Type__c) = "Hardware - Standard",
+      TEXT(Sub_Type__c) = "Hardware - Premium",
+      ISBLANK(Sub_Type__c)
+    )
+  )),
+  NOT(AND(
+    TEXT(Type__c) = "Software",
+    OR(
+      TEXT(Sub_Type__c) = "Software - SaaS",
+      TEXT(Sub_Type__c) = "Software - On-Prem",
+      ISBLANK(Sub_Type__c)
+    )
+  ))
+)
+```
+
+**Guidance:** This pattern validates combinations not covered by native
+dependent picklists. Prefer native dependent picklists where possible;
+use formula validation only when combination logic is complex.
+
+---
+
+## Pattern 8: Prevent Save if Related Records Exist (Cross-Object)
+
+**Use case:** Cannot set Account Status to "Inactive" if related open
+Opportunities exist.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  TEXT(Status__c) = "Inactive",
+  PRIORVALUE(TEXT(Status__c)) <> "Inactive",
+  Account_Open_Opp_Count__c > 0
+)
+```
+
+**Guidance:** Requires a roll-up summary field (`Account_Open_Opp_Count__c`)
+on the Account object. Direct cross-object formula fields cannot aggregate
+child record counts in validation rules.
+
+---
+
+## Pattern 9: Enforce Required Field on Edit When Stage Advances
+
+**Use case:** Require Forecast Category to be set when Stage moves to
+"Proposal/Price Quote" or beyond.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  NOT(ISNEW),
+  ISCHANGED(StageName),
+  OR(
+    TEXT(StageName) = "Proposal/Price Quote",
+    TEXT(StageName) = "Value Proposition",
+    TEXT(StageName) = "Id. Decision Makers",
+    TEXT(StageName) = "Perception Analysis",
+    TEXT(StageName) = "Closed Won"
+  ),
+  ISBLANK(ForecastCategoryName)
+)
+```
+
+---
+
+## Pattern 10: Multi-Select Picklist Validation
+
+**Use case:** Block save if "Sensitive Data" is selected in a multi-select
+picklist without the DPA checkbox being checked.
+
+```
+AND(
+  $Profile.Name <> "System Administrator",
+  INCLUDES(Data_Categories__c, "Sensitive Data"),
+  Data_Processing_Agreement_Signed__c = FALSE
+)
+```
+
+**Error message:** "DPA must be signed before selecting Sensitive Data categories."
+
+---
+
+## Anti-Patterns to Avoid
+
+| Anti-pattern | Why it fails | Fix |
+|---|---|---|
+| `Field__c = ""` | Does not catch null — only catches empty string on text | Use `ISBLANK(Field__c)` |
+| `Field__c = null` | Syntax error in Salesforce formula | Use `ISNULL(Field__c)` |
+| `ISCHANGED` without `NOT(ISNEW)` | Fires on every new record as if field changed | Gate with `NOT(ISNEW)` |
+| `PRIORVALUE` without `NOT(ISNEW)` | Returns null on new records; unexpected behavior | Gate with `NOT(ISNEW)` |
+| No profile bypass | Blocks admins during data migrations and sandbox refreshes | Always include System Administrator bypass |
+| `Text_Picklist__c = "Value"` without TEXT | Syntax error — picklists cannot be compared directly | Use `TEXT(Text_Picklist__c) = "Value"` |
+| Hardcoding Profile Names | Breaks when profile is renamed | Use Custom Permissions for production-grade bypass |

package/skills/salesforce/salesforce-zero-trust-maturity-skill/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: salesforce-zero-trust-maturity-skill
+description: Use this skill when Salesforce deployment zero-trust readiness must be evaluated against NIST SP 800-207 ZTA principles — covering continuous verification configuration, MFA and Always-On MFA status, OAuth token lifetimes, session re-authentication triggers, certificate lifecycle health, CA-signed vs. self-signed certificate posture, mTLS enforcement for external integrations via Named Credentials, contextual risk scoring via Transaction Security Policies, and Event Monitoring behavioral baselines. Trigger phrases: "assess zero-trust maturity", "review Salesforce zero trust", "evaluate continuous verification", "check certificate lifecycle", "audit mTLS configuration", "review adaptive authentication". Do not use when network or infrastructure policies are the focus (use salesforce-infrastructure-audit-skill), when identity and IAM permissioning is the focus (use salesforce-permission-model-review-skill), or when a live deployment or change approval is needed (use salesforce-live-change-approval-protocol). Works from sanitized config exports only; never requests live org access.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-21"
+  category: security
+  lifecycle: experimental
+---
+
+# Salesforce Zero Trust Maturity Skill
+
+## Purpose
+This skill evaluates Salesforce deployment zero-trust readiness using NIST SP 800-207 ZTA principles across five pillars: Device, Network, Application, User, and Automation. It reviews continuous verification configuration, certificate lifecycle health, mTLS enforcement for external integrations, adaptive authentication triggers via Transaction Security Policies, and behavioral baseline coverage via Event Monitoring. It produces a pillar-scored ZTA maturity assessment with a prioritized gap register. It does not access live orgs or execute API calls.
+
+## When to use
+- Zero-trust architecture compliance is required for a regulatory audit or certification.
+- Certificate expiry or rotation schedule gaps need to be identified before a security review.
+- mTLS configuration for Named Credentials or external service integrations must be assessed.
+- Adaptive authentication and Transaction Security Policy coverage is being reviewed.
+- Event Monitoring behavioral baseline presence must be confirmed or documented.
+- An overall NIST ZTA pillar score is needed to benchmark Salesforce deployment maturity.
+
+## When not to use
+- Network access policies, IP allowlisting, sandbox isolation, or Hyperforce controls — use `salesforce-infrastructure-audit-skill`.
+- Identity and IAM permission model review (profiles, permission sets, sharing) — use `salesforce-permission-model-review-skill`.
+- Live deployment or change approval workflow — use `salesforce-live-change-approval-protocol`.
+- Full org posture assessment combining all domains — use `salesforce-org-assessment-skill`.
+
+## Minimum payload (required inputs)
+- MFA configuration export: MFA enforcement status per profile, Always-On MFA status.
+- OAuth token configuration: access token lifetime, refresh token lifetime, connected app policies.
+- Session re-authentication configuration: high-assurance session triggers, re-auth timeout settings.
+- Certificate inventory: certificate names, expiry dates, issuing CA (CA-signed vs. self-signed), rotation schedule.
+- Named Credential configuration: auth protocol per credential (OAuth 2.0, certificate, password), mTLS flag.
+- Transaction Security Policies: policy names, event types monitored, actions configured.
+- Event Monitoring configuration: enabled log types, retention period, SIEM or alerting integration.
+- Context: industry vertical, regulatory framework, approximate integration count.
+
+## Workflow
+
+### 1. Continuous verification inventory
+- Review MFA enforcement status: confirm MFA is enforced for all internal users, not optional or waivable.
+- Flag: MFA not enforced for any profile with `API Enabled`, `Modify All Data`, or `Manage Users`.
+- Review Always-On MFA
+configuration status.
+- Flag: Always-On MFA not enabled in production for orgs with regulated-data classifications.
+- Review OAuth access token lifetime: flag lifetimes > 2 hours for integrations with sensitive object access.
+- Review OAuth refresh token lifetime: flag never-expiring refresh tokens on connected apps used in production.
+- Review session re-authentication triggers: confirm high-assurance sessions are required for sensitive operations (e.g., report export, data download, user management).
+- Flag: high-assurance session triggers absent or not mapped to sensitive operation types.
+
+### 2. Certificate lifecycle health
+- List all certificates in the certificate inventory.
+- Flag: any certificate expiring within 90 days (High) or within 30 days (Critical).
+- Flag: self-signed certificates used for external-facing integrations or Named Credentials.
+- Flag: certificate rotation schedule absent or not documented.
+- Flag: certificates issued by untrusted or internal-only CAs used in regulated integration paths.
+- Record expiry date distribution, CA-signed vs. self-signed ratio, and rotation schedule coverage.
+
+### 3. mTLS review for external integrations
+- Review Named Credential auth protocols.
+- Flag: Named Credentials using username-password auth for integrations that support certificate or OAuth 2.0.
+- Flag: Named Credentials accessing regulated-data endpoints without mTLS configured.
+- Review external service integrations (REST, SOAP, platform events) for mTLS enforcement.
+- Flag: integrations with external payment, identity, or healthcare endpoints lacking mutual TLS.
+- Record mTLS coverage rate across Named Credentials and external service definitions.
+
+### 4. Adaptive access controls
+- Review Transaction Security Policy inventory.
+- Flag: no Transaction Security Policies configured (absence is a gap regardless of org size).
+- Flag: Transaction Security Policies present but configured to notify-only without block or MFA-prompt action for Critical event types (e.g., ExportLeads, ReportExport, ApiAnomalousUsage).
+- Review Event Monitoring configuration.
+- Flag: Event Monitoring not enabled or licensed but not configured.
+- Flag: Event Monitoring enabled but no SIEM, alerting integration, or retention > 30 days configured.
+- Flag: anomaly detection for login, API usage, or report access not configured.
+- Record Transaction Security Policy count, action types, and Event Monitoring log coverage.
+
+### 5. NIST ZTA pillar scoring
+Score each pillar 0–4 using the scale: 0 = Not Present, 1 = Initial, 2 = Developing, 3 = Defined, 4 = Optimized.
+
+| Pillar | Key Controls Assessed |
+|---|---|
+| User (U) | MFA enforcement, Always-On MFA, session re-auth, OAuth token lifetimes |
+| Device (D) | Certificate lifecycle, CA-signed posture, mTLS on Named Credentials |
+| Network (N) | mTLS for external integrations, session IP locking (from infra audit if available) |
+| Application (A) | Transaction Security Policies, Event Monitoring, anomaly detection |
+| Automation (Au) | OAuth refresh token policy, connected app IP restrictions, named credential auth protocols |
+
+- Produce a D/N/A/U/Au score tuple.
+- Flag: any pillar scoring 0 or 1 as a maturity gap requiring remediation roadmap.
+
+### 6. Risk register assembly
+- Consolidate findings from steps 1–5.
+- Assign risk_tier per finding: Critical | High | Medium | Low.
+- Map each finding to its ZTA pillar and relevant NIST SP 800-207 control reference.
+- Identify findings that meet escalation gates from salesforce-risk-taxonomy.
+
+## Evidence requirements
+- Certificate inventory with expiry dates and CA details is required for step 2.
+- Named Credential auth protocol list is required for step 3.
+- Transaction Security Policy and Event Monitoring configuration are required for step 4.
+- Absence of any required input produces an "insufficient evidence" note with assumed worst-case scoring for that pillar.
+
+## Output format
+```
+zero_trust_maturity_findings:
+  continuous_verification_findings:
+    - finding: [description]
+      severity: Critical | High | Medium | Low
+      zta_pillar: User | Device | Network | Application | Automation
+      nist_reference: [NIST SP 800-207 section, if applicable]
+      evidence: [what in the export supports this]
+      recommendation: [brief]
+  certificate_findings: [same structure]
+  mtls_findings: [same structure]
+  adaptive_access_findings: [same structure]
+
+zta_pillar_scores:
+  user: [0-4]
+  device: [0-4]
+  network: [0-4]
+  application: [0-4]
+  automation: [0-4]
+  overall_maturity_tier: Initial | Developing | Defined | Optimized
+
+escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
+summary:
+  critical_count: [count]
+  high_count: [count]
+  pillars_at_initial_or_below: [list]
+assumptions: [list]
+missing_evidence: [what would improve the review]
+```
+
+## Redaction rules
+- Never request secrets, credentials, OAuth tokens, refresh tokens, session IDs, MFA seeds, customer PII.
+- Sanitize org IDs, user IDs before sharing in outputs.
+- Do not include actual certificate private key material or thumbprints in outputs; use expiry dates and CA references only.
+
+## Privilege / data handling rules
+- Works from schema-level exports and sanitized configs only.
+- Certificate expiry findings in regulated industries must be flagged for immediate remediation review.
+- Event Monitoring absence in orgs handling regulated data must trigger compliance specialist notification.
+
+## Handoff rules
+- Hands off to: salesforce-infrastructure-audit-skill (if network or session controls need infrastructure-layer review), salesforce-permission-model-review-skill (if MFA gaps require permission-level remediation), salesforce-case-capsule (for any Critical finding or pillar score of 0).
+- Required handoff fields: matter_id, risk_register (summary), escalation_gates_fired, missing_evidence, assumptions.
+
+## Audit log fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp
+
+## Stop conditions
+- Export contains live credentials, session tokens, certificate private keys, or unredacted customer PII — stop and request sanitized version.
+- Certificate expiry confirmed within 7 days in a production integration path — stop, output ESCALATE, require immediate human action.
+- Never-expiring OAuth refresh tokens confirmed on a production connected app with sensitive object access — stop and require human review before continuing.
+
+## Security notes
+- Read-only static review; never requests live org access or API credentials.
+- Sanitized inputs only; any input containing credentials or private key material must be refused.
+- ZTA pillar scores are advisory maturity indicators; remediation requires human-authorized change management.
+- NIST SP 800-207 references are informational; compliance determination requires qualified assessor review.

package/skills/salesforce/salesforce-zero-trust-maturity-skill/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "salesforce-zero-trust-maturity-skill",
+  "name": "Salesforce Zero Trust Maturity Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Evaluates Salesforce deployment zero-trust readiness against NIST SP 800-207 ZTA principles, scoring five pillars (User, Device, Network, Application, Automation) and reviewing continuous verification, certificate lifecycle, mTLS enforcement, Transaction Security Policies, and Event Monitoring coverage.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm",
+    "https://help.salesforce.com/s/articleView?id=sf.transaction_security_policy_events.htm",
+    "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf"
+  ],
+  "security_notes": "Read-only static review; sanitized inputs only; never requests live org credentials, session tokens, or API access. Risk register is advisory; remediation requires human authorization.",
+  "last_verified": "2026-05-21",
+  "path": "skills/salesforce/salesforce-zero-trust-maturity-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/salesforce/salesforce-zero-trust-maturity-skill/references/continuous-verification-patterns.md

@@ -0,0 +1,209 @@
+# Continuous Verification Patterns Reference
+
+Patterns for implementing continuous identity and session verification
+in Salesforce to support zero trust principles.
+
+---
+
+## What Continuous Verification Means
+
+In a Zero Trust model, authentication is not a one-time gate at login.
+It is continuous:
+- Session validity is re-checked at sensitive operations.
+- Risk signals (new device, new location, anomalous behavior) trigger
+  re-authentication or session downgrade.
+- Tokens are short-lived and rotated.
+
+---
+
+## Adaptive Authentication Patterns
+
+### Pattern 1: High-Assurance Session Gates
+
+Salesforce's High Assurance session mechanism is the native implementation
+of adaptive authentication. Users in a Standard session are challenged to
+step up to High Assurance before accessing sensitive operations.
+
+```
+User logs in with SSO (Standard session)
+  -> Accesses Salesforce CRM, creates Cases, updates Contacts (Standard session OK)
+  -> Attempts to navigate to Setup > Connected Apps (High Assurance required)
+     -> Salesforce presents MFA challenge
+     -> User passes MFA
+     -> Session elevated to High Assurance for 1 hour
+  -> High Assurance session expires
+     -> Next access to sensitive operation triggers re-challenge
+```
+
+**Configuring High Assurance requirements:**
+```
+Path: Setup > Security > Session Settings > Session Security Levels
+Map permission to High Assurance level:
+  - Manage Users
+  - Manage Connected Apps
+  - Manage Certificates
+  - View Encrypted Data
+  - Manage Remote Sites
+```
+
+### Pattern 2: Per-Permission-Set High Assurance
+
+Require step-up authentication when a user activates a specific Permission Set:
+
+```
+Setup > Permission Sets > [Sensitive Permission Set]
+  Session Activation Required = High Assurance
+```
+
+Users who try to exercise permissions in this set during a Standard session
+are prompted to step up before the Permission Set activates.
+
+---
+
+## Contextual Risk Signals in Salesforce
+
+Salesforce cannot natively evaluate all risk signals (device posture, geolocation
+velocity) without integration with an external IdP or CASB. Here is the split:
+
+| Risk Signal | Available in Salesforce Native | Requires Integration |
+|------------|-------------------------------|---------------------|
+| Login from new IP | Via LoginHistory monitoring | SIEM alert only |
+| Login from new device | Salesforce Device Activation challenge | Partial native |
+| Login outside normal hours | Login IP/hour restrictions on profile | SIEM for anomaly |
+| Credential compromise | No | IdP or CASB required |
+| Device compliance failure | No | MDM + IdP required |
+| MFA bypass attempt | Via Failed LoginHistory | SIEM alert |
+| Rapid record access (possible bot) | Event Monitoring | SIEM or CASB |
+
+### Device Activation (Native)
+
+When a user logs in from an unrecognized device, Salesforce sends a
+verification email or SMS. This is a lightweight form of device signal.
+
+```
+Path: Setup > Security > Session Settings
+Setting: Require Email Confirmation for Device Activation = Enabled
+```
+
+---
+
+## Token Rotation Patterns
+
+### OAuth Refresh Token Rotation
+
+For connected apps using Authorization Code + refresh token flow:
+
+```
+Best practice OAuth token lifecycle:
+1. Issue access token (short-lived: 15 minutes to 2 hours)
+2. Issue refresh token (long-lived: configurable)
+3. When access token expires: client uses refresh token to get new access token
+4. Rotate: issue new refresh token with each token refresh (invalidate old)
+5. If refresh token not used within expiry: force re-authentication
+```
+
+**Salesforce Connected App token policy:**
+```
+Setup > Apps > Connected Apps > [App] > OAuth Policies
+  Access Token Valid For: 2 hours (recommended maximum)
+  Refresh Token Policy: Expire refresh token after: 90 days
+    OR: Expire refresh token if not used for: 30 days
+```
+
+**Rotate on use pattern** (most secure):
+```
+Refresh Token Policy: Immediately expire old refresh token
+```
+This means every token refresh issues a new refresh token and invalidates
+the previous one — replay of captured refresh tokens fails.
+
+### JWT Bearer Flow (No Refresh Token)
+
+For server-to-server integrations, the JWT Bearer flow is preferred over
+refresh tokens:
+- No persistent token to steal.
+- Short-lived JWT (max 5 minute validity window).
+- Authentication re-occurs on every access token request.
+
+```python
+# JWT Bearer flow: no persistent token stored
+import jwt, time, requests
+
+def get_salesforce_token(client_id, private_key, username, audience):
+    payload = {
+        'iss': client_id,
+        'sub': username,
+        'aud': audience,
+        'exp': int(time.time) + 300  # 5 minute validity
+    }
+    assertion = jwt.encode(payload, private_key, algorithm='RS256')
+
+    response = requests.post(f'{audience}/services/oauth2/token', data={
+        'grant_type': 'urn:ietf:params:oauth:grant-type:jwt-bearer',
+        'assertion': assertion
+    })
+    return response.json['access_token']
+    # Call this function each time a token is needed — no caching
+```
+
+---
+
+## Event Monitoring for Continuous Verification
+
+Event Monitoring
+(a Salesforce Shield or add-on product)
+provides real-time and log-based access to user activity events.
+
+### Key Event Types for ZTA Monitoring
+
+| Event Type | API Name | What to Alert On |
+|------------|----------|-----------------|
+| Login | `LoginEvent` | Failed logins > 5 per hour per user |
+| Logout | `LogoutEvent` | Unexpected logouts (session hijack indicator) |
+| API calls | `ApiEvent` | Volume spikes, unusual endpoints |
+| Report export | `ReportExportEvent` | Any export by non-authorized user |
+| List view access | `ListViewEvent` | Bulk queries on sensitive objects |
+| Permission change | `PermissionSetAssignmentEvent` | Any assignment to high-privilege sets |
+| SOQL query | `QueryEvent` | Queries touching regulated fields |
+| Field history | `FieldHistoryEvent` | Changes to PII or financial fields |
+
+### Real-Time Event Monitoring (Streaming API)
+
+```apex
+// Subscribe to real-time events via Salesforce Streaming API
+// Example: Monitor permission set assignments as they happen
+// Subscribe to: /event/PermissionSetAssignmentEvent (or equivalent)
+
+// In an external monitoring tool (Node.js example):
+const faye = require('faye');
+const client = new faye.Client(instanceUrl + '/cometd/59.0', {
+    timeout: 120,
+    retry: 5
+});
+
+client.setHeader('Authorization', 'Bearer ' + accessToken);
+client.subscribe('/event/PermissionSetAssignmentEvent', event => {
+    const data = event.data.payload;
+    if (data.PermissionSet.IsHighPrivilege__c) {
+        sendAlert('High-privilege permission set assigned to ' + data.Assignee.Username);
+    }
+});
+```
+
+---
+
+## Continuous Verification Checklist
+
+- [ ] MFA enforced for all user logins (not just login page — also API).
+- [ ] High Assurance sessions required for admin operations.
+- [ ] Per-Permission-Set activation requires High Assurance for privileged sets.
+- [ ] OAuth access tokens expire in <= 2 hours.
+- [ ] Refresh tokens rotate on use (invalidate previous on refresh).
+- [ ] Server-to-server integrations use JWT Bearer (no persistent refresh token).
+- [ ] Event Monitoring enabled and logs exported to SIEM.
+- [ ] Alert rule: 5+ failed logins per user per hour.
+- [ ] Alert rule: Report export by user not in authorized-exporter list.
+- [ ] Alert rule: High-privilege permission set assigned outside business hours.
+- [ ] Alert rule: API volume spike (> 10x baseline per user per hour).
+- [ ] Session lock-to-IP enabled to prevent token reuse from different IPs.
+- [ ] Device activation challenge enabled for new device logins.