Phase 4
Policy detail
Source: c114 governance-phase2 — S3, everything that hangs off a Policy · surface-map.md §5 · 2026-10-09
One policy, configured in its context. The layer's policy-config shell gives the header, the meta strip and the underlying-control disclosure (copied where it fits, D8); the sections below are the model's: severity as a pair, where it applies as paths, enforcement per scope, exceptions, groups, frameworks, findings, history. Each section carries the delivery phase it ships in (Mark Peterson, 2026-10-09). Severity, scope, enforcement and exceptions act for real against a page-local world through the change sheet, which previews before it applies (S6, drawn here).
policytypical — the Vanta policy: severity overridden, two groups, one exception live and one revoked, enforcement per scope, four changes in history
Policies & Frameworks/P-MCP
Unsanctioned MCP server in use
Qpoint policy · v3ObserveEnforceDetect use of an MCP server that is not sanctioned for the applicable user, team, device, or other governed scope.
State
Active
delivery phase 2 · Foundation
Effective severity
highconfigured · recommended medium
Findings
0 open · 2 resolved see all →
Enforcement
enforced for 2 scopes · observed for 2
Applies through
4 assignments · 14 of 14 people
Groups
3
Frameworks
15 requirements
Show condition— the Rule, internal
mcp_server: sanctioned = falseDefinition
delivery phase 2 · Foundation[policy]What it tests
Detect use of an MCP server that is not sanctioned for the applicable user, team, device, or other governed scope.
Why it matters
MCP servers load tools and context into an agent without review; an unsanctioned one can read, write or exfiltrate on the user's behalf.
What fails it
An agent connects to an MCP server that is not on the sanctioned list for the subject's scope.
What happens on failure
A finding is generated for the subject and resource; where enforcement is on, Qpoint will block the MCP connection.
Configuration
delivery phase 2 · FoundationG7 [policy]What this policy matches, set for your organisation on top of Qpoint's definition. A change is a policy change: it is recorded in History and re-evaluates the open findings it touches (D2).
Seen, not on the list
servers this policy has found, most findings firstVanta MCP2 findings · 0 open · 2 people · last 2026-10-08
Sanctioned MCP servers
3 entries · patterns supported (* and ?)
| Server | Scope | Added by | Last matched | |
|---|---|---|---|---|
| GitHub MCPreviewed 2026-08 | global | Dana (security admin) | 2026-10-08 | |
| Atlassian MCP | global | Dana (security admin) | 2026-10-07 | |
| Postgres MCP (read-only)analytics harnesses only | agent | Sam (GRC lead) | 2026-10-02 | |
| you |
from qdash P6 MCP Server Allow-List
Severity
delivery phase 2 · Foundation[severity]Qpoint recommended medium
Organization configured high
New findings inherit the effective severity. A change never touches scope, observation, enforcement or exceptions, and never re-evaluates (D2); historical findings keep the severity that applied when they were generated.
Where it applies
delivery phase 4 · Applicability & Enforcement[scope]scopeviaspecenforcement herepeople
Organization-widedirect0confirmed · 97 of 10014 of 14
Team: EngineeringEngineering AI Controls →2observe9 of 14
Team: FinanceFinance AI Controls →2confirmed · 38 of 402 of 14
Team: LegalLegal AI Controls →2observe0 of 14
Overlaps
Priya (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Dev (Finance) is reached through Organization-wide and Finance AI Controls — one policy, two paths, no conflict
Jordan (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Alex (Engineering) is reached through Organization-wide and Engineering AI Controls and Finance AI Controls — one policy, two paths, no conflict
Noor (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Mateo (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Hana (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Kofi (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Lena (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Ravi (Engineering) is reached through Organization-wide and Engineering AI Controls — one policy, two paths, no conflict
Effective for a person
Applies through Organization-wide, Engineering AI Controls ·observe decided by Team: Engineering
Enforcement
delivery phase 4 · Applicability & Enforcement[enforce]Where enforcement is on, Qpoint will block the MCP connection. Observation never stops; enforcement builds on the same evaluation. Scopes without an entry are observed.
scopelevelreachbefore you enforce
Organization-wideconfirmed97 of 100 devices0 open findings · 1 exception in this scope
Team: Engineeringobserve—0 open findings · 0 exceptions in this scope
Team: Financeconfirmed38 of 40 devices0 open findings · 0 exceptions in this scope
Team: Legalobserve—0 open findings · 0 exceptions in this scope
Exceptions
delivery phase 4 · Applicability & EnforcementG1 [scope] [enforce]A scoped allow for one resource. Narrows the policy inside a scope; never removes the scope. Enforcement must not block what an exception allows.
allowscopereasonuntilby
Vanta MCPTeam: GRCApproved GRC workflow with the vendor.indefiniteDana (security admin) · 2026-09-28
Vanta MCPTeam: Team ATeam A owns the Vanta integration.revoked 2026-10-14Dana (security admin) · 2026-10-09
Groups that include this policy
delivery phase 3 · Organization[groups]Engineering AI Controls →Team: Engineering · 4 policies · active
Finance AI Controls →Team: Finance · 5 policies · active
Legal AI Controls →Team: Legal · 4 policies · active
Frameworks
delivery phase 3 · Organization[framework]
OWASP LLMLLM03:2025Supply Chain· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →OWASP Top 10 for Agentic ApplicationsASI04Agentic Supply Chain Vulnerabilities· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →OWASP Top 10 for Agentic ApplicationsASI10Rogue Agents· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →NIST AI Risk Management FrameworkGOVERN 1.6Mechanisms are in place to inventory AI systems· this policy contributes observation and enforcementframework →NIST AI Risk Management FrameworkGOVERN 6.1Policies and procedures address third-party AI risks· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →NIST AI Risk Management FrameworkGOVERN 6.2Contingency processes handle failures in high-risk third-party data or AI systems· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →NIST AI Risk Management FrameworkMAP 4.1Risks of AI components, including third-party data and software, are mapped· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →NIST AI Risk Management FrameworkMAP 4.2Internal risk controls for AI components, including third-party, are documented· this policy contributes observation and enforcementframework →NIST AI Risk Management FrameworkMEASURE 3.1Existing, unanticipated and emergent AI risks are tracked· this policy contributes observation and enforcementframework →NIST AI Risk Management FrameworkMANAGE 2.4Mechanisms supersede, disengage or deactivate AI systems that act outside intended use· this policy contributes observation and enforcementframework →NIST AI Risk Management FrameworkMANAGE 3.1Third-party AI risks are monitored and controls applied and documented· this policy contributes observation and enforcementframework →Example: everything at idealEX-2Tools connect only when sanctioned· this policy contributes observation and enforcementframework →SOC 2CC3.2Identify and analyze risks· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →SOC 2CC6.8Prevent or detect unauthorized or malicious software· this policy contributes observation and enforcementframework →SOC 2CC7.1Detect configuration changes and new vulnerabilities· this policy contributes observation and enforcement; the requirement also needs process Qpoint cannot provideframework →Findings
delivery phase 2 · Foundation[policy]see all 2 →0 open
2 resolved
F-AUser A · Team AVanta MCPResolved: enforced
F-BUser B · Team BVanta MCPResolved: enforced
History
delivery phase 2 · Foundation[severity] [scope] [enforce] [reeval]Every auditable change to this policy's configuration. Finding lifecycles point at these rows as their cause.
2026-10-14 08:00Dana (security admin)exception revokeException E-A revoked: Team A moved off VantaCH-5
2026-10-09 11:05qdashenforcement confirmEnforcement confirmed on 97 of 100 devices (Vanta MCP blocked on mac-b1 at 11:05)CH-3
2026-10-09 09:40Dana (security admin)enforcement setEnforcement configured organisation-wide: block the MCP connectionCH-2
2026-10-09 09:15Dana (security admin)exception addException: allow Vanta MCP for Team ACH-1
2026-09-30 15:10Dana (security admin)severity overrideConfigured high (recommended medium)
Composition notes
- Reused (D8): the layer policy-config shell's identity row, meta strip and underlying-control disclosure (copied; the shell renders its own Exceptions block with the old scope words and no resource, so it is not seated as a component — a slot for that block is the layer follow-up); the catalog's severity, category and framework tags; the c64 control-detail definition split; the c65 carve-out table shape for Exceptions.
- Configuration (G7, 2026-10-18): the qdash policy listing's expand-row editors (the layer's PolicyConfigListEditor / DetectorList / LevelSelect / Threshold, seated as they are), on data copied from the qdash catalog (P5–P17), with "Seen, not on the list" made from the policy's findings in the way qdash's pending destinations are. Edits apply at once, add a History row and re-evaluate (D2). Detector hits count this policy's findings, while the layer's caption says "last 24h". Open: S3.6.
- Changed: one severity → the recommended / configured pair with Set and Reset; "satisfies" packs → mapped requirements with what the policy contributes; the activation toggle → State, derived from scope (Active when any assignment reaches someone); exceptions carry a resource and a scope separately, with duration and actor.
- Delivery phases on every section (Mark Peterson, 2026-10-09): Definition, Severity, Findings and History are Foundation; Groups and Frameworks are Organization; Where it applies, Enforcement and Exceptions are Applicability & Enforcement. Under Foundation alone the page is sections 1–5, 11 and 12 with one organization-wide scope.
- The change sheet is S6 and S8b: one panel for add / remove scope, enforce / observe per scope, add / revoke exception; the preview dry-runs the change on a clone (previewChange()) and reports population, reach, overlaps, conflicts and what re-evaluation would do; the audit line shows the History row it will add. S7 reuses it for a group's scope.
- States: ?policyId=P-MCP · P-SENS-SANITIZE · P-TRANSPORT · P-NOPE. Jump pills are plain anchors here; the sticky band and qdash PageHeader are the port's concern.