Skip to Content
Product GuideSecurity & ComplianceOverview

Security & Compliance

Security & Compliance is a module in the Evaluate group of the sidebar, at /security-compliance. It shows what Morse measured from your traces, settings and test runs: what it saw go wrong, what it can and cannot see for each agent, what a person has fixed and verified, and a capability level for each agent and for the workspace.

Everything here is Observed by Morse; not an attestation. A figure describes the traffic Morse received in a stated window and environment. It says nothing about traffic Morse never saw, and it is not a certification against any standard.

This page explains how scope and levels work. The other pages are reference for the links the module shows:

  • Checks: one section per check behind the level, with what it needs and how to meet it.
  • Findings: one section per finding type, with what it means, how to fix it and how to verify the fix.
  • Areas: one section per tab of the module.

What Morse assesses

Every number, finding and level uses assessed runs only.

  • Assessed environment. One per workspace. By default it is the environment with the most non-synthetic traces in the last 14 days; a tie goes to the default environment. An admin can override it. Every headline names the environment it measures.
  • Assessed run. A non-synthetic trace of a non-internal agent in the assessed environment.
  • Assessed agent. A non-internal agent with assessed runs in the assessed window.
  • Assessed window. 14 days by default (see Thresholds). Each figure shows its own window.
  • Current release. An agent’s current release is the git revision of its newest assessed trace, not the latest deploy event, so a rollback moves it back. A revision that is empty or shorter than 7 characters counts as no release. See Git revision for how the SDK records it.
  • Release match. A test run’s commit and a release match when both are at least 7 characters and one is a case-insensitive prefix of the other.

Check states

Every check has one of five states. A state is never turned into a pass, a zero or “none found”.

StateReads asWhat it means
metMetThe check’s rule holds in the window.
not_metNot metMorse has data and the rule does not hold.
below_min_nBelow minimum sample (n = 12 of 20)There is data, but less than the check needs.
not_measuredNot measured for <agent>No data to check yet, such as when the scorer is off.
not_applicableNot applicable: this agent has no toolsThe subject is absent. Only the tool allowlist check uses this state.

Every check that is not met, below the minimum sample or not measured carries one next step and a link to its section on the Checks page.

How levels work

Each assessed agent gets a level from L1 to L5. The level is cumulative: an agent’s level is the highest one whose checks, and every lower level’s checks, are all met or not applicable. An agent that does not meet L1 has no level.

LevelNameChecks
L1ObservedReal traces in the assessed environment
L2Privacy measuredRedaction beyond defaults and PII-leak scoring
L3Guardrail in placeGuardrail verdicts on runs and Tool allowlist
L4Release testedCurrent release tested
L5Fixes verifiedOpen findings owned and fixes verified

Cumulative matters because the L5 check is met when there are no findings at all. Without the rule, an agent that had tested nothing could jump to L5.

Workspace level

The workspace level is the lowest level among the agents that count.

  • An agent whose only gaps are “not measured yet” (too few runs for a check, or no CI test run on its current release yet) is left out of the workspace level and listed as Not counted yet, with what it still needs, for example “needs 8 more runs” or “needs a CI test run on its current release”.
  • An agent with a measured gap, such as a failed CI run, counts.
  • An agent with an open high-severity finding always counts.
  • When no agent counts yet, the workspace shows No level yet instead of a level.

The cap for open high-severity findings

An open high-severity finding holds its agent at L2 until a person verifies the fix or closes the finding as dismissed or, for a tool change, accepted as intended. A finding that has gone quiet but is not yet verified still counts. The agent’s row shows “Capped: 1 open high finding” and the level it would have without the cap, and the workspace level uses the capped level. Open high-severity findings are also pinned above the level on Overview, so the level never hides them.

PII scoring label

While the PII detector is still being validated, an agent at L2 or higher carries the line “PII scoring uses a detector that is still being validated; check the example runs before acting.”

Next steps

Overview lists numbered next steps: first a remedy for each open high-severity finding (up to 3), then the lowest unmet check across your agents, one per check, with how many agents share it. Each step has one action, a link to these docs and, for a CI or SDK change, a snippet you can copy.

Security readiness report

Once an agent has assessed runs, Overview shows a Security readiness report: what Morse observed, coverage gaps (including agents that are not counted yet), the top next steps and the seed suite block. It replaces the level summary for 7 days after the first assessed runs, or until the first person-verified fix. After that it opens from a link in the level summary. Its figures are live, not a frozen copy.

Roles

ActionRead-onlyWriteOwner or admin
View every page, level and findingYesYesYes
Confirm a finding, dismiss it, verify a fixNoYesYes
Save flagged runs as test cases; install the seed suiteNoYesYes
Export evidence; create or revoke a share linkNoNoYes
Change the assessed environment and thresholdsNoNoYes
Edit a tool allowlistNoNoYes
Accept a tool change as intendedNoNoYes

A workspace viewer is read-only, a member has write access, and owners and admins are admins here.

Owners and admins on Solo and up can share what Morse observed with a prospect or auditor.

  • Share link. A read-only page with configuration facts, open findings, attributed test results and vendor guardrail verdicts. Anyone with the link can read it. It expires 30 days after you create it, and you can revoke it at any time from Manage links; revoking takes effect at once.
  • Evidence export. A Markdown or JSON file for a security questionnaire: configuration facts, attributed test results, open findings with their owner state, findings closed in the last 90 days with their reason and who closed them, remediation history and the OWASP and AIUC-1 rows.

Both follow the same rule. They include facts from settings, vendor reports, attributed test runs and open findings. Every open finding is listed with its owner state: confirmed findings by title, detector-based findings as a count. Detector-based measurements, such as the PII leak rate, and levels are left out until the detector’s accuracy has been independently checked, and the page says so. Both carry the window, the environment and “Observed by Morse; not an attestation”.

Plans

Free keeps every page, level and finding in this module, the readiness report, viewing share links, and the seed suite for one agent: the first agent you install it for, on its latest release. Solo and up add share links, the evidence export, saving test cases (and so verifying a fix in CI), and the seed suite on every agent with results kept across releases.

Before you have data

Until an agent has assessed runs, the module has nothing to assess. Overview shows no level, and each area that has no measured value is hidden and listed on Overview with “Turn this on” and its setup step. A value Morse cannot measure reads “Not measured” with what to turn on, never zero.

  • Checks: what each level needs.
  • Findings: what each finding means and how to close it.
  • Areas: what each tab shows.
  • Data handling: redaction, retention, hosting and erasure.
  • CI Gate: the fresh-output CI runs the seed suite and regression cases use.
Last updated on