25 of 25 requirements
Export view:Runtime Guardrails
GRD · 21- GRD-001Live test
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
- GRD-002Live test
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
- GRD-003Live test
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
- GRD-004Live test
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
- GRD-005Live test
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
- GRD-006Live test
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
- GRD-007Live test
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
- GRD-008Live test
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
- GRD-009Live test
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
- GRD-010Walkthrough
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
- GRD-011Live test + Documentation
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
- GRD-012Live test
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
- GRD-013Live test
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
- GRD-014Live test
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
- GRD-015Live test
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
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
- GRD-017Walkthrough
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
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
- GRD-019Walkthrough + Proof of value
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
- GRD-020Live test
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
- GRD-021Live test
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
Agent & MCP Governance
AGT · 2Govern 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
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
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
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