Harmonic Security

Standards & frameworks · /ISO27001

ISO/IEC 27001:2022

Information security management system, including Annex A controls (Amd 1:2024 noted).

65 requirements · Edition: ISO/IEC 27001:2022 including Annex A, with Amd 1:2024 noted

.md .json

Clause coverage matrix · 41 references

65 of 65 requirements

Export view:
  1. SPM-001Live testCl. 6.1.2 · A.5.9

    Classify previously unseen AI applications on first encounter

    Identify and risk-score an AI application the platform has not seen before, without waiting for a signature, category list or catalog update, and show the evidence behind the classification.

    Why it matters
    Waiting for a catalog update leaves every new tool ungoverned during the period it is most likely to be tried.
    How to verify
    An AI tool the vendor has not seen before is classified and risk-scored on first use, with the evidence shown.

    Area: AI Security Posture Management

  2. SPM-002Live testA.8.16

    Detect AI use at the browser point of use

    Show visibility in Chrome, Edge, Safari and Firefox where supported, including prompt context and account plan.

    Why it matters
    The browser is where most employee AI use happens, so it is the first place visibility has to work.
    How to verify
    Pilot users' AI use in each supported browser appears with prompt context and account plan.

    Area: AI Security Posture Management

  3. SPM-003Live testA.5.9 · A.8.16

    Detect endpoint AI activity beyond the browser

    Identify desktop clients, IDEs, coding assistants, CLI tools and local agents on managed Windows and macOS endpoints.

    Why it matters
    Desktop apps, IDEs and CLI tools carry a growing share of AI use, and browser-only controls never see them.
    How to verify
    Desktop assistants, coding tools and CLI tools used by pilot users appear, attributed to user, device and application.

    Area: AI Security Posture Management

  4. SPM-004Live testA.8.16 · A.5.9

    Detect direct model-provider API calls from employee devices

    Attribute provider, process, device, user and destination for direct API use with no browser involved.

    Why it matters
    Scripts and tools that call model APIs directly bypass every browser control and often carry the most sensitive information.
    How to verify
    A direct API call from a pilot device is attributed to provider, process, user and destination.

    Area: AI Security Posture Management

  5. SPM-005Live testA.5.9 · A.8.16

    Discover local model runtimes and offline AI installations

    Identify installation and running process for tools such as Ollama or LM Studio.

    Why it matters
    Local models move data off the monitored path entirely.
    How to verify
    A local runtime installed on a pilot device is discovered and cataloged.

    Area: AI Security Posture Management

  6. SPM-006Live testA.5.9 · A.5.22

    Discover AI embedded in sanctioned SaaS

    Identify AI features inside existing SaaS tools, such as Google AI Mode.

    Why it matters
    AI features switched on inside approved SaaS create new data flows without a new application to approve.
    How to verify
    A common SaaS application is identified and cataloged as an AI tool due to its embedded AI features.

    Area: AI Security Posture Management

  7. SPM-007Walkthrough + DocumentationA.8.16

    Provide visibility for unmanaged endpoints

    Use approved SaaS/API methods where no endpoint agent can be installed.

    Why it matters
    Contractors and personal devices still reach corporate AI tenants, and some will never run an agent.
    How to verify
    The vendor shows and documents the coverage method for an unmanaged device in your environment.

    Area: AI Security Posture Management

  8. SPM-008Live testAlso in VALA.8.3 · A.5.23

    Distinguish personal, free and guest accounts from sanctioned enterprise tenants

    Report a reliable account-type split at the point of use and allow policy to vary depending on account plan.

    Why it matters
    Contractual protections attach to the enterprise tenant, not the domain. A personal account reaches the same URL with none of them.
    How to verify
    Enterprise, personal and unauthenticated use of the same tool are each identified and handled per policy.

    Area: AI Security Posture Management

  9. SPM-009WalkthroughCl. 6.1.2 · A.5.19

    Risk-score AI tools, connectors and agent workflows

    Configurable factors such as vendor location, training on inputs, trust-center availability, account tier, autonomy, data sensitivity and tool power.

    Why it matters
    The risk in an AI tool usually sits in its data-handling terms, which change without the domain changing.
    How to verify
    Risk scores, with sources and factors, for five tools.

    Area: AI Security Posture Management

  10. SPM-010Live testCl. 8.1 · A.5.10 · A.8.3

    Define default treatment for newly discovered AI services

    Apply a documented default rule until the service is assessed as sanctioned, restricted or prohibited.

    Why it matters
    New tools arrive faster than they can be assessed, so the default decides what happens in the meantime.
    How to verify
    A tool first used during the pilot receives the documented default treatment.

    Area: AI Security Posture Management

  11. SPM-011WalkthroughAlso in AUDA.5.9 · A.5.23

    Support the AI tool approval and review lifecycle

    Define and track unapproved versus approved AI tools and MCP servers.

    Why it matters
    Without a governed approval path, teams route around the control.
    How to verify
    Walk a tool or MCP server request from intake to a recorded decision.

    Area: AI Security Posture Management

  1. GRD-001Live testA.8.12 · A.5.14

    Inspect prompt content in real time before submission

    Classify typed or pasted content at submit time and reach a policy decision before content leaves for the provider.

    Why it matters
    A decision made after submission only tells you what was lost. Inspection before submission is what prevents the loss.
    How to verify
    Sensitive pilot prompts receive a policy decision before they reach the provider; record the decision time.

    Area: Runtime Guardrails

  2. GRD-002Live testA.8.12

    Inspect file uploads before submission

    Apply eligible detection models to uploaded files, summarize the alert, and document coverage differences between files and typed text.

    Why it matters
    Files carry far more data than typed prompts, and many tools treat uploads as a separate, weaker path.
    How to verify
    Sensitive DOCX, PDF, XLSX and CSV uploads are inspected before submission; coverage differences are documented.

    Area: Runtime Guardrails

  3. GRD-003Live testA.8.12 · A.5.12

    Classify sensitive information semantically in ordinary business language

    Detect context and intent without depending on formatted identifiers, regex, file labels or exact keywords, and keep detecting when the user asks to translate, rewrite, summarize or reformat the same content.

    Why it matters
    Most valuable business information has no fixed format. Pattern matching misses it, and rewording defeats it.
    How to verify
    Unstructured sensitive text, including translated and reworded versions, is detected on default configuration.

    Area: Runtime Guardrails

  4. GRD-004Live testA.8.12

    Detect and coach in the languages your workforce uses

    Detect sensitive content in every language the workforce uses, including mixed-language prompts and translated text, and show coaching messages in the employee's language.

    Why it matters
    A control that only reads English leaves much of the workforce unprotected.
    How to verify
    Sensitive information is detected in all the languages required for your workforce.

    Area: Runtime Guardrails

  5. GRD-005Live testA.8.12 · A.5.34

    Detect general, customer, employee and bulk PII

    Correctly classify realistic personal, customer, employee and multi-person records inside contextual prompts.

    Why it matters
    Personal data is the most regulated thing employees paste into AI, often as whole records rather than single fields.
    How to verify
    Realistic customer, employee and multi-person records in pilot prompts are detected on default configuration.

    Area: Runtime Guardrails

  6. GRD-006Live testA.8.12 · A.5.34

    Detect sensitive health and workforce information

    Recognize sensitive patient, clinical-research and employee information in context, including when users summarize or rewrite it. Document supported prompts and file types.

    Why it matters
    Sensitive records can appear in everyday prose, not just structured forms or obvious identifiers.
    How to verify
    Test synthetic health and workforce examples in prompts and supported files, including summarization requests. Compare results with nonsensitive reference text.

    Area: Runtime Guardrails

  7. GRD-007Live testA.8.12 · A.5.12

    Detect confidential commercial information

    Cover pipeline, pricing, contracts, supplier terms, financial projections, M&A and investment data.

    Why it matters
    Pricing, contracts and deal information are often a company's most valuable data and rarely follow a pattern.
    How to verify
    Commercial information in unstructured pilot prompts is detected on default configuration.

    Area: Runtime Guardrails

  8. GRD-008Live testA.8.12 · A.5.17

    Detect secrets, technical configuration and security-operations detail

    Detect standard and homegrown keys, API tokens, credentials, connection strings, internal hostnames, network ranges and infrastructure config, plus narrative incident reports and customer authentication or session detail.

    Why it matters
    One leaked credential or network detail can turn an AI prompt into a breach.
    How to verify
    Standard and homegrown secrets, hostnames and incident details are detected in pilot prompts.

    Area: Runtime Guardrails

  9. GRD-009Live testA.8.12

    Detect proprietary source code and engineering content

    Identify source code exposure across browser, IDE, desktop, CLI and agent workflows.

    Why it matters
    Source code is pasted into AI tools daily, across more surfaces than any other data type.
    How to verify
    Proprietary code is detected in browser, IDE, CLI and agent use by pilot users.

    Area: Runtime Guardrails

  10. GRD-010WalkthroughA.8.15 · A.8.12

    Support granular custom detections

    Let authorized teams maintain custom keywords, client and project identifiers and deal codenames, with an audit trail.

    Why it matters
    Built-in models cannot know your client names, project codes or deal codenames.
    How to verify
    An authorized user adds a project codename and it is detected in the next pilot prompt, with the change audited.

    Area: Runtime Guardrails

  11. GRD-011Live test + DocumentationCl. 9.1 · A.8.29

    Maintain acceptable detection quality

    Report the false-alert proportion: reviewed flagged events judged benign divided by all reviewed flagged events, over a defined window. Document the sample size and composition; under 5% where that target is adopted. Separately report the missed-detection rate using a labeled test corpus: cases expected to be flagged but not flagged divided by all cases expected to be flagged. Include results by data class.

    Why it matters
    False positives decide whether employees and the SOC tolerate a control. A noisy one gets switched off.
    How to verify
    Review a representative sample of flagged pilot events and calculate the false-alert proportion. Separately run a labeled test corpus and calculate the missed-detection rate by data class. Record the numerator, denominator and test scope for each metric. If a denominator is zero, report the rate as not measurable.

    Area: Runtime Guardrails

  12. GRD-012Live testA.8.3 · A.5.15

    Apply policy by user, group, role, department, tool, account plan and risk context

    Show differentiated rules for high-risk and trusted populations, beyond a blanket allow or block, including distinct treatment by approval state: approved, restricted, unapproved, personal, free and unauthorized use. Resolve users to approved identity attributes from the directory or HR system so rules and reports can key off department and role.

    Why it matters
    Different teams carry different risk. One rule for everyone is either too loose or too blunt.
    How to verify
    Two pilot groups get different outcomes for the same content, driven by directory attributes.

    Area: Runtime Guardrails

  13. GRD-013Live testCl. 8.1 · A.8.12 · A.8.15

    Support monitor, warn, block, and restrict actions

    Set the action per policy and let the policy owner configure the intervention choices and block-page wording including removing any bypass, and record both the evaluation and the action. Support a monitor-first rollout. Where policy permits a user to proceed after a warning, require a business justification before continuing. Do not offer an override where policy disables bypass.

    Why it matters
    A control that can only block drives work onto personal devices. Graduated actions let policy match the risk.
    How to verify
    Pilot users see monitor, warn and block outcomes with your wording, and each action is logged. For a warning policy that permits proceeding, show that the user must enter a business justification before continuing. For a blocking policy configured with no bypass, show that the user cannot override the block.

    Area: Runtime Guardrails

  14. GRD-014Live testA.8.12 · A.8.3 · A.5.14

    Prevent sensitive data reaching unauthorized tools or account tiers

    Block before egress while allowing legitimate work and treating sanctioned and personal tiers differently.

    Why it matters
    The same content can be fine in an enterprise tenant and a reportable incident in a personal one.
    How to verify
    The same sensitive content is allowed to the enterprise tenant and stopped for a personal account.

    Area: Runtime Guardrails

  15. GRD-015Live testCl. 7.3 · A.6.3

    Coach employees in the moment

    Show prompt-specific guidance naming the policy issue, and return the same feedback into developer tooling and MCP clients where the action originates there.

    Why it matters
    Coaching that names the issue and the safe alternative changes behavior; an unexplained block teaches nothing.
    How to verify
    Pilot users see prompt-specific guidance with your policy links in the browser, IDE and MCP client.

    Area: Runtime Guardrails

  16. GRD-016Live testAlso in IDRA.5.25 · A.6.3

    Explain each decision to the employee and the analyst

    Show which detection or policy triggered and highlight the content that caused it, both in the employee's coaching message and in the analyst's alert, so the employee can fix the prompt and the analyst can confirm the decision without opening another tool.

    Why it matters
    Explaining the trigger lets the employee fix the prompt and the analyst confirm the decision, which cuts tickets on both sides.
    How to verify
    The coaching message and the alert both show the detection that fired and highlight the content.

    Area: Runtime Guardrails

  17. GRD-017WalkthroughA.5.1 · A.5.10

    Provide sensible policy defaults and no-code authoring

    Editable baseline policies and recommended settings without regex or specialist rule writing.

    Why it matters
    Policy work should not require regex skills.
    How to verify
    Show the default policy set and author a new policy without writing patterns.

    Area: Runtime Guardrails

  18. GRD-018Walkthrough + Proof of valueAlso in AUDCl. 8.1 · A.5.10 · A.5.36

    Turn acceptable-use policy into enforceable scenarios

    Express AUP rules as policies and demonstrate enforcement.

    Why it matters
    An acceptable-use policy only matters if it can be enforced and shown to be enforced.
    How to verify
    Three clauses from your AUP are expressed as policies and successfully tested in your pilot.

    Area: Runtime Guardrails

  19. GRD-019Walkthrough + Proof of valueA.8.32 · A.8.9

    Roll out policy in stages, starting in monitor-only mode

    Start new policies in monitor-only mode, then escalate to coaching and blocking group by group. Policy changes reach every enforcement point within minutes, and every change is recorded with who made it, what changed and when.

    Why it matters
    Nobody should switch on blocking before seeing what monitoring finds.
    How to verify
    A policy moves from monitor to coach to block for one pilot group; record how long changes take to apply.

    Area: Runtime Guardrails

  20. GRD-020Live testA.5.15 · Cl. 6.1.3

    Scope exceptions to a single detection for a defined group

    Grant an exception for one detection, data class or tool to one group, leaving every other protection in place for that group. For example, a deal team can discuss financial projections without losing credential or personal-data protection. Document a named owner, business rationale and review date for each exception.

    Why it matters
    A team that needs latitude on one data type should not lose every other protection.
    How to verify
    One detection is relaxed for a pilot group while all other detections still fire for that group. Show the documented exception owner, business rationale and review date.

    Area: Runtime Guardrails

  21. GRD-021Live testCl. 9.1 · Cl. 8.1

    Keep typical added inline latency under 300 ms

    State the added policy-decision latency and the conditions it was measured under, and document the behavior when a decision is slow or unavailable, including whether the control fails open or closed.

    Why it matters
    Added delay decides whether real-time enforcement is practical or only theoretical.
    How to verify
    Record the added decision time on pilot prompts and the behavior when a decision is slow.

    Area: Runtime Guardrails

  1. IDR-001Live testA.8.15 · A.5.25

    Generate actionable alerts

    Include tool, account type, detection type, policy, action, timestamp, and user or team context.

    Why it matters
    An alert the SOC cannot act on is noise. The fields decide whether triage takes seconds or a ticket.
    How to verify
    Pilot alerts carry every listed field and can be triaged without opening another console.

    Area: AI Detection & Response

  2. IDR-002Live testA.8.16 · A.5.25

    Detect direct and indirect prompt injection attempts.

    Identify, block, and flag prompt injection attempts, whether directly entered into the AI tool or read via connections to third-party tools.

    Why it matters
    Successful prompt injection can lead to sensitive data exfiltration or irreversible destructive agent actions.
    How to verify
    Prompt injection attempts via user input or connected tools are detected and logged with evidence.

    Area: AI Detection & Response

  3. IDR-003Proof of valueAlso in VALCl. 9.1 · A.8.16

    Identify use cases leading to elevated risk behavior.

    Surface the use cases and teams that require additional training on safe usage principles.

    Why it matters
    Repeat exposure and under-use point to where risk reduction or enablement will pay off.
    How to verify
    High-risk use cases and the associated users are identified in a pilot.

    Area: AI Detection & Response

  4. IDR-004Live testA.5.25 · A.8.15

    Integrate with SIEM, SOAR, ticketing, and identity systems

    Use webhooks or APIs to consume relevant employee identity context and to push alerts into logging and response systems.

    Why it matters
    Security alerts need relevant context and need to stream to centralized repositories.
    How to verify
    Pilot events can be enriched with employee identity context and streamed to your SIEM.

    Area: AI Detection & Response

  1. AGT-001Live testAlso in GRDA.8.3 · A.8.15

    Govern tool calls at read, write and delete scope

    Permit a read while refusing write, delete or other destructive actions, with every attempt logged and attributable.

    Why it matters
    One agent can read, write and delete in the same workflow. Allow or deny per app is too blunt.
    How to verify
    Reads to a connected system are allowed while attempts to change or delete information are blocked.

    Area: Agent & MCP Governance

  2. AGT-002Live testAlso in IDRA.8.16 · A.5.18

    Flag destructive, over-scoped or anomalous agent actions

    Detect excessive permissions, unexpected tools, destructive operations, abnormal call sequences and policy bypass.

    Why it matters
    Destructive or unusual agent actions are often the first sign of a hijacked or misconfigured agent.
    How to verify
    A destructive or out-of-pattern tool call in the pilot is flagged with context.

    Area: Agent & MCP Governance

  3. AGT-003Live testAlso in GRDA.8.12

    Inspect sensitive data retrieved through connectors mid-workflow

    Detect when an agent picks up sensitive content from one connnected tool and attemps to share it with a separate tool, even if the user prompt was benign.

    Why it matters
    Connectors pull sensitive data into a conversation even when the user's question is harmless.
    How to verify
    When an agent picks up sensitive information from one tool or dataset and attempts to share it with a different tool, the even is blocked if it violates policy.

    Area: Agent & MCP Governance

  4. AGT-004Live testAlso in IDR, AUDA.8.15

    Attribute every connector and tool call alert to a person

    Answer which server and tool were called, by whom, using which identity, every time an alert or intervention fires.

    Why it matters
    Without attribution, an agent action cannot be investigated or tied to accountability.
    How to verify
    Every pilot tool call alert shows the tool used, the surface, the user identity, and the result.

    Area: Agent & MCP Governance

  5. AGT-005Live testAlso in IDRA.5.26 · A.5.18

    Provide targeted containment for a single connector or tool.

    Disable or revoke one connector, tool, plugin, or integration for a user or group without switching off the whole AI tool.

    Why it matters
    When one connector misbehaves, switching off the whole AI tool punishes everyone.
    How to verify
    One connector is disabled for one pilot group while the AI tool keeps working.

    Area: Agent & MCP Governance

  6. AGT-006Live testAlso in SPMA.5.9 · A.5.19

    Discover the MCP servers and connectors employees attach to their AI clients

    Inventory local and remote MCP servers reached from desktop, IDE and CLI AI tools with owner, scope and exposure.

    Why it matters
    MCP-capable clients now ship inside IDEs, terminals and desktop apps, and each connector is a new path to corporate data.
    How to verify
    Local and remote MCP servers used by pilot users appear with client, owner, scope and exposure.

    Area: Agent & MCP Governance

  7. AGT-007WalkthroughAlso in SPMCl. 6.1.2 · A.5.18

    Map the actions available via each connector.

    Show, per connector/MCP server, what actions are available and which are currently enabled.

    Why it matters
    Approving a connector without knowing which actions it exposes and which are enabled leaves the scope of available functionality unclear.
    How to verify
    For three connectors you name, the console lists the actions each exposes and shows which are currently enabled.

    Area: Agent & MCP Governance

  8. AGT-009Live testAlso in IDRA.8.16 · A.5.25

    Detect indirect prompt injection in content agents read

    Identify malicious instructions from the sources that AI systems are able to read from. Name the originating connector or source, respond before the agent acts where configured, and demonstrate tested coverage and known gaps.

    Why it matters
    A poisoned tool response can turn a trusted agent into an attacker's tool while the user's prompt looks harmless.
    How to verify
    Injected instructions in content returned to pilot users' agents are detected and attributed to their source.

    Area: Agent & MCP Governance

  1. VAL-001Proof of valueCl. 9.1 · A.5.36

    Measure AI usage and adoption by tool, team, function and workflow

    Report volumes, active users, trends and the sanctioned/unsanctioned split at privacy-appropriate aggregation.

    Why it matters
    Usage is the denominator for every cost, risk and value figure.
    How to verify
    Usage by tool, team and function from pilot data, at privacy-appropriate aggregation.

    Area: AI Usage, Spend & Value

  2. VAL-005Proof of valueCl. 9.1 · Cl. 7.3 · A.6.3

    Generate targeted training and enablement recommendations

    Turn observed usage and detection telemetry into prioritized interventions, templates, coaching and sanctioned-tool adoption, aimed at the teams and behaviors that actually generate risk, and measure whether behavior changes.

    Why it matters
    Training aimed at the teams and behaviors that actually create risk works better than blanket training.
    How to verify
    Prioritized enablement recommendations from pilot data, and a measure of whether behavior changed.

    Area: AI Usage, Spend & Value

  3. VAL-006Proof of valueCl. 9.1 · A.6.3

    Measure employee self-remediation

    Record whether a warned user cancels, edits, redirects or proceeds, and calculate a remediation rate where privacy allows.

    Why it matters
    Self-remediation shows whether coaching changes behavior or just records it.
    How to verify
    Share of coached pilot interventions where the employee edits or cancels, and the trend over the pilot.

    Area: AI Usage, Spend & Value

  4. VAL-007WalkthroughCl. 9.1 · Cl. 9.3.2

    Provide role-based dashboards and reporting, up to board level

    Tailor views for Security, IT, GRC, Legal, executives and business units, filter by unit, tool, environment, owner and risk, and summarize adoption, risk, policy, incidents and recommendations with trends and supporting evidence.

    Why it matters
    Each audience, from SOC to board, needs its own view of the same data.
    How to verify
    The same pilot data shown through executive, function and security views.

    Area: AI Usage, Spend & Value

  1. AUD-001WalkthroughAlso in IDRA.8.15 · A.5.34

    Keep a configurable record of each conversation

    Record the prompts, responses, uploaded files and tool calls that make up each conversation, with content capture set per policy: full, partial, metadata-only or none, in line with privacy and retention rules.

    Why it matters
    The conversation, not the single prompt, is the unit an investigator or auditor needs to see.
    How to verify
    Show one pilot conversation's record at full, partial and metadata-only capture settings.

    Area: Audit & Evidence

  2. AUD-002WalkthroughA.5.28

    Export audit and forensic evidence

    API, CSV, webhook or evidence package suitable for audit and incident response use.

    Why it matters
    Evidence has to leave the console in a form legal, HR and auditors can use.
    How to verify
    Export an evidence package for one pilot incident.

    Area: Audit & Evidence

  3. AUD-003WalkthroughAlso in PLTA.8.3 · A.8.15

    Restrict and audit access to raw prompt content

    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.

    Area: Audit & Evidence

  1. PLT-001DocumentationA.8.27 · A.8.29

    Minimize endpoint and network architecture risk

    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.

    Area: Platform, Privacy & Assurance

  2. PLT-002Documentation + Live testAlso in GRDA.8.27 · A.8.20

    Disclose where decisions are enforced and how the control fails

    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.

    Area: Platform, Privacy & Assurance

  3. PLT-003Proof of valueA.8.32 · A.8.9

    Deploy silently through endpoint management with release controls

    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.

    Area: Platform, Privacy & Assurance

  4. PLT-004Live testA.8.16

    Support Linux endpoints

    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.

    Area: Platform, Privacy & Assurance

  5. PLT-005Walkthrough + DocumentationA.8.16

    Support network-based AI traffic detection where the architecture requires it

    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.

    Area: Platform, Privacy & Assurance

  6. PLT-006Documentation + Proof of valueCl. 9.1 · A.8.6

    Scale enforcement and telemetry to the full population

    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.

    Area: Platform, Privacy & Assurance

  7. PLT-007Live testAlso in GRDCl. 9.1 · Cl. 6.1.2 · A.8.29

    Resist common circumvention paths

    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.

    Area: Platform, Privacy & Assurance

  8. PLT-008WalkthroughAlso in AUDA.5.3 · A.8.2 · A.8.3 · A.8.5 · A.8.15

    Separate administrative roles, and authenticate them through enterprise SSO

    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.

    Area: Platform, Privacy & Assurance

  9. PLT-009Documentation + WalkthroughA.8.10 · A.8.11 · A.8.24 · A.5.33 · A.5.31 · A.5.34

    Control telemetry residency, retention, encryption, deletion and masking

    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.

    Area: Platform, Privacy & Assurance

  10. PLT-010DocumentationA.5.23 · A.5.31 · A.5.34

    Offer required hosting regions

    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.

    Area: Platform, Privacy & Assurance

  11. PLT-011Documentation + WalkthroughA.5.34

    Inspect uploaded content without permanent file retention

    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.

    Area: Platform, Privacy & Assurance

  12. PLT-012WalkthroughA.8.11 · A.8.3 · A.5.34

    Support pseudonymized and aggregate-only views where required

    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.

    Area: Platform, Privacy & Assurance

  13. PLT-013Walkthrough + DocumentationA.5.34

    Limit monitoring scope by design

    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.

    Area: Platform, Privacy & Assurance

  14. PLT-014DocumentationA.5.19 · A.5.22

    Maintain security assurance

    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.

    Area: Platform, Privacy & Assurance