# Platform, Privacy & Assurance (PLT) Requirements — 15 Workforce AI Security Controls

> Deployment, data residency, privacy-by-design and vendor assurance. 15 vendor evaluation requirements with acceptance criteria, verification tests and framework mappings.

Source: Harmonic Security, updated October 2026. 15 requirements.

Disclaimer: Mappings indicate relevant contributions, not complete compliance, certification, assurance, a conformity assessment or legal advice. Read each explanation and its scope conditions. Legal applicability depends on jurisdiction, role, use and effective dates. Reference summaries are selective; consult current official sources and full licensed standards before relying on them.

## AUD-003: Restrict and audit access to raw prompt content

- Area: Audit & Evidence

- Verification: Walkthrough
- OWASP adoption tier: Tier-independent
- Formerly: GOV-005
- URL: /r/AUD-003

**Acceptance criteria:** Provide RBAC controls over who can read full prompt content, and record each access to it.

**Why it matters:** Raw prompts are among the most sensitive data the control holds, so access must be limited and logged.

**How to verify:** Only an authorized role can open full prompt content, and each access is recorded.

**OWASP adoption context:** Raw prompt access needs protection across the listed employee AI settings, independently of whether the underlying application is sanctioned.

**Mappings:**
- NIST CSF 2.0: PR.AA-05, PR.DS-01; SOC 2: CC6.3, CC7.2; ISO 27001: A.8.3, A.8.15 — Role-scoped access restricts who can read raw prompts, helping protect stored content, while records of each read supply monitoring evidence. Restrictions must operate across relevant access paths; logged reads still require review and follow-up to detect misuse.
ISO/IEC 27001: Enforce restrictions before access across the UI, exports, APIs, search and administrators. Retain, protect and analyze attributed access logs; logging access does not authorize it.
- NIST AI RMF: MEASURE 2.10 — Restricted and recorded access to identifiable prompt content provides evidence of a treatment for privacy risk. The broader examination and documentation of privacy impacts remain necessary.

## PLT-001: Minimize endpoint and network architecture risk

- Area: Platform, Privacy & Assurance

- Verification: Documentation
- OWASP adoption tier: AT0–AT4
- Formerly: ARC-006
- URL: /r/PLT-001

**Acceptance criteria:** Support agentless and optional-agent patterns, and avoid kernel mode, reverse proxy and major network changes unless justified and tested.

**Why it matters:** Kernel components, proxies and network changes add operational risk that should be justified.

**How to verify:** The vendor documents the deployment architecture and justifies any privileged component.

**OWASP adoption context:** Endpoint and network design risks span the listed employee AI settings; broad coverage should not assume that one deployment architecture fits every surface.

**Mappings:**
- SOC 2: CC6.1, CC8.1; ISO 27001: A.8.27, A.8.29 — Justified, tested deployment choices provide secure-architecture, configuration and change/acceptance-review inputs and can reduce unnecessary privileged interception exposure. Agentless deployment is not intrinsically more secure, and these frameworks do not prohibit kernel components or reverse proxies.
- NIST AI RMF: MAP 4.2 — Agent choices and justified network changes document AI component controls, computing resources and deployment requirements. Tests provide readiness evidence, but the configuration still needs assessment in the actual deployment environment.
- ISO 42001: A.6.2.5 — Justified and tested deployment choices provide readiness evidence when assessed against a defined deployment plan and acceptance criteria. Avoiding kernel components or reverse proxies is not itself resource documentation or proof of safe deployment.
- NIST CSF 2.0: PR.PS-01 — Justified, tested deployment choices can provide configuration-acceptance evidence when assessed against a security baseline. Agentless deployment is not inherently safer, and avoiding a technology class does not establish a network-access safeguard.

## PLT-002: Disclose where decisions are enforced and how the control fails

- Area: Platform, Privacy & Assurance

- Verification: Documentation + Live test
- OWASP adoption tier: AT0–AT4
- Formerly: ARC-015
- URL: /r/PLT-002

**Acceptance criteria:** Enforce before submission, so a blocked payload is never sent and a denied tool call never runs. State where each decision is evaluated (device, browser or cloud), whether TLS interception, a forward proxy or a managed certificate is required, and whether each surface fails open or fails closed.

**Why it matters:** Where a decision runs and how it fails decide whether data is actually stopped.

**How to verify:** The vendor documents enforcement points and failure modes per surface, and the pilot confirms them.

**OWASP adoption context:** Enforcement points and failure behavior can differ by surface, so each listed context needs its own answer.

**Mappings:**
- NIST CSF 2.0: PR.IR-03, PR.DS-02; SOC 2: CC6.7, CC9.1; ISO 27001: A.8.27, A.8.20 — A documented enforcement point and failure mode support secure-architecture and resilience decisions, and show whether data in transit is actually stopped. Neither fail-open nor fail-closed is right in every case; the buyer must choose per surface and test the behavior.
SOC 2: CC6.7 supports restrictions on unauthorized data transfers. Tested fail-open/fail-closed behavior provides evidence for assessing disruption risks and selecting mitigation under CC9.1. The buyer must approve the trade-off and implement the response; documenting a failure mode alone does not establish a complete mitigation plan.
- NIST AI RMF: MAP 4.2; ISO 42001: A.6.2.5 — Knowing where decisions run and what happens when they cannot be made documents the control's deployment requirements and dependencies. It is readiness evidence, not proof of correct behavior under failure.

## PLT-003: Deploy silently through endpoint management with release controls

- Area: Platform, Privacy & Assurance

- Verification: Proof of value
- OWASP adoption tier: AT0–AT4
- Formerly: ARC-016
- URL: /r/PLT-003

**Acceptance criteria:** Deploy and update every component silently through the buyer's endpoint management tools on Windows, macOS and Linux and all major browsers, with release rings, version pinning, rollback and a central view of deployment health by device.

**Why it matters:** Deployment is where enterprise controls most often fail.

**How to verify:** Pilot devices are deployed silently through your endpoint management, with deployment health visible.

**OWASP adoption context:** Endpoint components underpin coverage in every listed context, so deployment health determines real coverage.

**Mappings:**
- NIST CSF 2.0: PR.PS-02, ID.AM-08; SOC 2: CC8.1; ISO 27001: A.8.32, A.8.9 — Managed deployment with release rings, pinning and rollback brings the control's own software under change and configuration management. Deployment health still has to be monitored; an install that fails silently does not meet this requirement.
- NIST AI RMF: MANAGE 2.4; ISO 42001: A.6.2.5 — Staged releases and rollback let the buyer contain a faulty update without losing protection everywhere. They are deployment safeguards, not evidence that each release is correct.

## PLT-004: Support Linux endpoints

- Area: Platform, Privacy & Assurance

- Verification: Live test
- OWASP adoption tier: AT0, AT4
- Formerly: ARC-003
- URL: /r/PLT-004

**Acceptance criteria:** Provide Linux visibility or document an equivalent coverage method.

**Why it matters:** Engineering teams on Linux are often the heaviest AI users.

**How to verify:** AI use on a pilot Linux endpoint is visible, or an equivalent method is shown.

**OWASP adoption context:** Linux support is relevant to shadow applications and code-agent workflows on employee endpoints; the operating system is a coverage choice, not an adoption tier itself.

**Mappings:**
- NIST CSF 2.0: DE.CM-09; ISO 27001: A.8.16 — Linux visibility or a tested network, MCP or API alternative can close an endpoint-monitoring blind spot. Platform support or a documented alternative is not itself anomaly detection or endpoint security; equivalent coverage must be demonstrated.
- SOC 2: CC7.2 — Linux visibility or an equivalent collection route can supply security-monitoring telemetry within the system boundary. Demonstrate actual, attributable security-relevant events; documenting an available method alone does not establish monitoring coverage.

## PLT-005: Support network-based AI traffic detection where the architecture requires it

- Area: Platform, Privacy & Assurance

- Verification: Walkthrough + Documentation
- OWASP adoption tier: AT0–AT2
- Formerly: ARC-001
- URL: /r/PLT-005

**Acceptance criteria:** Integrate with SASE or network controls, identify AI hosts and protocols, and state whether the implementation is passive or inline.

**Why it matters:** Some architectures need network-level coverage, and the difference between passive and inline matters.

**How to verify:** The vendor shows the network integration and states whether it is passive or inline.

**OWASP adoption context:** Shadow, vendor-embedded and platform-integrated AI can create network-visible traffic; whether network inspection is appropriate depends on the architecture.

**Mappings:**
- SOC 2: CC7.2 — AI host and protocol identification adds network and external-service monitoring evidence and informs network-protection design. Passive versus inline coverage identifies the architecture; it does not prove enforced access restrictions, segmentation or secure network configuration.
- NIST AI RMF: MAP 4.2 — Supported protocols, integration points and passive/inline boundaries help document controls for AI components and associated dependencies. The architecture description must be tied to actual deployed coverage.
- ISO 42001: A.4.5 — Network coverage and deployment dependencies inform the computing-resource record for the AI system. An integration claim is not evidence that those resources are adequate or securely operated.
- ISO 27001: A.8.16 — Observed AI hosts and protocols supply network-activity signals for security monitoring. Demonstrate traffic results and missed paths; passive visibility does not establish network enforcement, segmentation or secure configuration.
- NIST CSF 2.0: DE.CM-01, DE.CM-06 — Observed AI hosts and protocols support network monitoring; observable external AI service traffic can also inform service-provider monitoring. Passive detection does not protect a network from unauthorized access, so show the traffic actually observed and the remaining gaps.

## PLT-006: Scale enforcement and telemetry to the full population

- Area: Platform, Privacy & Assurance

- Verification: Documentation + Proof of value
- OWASP adoption tier: AT2, AT4, AT6
- Formerly: ARC-007
- URL: /r/PLT-006

**Acceptance criteria:** Demonstrate capacity, latency and availability, and dashboard, drill-down, search and export performance, at the target scale.

**Why it matters:** A control proven at a few thousand users can behave like a different product at full scale.

**How to verify:** The vendor provides a reference at your scale and demonstrates console performance on pilot data.

**OWASP adoption context:** Population-scale capacity and availability matter across adoption tiers, with the actual workload and deployment determining the test conditions.

**Mappings:**
- NIST CSF 2.0: PR.IR-04; SOC 2: A1.1; ISO 27001: Cl. 9.1, A.8.6 — Recorded capacity, latency and availability at the target population provide resource-adequacy and security-control performance evidence, including availability planning where the SOC 2 Availability category and relevant information are in scope. A benchmark does not establish ongoing capacity monitoring or resilience under all loads; the user-count target is buyer-specific.
ISO/IEC 27001: Define responsibility, frequency and evaluation for security-performance or control-effectiveness measures. Test sustained load and spare capacity; a demonstration does not establish ongoing monitoring or adjustment, and ISO prescribes no particular latency.
- NIST AI RMF: MEASURE 2.3 — Recorded performance tests at deployment-like scale provide measurement evidence and clarify the conditions in which results apply. The buyer must judge whether those conditions represent production use.
- ISO 42001: A.4.5 — Population-scale results inform computing-resource needs for enforcement and telemetry. The target user count is a buyer criterion, and a demonstration does not by itself establish continuing resource adequacy.

## PLT-007: Resist common circumvention paths

- Area: Platform, Privacy & Assurance

- Verification: Live test
- OWASP adoption tier: AT0, AT3, AT4, AT6
- Formerly: ARC-011
- URL: /r/PLT-007

**Acceptance criteria:** Test disabling the extension, switching browser or private mode, personal accounts and desktop or CLI routes; document residual gaps.

**Why it matters:** A control that is easy to bypass gives false assurance.

**How to verify:** Pilot testers try disabling the extension, switching browser and using CLI routes; record residual gaps.

**OWASP adoption context:** Shadow tools and code-agent workflows are primary contexts for testing alternate execution and connection paths that may evade the intended controls.

**Mappings:**
- NIST CSF 2.0: ID.IM-02, ID.RA-01; NIST AI RMF: MEASURE 1.2; ISO 42001: A.6.2.4; SOC 2: CC4.1, CC7.1; ISO 27001: Cl. 9.1, Cl. 6.1.2, A.8.29 — Circumvention tests and recorded residual gaps provide control-effectiveness and verification/acceptance-testing evidence, identify vulnerabilities and inform risk assessment and improvements. Tests must match the deployment and include results; they do not establish that every route was tested or each gap was fixed or accepted by its risk owner.
ISO/IEC 27001: Define responsibility, frequency and evaluation for security-performance or control-effectiveness measures; generic business metrics do not qualify.

## PLT-008: Separate administrative roles, and authenticate them through enterprise SSO

- Area: Platform, Privacy & Assurance

- Verification: Walkthrough
- OWASP adoption tier: Tier-independent
- Formerly: POL-002
- URL: /r/PLT-008

**Acceptance criteria:** Separate policy, approval, administration, investigation and exception duties; authenticate administrators through enterprise SSO; apply least-privilege roles over policy, alerts, raw prompts, exports and dashboards; and record administrative and investigative actions.

**Why it matters:** Whoever can change policy or read prompts holds a lot of power, so roles must be separated and every action recorded.

**How to verify:** Show separate policy, investigation and exception roles, SSO login and the record of an admin action.

**OWASP adoption context:** Administrative role separation and enterprise authentication apply to governance of workforce AI regardless of the end-user adoption tier.

**Mappings:**
- NIST CSF 2.0: GV.RR-02, PR.AA-03, PR.AA-05; SOC 2: CC6.1, CC6.3; ISO 27001: A.5.3, A.8.2, A.8.3, A.8.5, A.8.15 — Separating administrative duties, authenticating administrators through enterprise SSO and restricting access to prompts, exports and policy functions implement authenticated, least-privilege administration. Recorded administrative and investigative actions provide an activity trail. The role assignments must actually prevent conflicting duties; SSO alone does not establish authentication strength.
ISO/IEC 27001: A.5.3: Adopt the organizational process and validate this requirement against the buyer’s actual ISMS scope; product availability is not implementation. A.8.3: Apply restrictions before the operation. A.8.5: SSO must meet buyer-approved authentication requirements; its presence alone does not prove MFA or session strength. A.8.15: Logs need usable attribution and appropriate retention, protection and analysis; a live view alone is insufficient.
- NIST AI RMF: GOVERN 2.1; ISO 42001: A.3.2, Cl. 5.3 — Distinct policy, approval, investigation and exception duties make AI-risk responsibilities and authorities concrete. The roles provide evidence for governance assignments and lines of responsibility; these references do not prescribe enterprise SSO or establish every organization-wide role and communication path.

## PLT-009: Control telemetry residency, retention, encryption, deletion and masking

- Area: Platform, Privacy & Assurance

- Verification: Documentation + Walkthrough
- OWASP adoption tier: AT0, AT4
- Formerly: GOV-004
- URL: /r/PLT-009

**Acceptance criteria:** Validate region, retention period, encryption, deletion behavior, identity masking and exclusions with Legal and Privacy.

**Why it matters:** Residency, retention and masking are the first questions privacy and legal teams ask.

**How to verify:** The vendor documents region, retention, encryption, deletion and masking, and shows the settings.

**OWASP adoption context:** Telemetry protection and retention choices apply across adoption tiers; actual data, deployment location and applicable obligations determine the settings.

**Mappings:**
- NIST CSF 2.0: PR.DS-01, PR.DS-02; SOC 2: CC6.1, CC6.7, C1.1, C1.2, P4.2, P4.3; ISO 27001: A.8.10, A.8.11, A.8.24, A.5.33, A.5.31, A.5.34 — Validation of telemetry encryption, masking, retention and deletion provides assurance inputs for data protection and applicable confidentiality/privacy objectives. Stored and transmitted data need separate consideration; validation alone does not demonstrate operating safeguards, and these frameworks do not prescribe a universal hosting region or retention period.
SOC 2: C1.1/C1.2 require the Confidentiality category and relevant information in scope; P4.2/P4.3 require Privacy and relevant information in scope.
ISO/IEC 27001: These settings do not establish cryptographic key governance.
- NIST AI RMF: MEASURE 2.10 — Legal and Privacy review of masking, location, retention and deletion provides evidence for examination and documentation of AI privacy risk. It is one part of assessing that risk across the system lifecycle.
- ISO 42001: A.4.3 — Telemetry location, retention and handling settings provide facts for documenting AI data resources. A.4.3 does not itself prescribe all the listed safeguards, a hosting region or a retention minimum.

## PLT-010: Offer required hosting regions

- Area: Platform, Privacy & Assurance

- Verification: Documentation
- OWASP adoption tier: Tier-independent
- Formerly: ARC-008
- URL: /r/PLT-010

**Acceptance criteria:** Document processing and storage locations, regional failover, subprocessor boundaries and tenant residency enforcement.

**Why it matters:** Where data is processed and stored is often a contractual and legal requirement.

**How to verify:** The vendor documents processing and storage locations, failover and subprocessor boundaries.

**OWASP adoption context:** Hosting and subprocessor-location choices are cross-tier deployment concerns; adoption tier does not create a universal residency obligation.

**Mappings:**
- NIST CSF 2.0: GV.SC-07; NIST AI RMF: MAP 4.1; SOC 2: CC9.2 — Documented processing locations, regional failover and subprocessor boundaries supply evidence for assessing third-party dependencies and associated supplier and legal risks. Location records do not verify residency enforcement or resolve those risks; US/EU hosting is not a universal requirement.
- ISO 42001: A.4.5, A.10.3 — Hosting, failover and subprocessor details inform computing-resource documentation and supplier responsibilities. Region availability alone does not establish suitable supplier terms or operating residency controls.
- ISO 27001: A.5.23, A.5.31, A.5.34 — Documented locations and residency-enforcement arrangements support the buyer’s cloud-use governance and applicable data-location/privacy obligations. Documentation alone does not demonstrate residency enforcement. US/EU hosting is not universally required by ISO and does not prove lawful transfer, suitable subprocessor agreements or failover arrangements.

## PLT-011: Inspect uploaded content without permanent file retention

- Area: Platform, Privacy & Assurance

- Verification: Documentation + Walkthrough
- OWASP adoption tier: AT0–AT4
- Formerly: GOV-012
- URL: /r/PLT-011

**Acceptance criteria:** Webhook, pointer or in-place inspection so source files stay in enterprise-controlled storage.

**Why it matters:** Copying every uploaded file into another vendor's storage creates a second copy to protect.

**How to verify:** The vendor documents and shows how uploads are inspected without permanent retention.

**OWASP adoption context:** Upload inspection across the listed employee AI contexts should avoid unnecessary permanent copies, regardless of which tool receives the content.

**Mappings:**
- NIST CSF 2.0: PR.DS-10 — In-place or pointer-based inspection can examine data in use while limiting copied personal data and unnecessary retention by the inspection service. Buffers, logs, derived content and subprocessors still need checking; reduced copying does not prove zero retention or an operated leakage-prevention workflow.
- SOC 2: P4.2 — Avoiding permanent copies can support personal-data retention limits when the Privacy category and relevant inspection service are in scope. Verify buffers, logs, derived content and subprocessors; enterprise source-file retention remains separate. Non-retention does not demonstrate that less personal information was collected or read.
- ISO 27001: A.5.34 — Keeping inspected files in enterprise-controlled storage can limit unnecessary PII copies. The privacy link depends on personal data being present and actual copying limits, including caches, previews, derived content and subprocessors. Non-retention does not demonstrate deletion or an operated leakage-prevention workflow.

## PLT-012: Support pseudonymized and aggregate-only views where required

- Area: Platform, Privacy & Assurance

- Verification: Walkthrough
- OWASP adoption tier: Tier-independent
- Formerly: GOV-013
- URL: /r/PLT-012

**Acceptance criteria:** Provide role-scoped views that withhold individual identity while preserving team, department and tool-level analysis, so monitoring can proceed where works councils, unions or local law restrict individual attribution.

**Why it matters:** Where works councils or local law restrict individual attribution, monitoring still has to be possible.

**How to verify:** Pilot data viewed at team level with individual identity withheld.

**OWASP adoption context:** Privacy-appropriate reporting views can be needed across the listed employee AI contexts; the tier itself does not determine whether individual attribution is permissible.

**Mappings:**
- NIST CSF 2.0: GV.OC-02, PR.AA-05; SOC 2: CC6.3, P4.1; ISO 27001: A.8.11, A.8.3, A.5.34 — Role-scoped views that withhold identity implement access restriction and masking while enabling team-level monitoring aligned with relevant stakeholder and privacy requirements. Pseudonymization or aggregation does not guarantee anonymity; the buyer must establish the permitted use and validate re-identification and alternate-access risks.
SOC 2: P4.1 requires the Privacy category and relevant information in scope.
ISO/IEC 27001: Operate masking within the buyer’s ISMS scope and enforce restrictions before access; monitoring or warnings alone are insufficient. Check local law and workforce-consultation duties separately.
- NIST AI RMF: GOVERN 1.1, MEASURE 2.10 — Withholding identity supplies a concrete privacy-risk treatment and evidence for evaluating impacts on individuals and relevant AI obligations. It does not replace the privacy/individual-impact assessment or determine which workforce-monitoring obligations apply.

## PLT-013: Limit monitoring scope by design

- Area: Platform, Privacy & Assurance

- Verification: Walkthrough + Documentation
- OWASP adoption tier: Tier-independent
- Formerly: GOV-016
- URL: /r/PLT-013

**Acceptance criteria:** Monitor AI destinations and agent activity only, not general browsing. Minimize captured content and allow full capture to be switched off, ring-fence named individuals such as executives, exclude personal conversations from analytics, and document the configuration for privacy, legal and workforce review.

**Why it matters:** Works councils and privacy teams judge the architecture, not the policy document.

**How to verify:** Show that non-AI browsing is not captured, a ring-fenced user is excluded, and the configuration is documented.

**OWASP adoption context:** Monitoring reaches employees in every listed context, so scope limits should be enforced on each surface, not only in the browser.

**Mappings:**
- NIST CSF 2.0: GV.OC-03, PR.DS-10; SOC 2: P3.1, P4.1; ISO 27001: A.5.34 — Limiting collection to AI activity, minimizing content and ring-fencing sensitive individuals protects personal information within the monitoring itself. A documented configuration supports review; it does not settle whether the monitoring is lawful.
SOC 2: P3.1, P4.1 require the Privacy category and relevant information in scope.
- NIST AI RMF: MEASURE 2.10; ISO 42001: A.5.4 — Privacy-limited monitoring is a concrete treatment for the privacy risk the control itself creates for employees. It does not replace an impact assessment of the monitoring.

## PLT-014: Maintain security assurance

- Area: Platform, Privacy & Assurance

- Verification: Documentation
- OWASP adoption tier: Tier-independent
- Formerly: ARC-009
- URL: /r/PLT-014

**Acceptance criteria:** Current evidence for SOC 2 Type II and ISO 27001.

**Why it matters:** Standard assurance should be evidenced, not assumed.

**How to verify:** Current SOC 2 Type II report, ISO 27001 certificate and privacy terms are provided.

**OWASP adoption context:** Supplier assurance supports procurement and oversight across adoption tiers, with the buyer’s own scope and use determining the relevant evidence.

**Mappings:**
- NIST CSF 2.0: GV.SC-06, GV.SC-07; NIST AI RMF: GOVERN 6.1, MANAGE 3.1; ISO 42001: A.10.3; SOC 2: CC9.2; ISO 27001: A.5.19, A.5.22 — Current vendor reports and certificates provide inputs to pre-contract due diligence, supplier governance and continuing risk assessment. The buyer must evaluate service scope, reporting period, certificate expiry, findings, exclusions and its own responsibilities; vendor assurance neither certifies the buyer nor satisfies its controls.