Areas

Security & Compliance has an Overview and seven area tabs. Overview always shows. Any other tab shows only once it has at least one measured value or a value below its minimum sample. Until then it is hidden, and Overview’s Coverage list shows it with “Turn this on” and its one setup step, which links to its section here.

Tab	Checks it counts	Findings it covers
Privacy	Redaction beyond defaults, PII-leak scoring	PII leak exposure, PII leak regression
Threats	none	Secrets in runs, System-prompt echo
Guardrails	Guardrail verdicts on runs	Guardrail verdicts failing
Agent access	Tool allowlist	Tool surface changed
Content safety	none	none
Red teaming	Current release tested	none
Compliance	none (it maps every check to OWASP)	none

Every tab ends with “Observed by Morse; not an attestation.” Settings on a tab (thresholds, the allowlist) can be changed by owners and admins only; others see them read-only.

Privacy

What the agents’ runs show about personal data, and how your workspace handles it.

PII by category and agent: PII the requester didn’t give the agent, per category and agent, with scored runs, the leak rate and its likely range, weighted by each agent’s runs. The leak threshold (1% by default) is shown beside it.
Redaction evidence: server redaction patterns, SDK masking, and the counts of values redacted. See Redaction evidence.
Retention, hosting and erasure: the sections that also appear on Data handling.
Thresholds: the leak threshold the PII findings use. An owner or admin can change it here.
Findings: when a PII leak finding is open at high severity, the banner at the top of the tab links to it (Open the PII leak finding →); with more than one, the one with the highest rate. Every open finding is listed on Home.

Turn it on: turn on the Pattern-based PII check scorer so leak rates can be measured. See PII-leak scoring.

Threats

Signs that someone is probing an agent or that it is exposing what it should not.

Threat findings: open Secrets in runs and System-prompt echo findings.
Prompt-injection preview: the number of runs flagged by Morse’s injection classifier in the window. The classifier is still being checked for accuracy, so these never open a finding and never appear on a share page. This panel is an internal preview and is off by default.

Threats has no level checks.

Turn it on: turn on the System prompt repeated in output scorer, or send guardrail verdicts. See System prompt repeated in output.

Guardrails

How many of each agent’s runs carry a working verdict from the guardrail you already run.

Guardrail verdicts by agent: runs checked and not checked, with vendor error and unreachable verdicts counted separately, since those runs were not checked.
Findings: Guardrail verdicts failing findings are medium severity, so the banner at the top of the tab does not link to them. Every open finding is listed on Home.

Morse records your guardrail’s verdicts. It does not run a guardrail and is not in the request path.

Turn it on: send the verdict of the guardrail you already run on each request. Morse reads verdicts from LiteLLM, OpenInference and OpenAI Agents guardrail spans. See Guardrail verdicts and Guardrail verdicts on runs.

Agent access

The tools and MCP servers each agent calls, how they change between releases, and which ones the agent is meant to use.

Tools and MCP servers by release: each tool with its server, risk class (pay, exec, send, write, read or unclassified), the release it was first seen on, and whether it is on the allowlist. A description or schema change is recorded per release.
Allowlists: the tools each agent is meant to call. An owner or admin edits an agent’s allowlist here; everyone else sees it read-only. Morse watches calls and is not in the request path. Calls to a tool off the list are listed here, not yet flagged as findings.
Tool change findings: a panel listing every open Tool surface changed finding at every severity, with the agent and tool; open one to accept it or dismiss it. Accepted and dismissed findings drop off the list.
Banner: when the current release gained a pay or exec tool and its Tool surface changed finding is open at high severity, the banner at the top of the tab links to it (Open the finding →). Every open finding is listed on Home.

Turn it on: tools appear here once an agent calls one; then set its allowlist. See Tool allowlist and Tools first seen.

Content safety

Results of the Keyword check scorer (toxicity_v1), which flags outputs against a keyword list; it is not a toxicity classifier. The tab shows once that scorer has scored at least one assessed run in the window. Content safety has no level checks yet, so nothing on this tab changes a level.

Turn it on: in Quality › Score settings (/quality/score-settings), make sure Keyword check has a sample rate above 0%. It is on for every run by default; a sample rate of 0% turns it off. Until it has scored a run, the tab reads “Not measured: the keyword check is off”. If the sample rate is already above 0%, the tab fills in once the keyword check has scored a run in the assessed environment. See Score Settings.

Red teaming

Test runs on each agent’s releases: the seed suite, imported red-team runs and the agent’s Security regressions runs.

Runs by release: each run’s suite, agent, release, date and result. A release passes when every case passes in all 3 runs, for example “Passed 3 of 3 runs on 40 cases”; with fewer runs so far it reads “2 of 3 runs so far on 40 cases, all passed”.
This tab counts Current release tested, the L4 check.

The seed suite

The seed suite (Seed suite v1, Morse-authored) is 40 attack cases mapped to OWASP categories, covering direct injection, system-prompt extraction, PII extraction, tool misuse, jailbreak framings and harmful content. Each case is graded by a fixed rule: a canary or pattern that must not appear, a refusal that must appear, or no tool call of a risky class. Two cases have no fixed rule and use a judge model; they are marked judge-graded.

How to use it:

A teammate with write access installs the suite for an agent. Morse adds the cases to a dataset for that agent and shows a canary, a value unique to your workspace, and a CI snippet.
Place the canary in the agent’s system prompt. A case fails if the canary ever appears in an answer, which shows the system prompt leaked.
Run the suite in your CI 3 times per release, using fresh outputs from your agent. A release passes when every case passes in all 3 runs. See the snippet under Current release tested.

Morse runs no code of yours. Every test runs in your CI and sends its outputs to Morse.

Free runs the seed suite on one agent: the first agent you install it for, on its latest release. That choice stays with the agent. Imports, other agents and release history are on Solo and up.

Imported runs

You can also import a promptfoo or garak result file for a release. Set the agent and the commit on the import so it counts for that agent’s release. Imported runs show on this tab on Solo and up. See Imported test runs.

Turn it on: run the seed suite in your CI.

Compliance

How the checks and findings map to the OWASP Top 10 for LLM Applications (2025) and the OWASP Top 10 for Agentic Applications. Each category shows one of four evidence states:

State	Meaning
Check passed	Every mapped check is met on every agent.
Gap observed	A mapped check is not met, or a finding is open.
Evidence available	Data exists; no pass rule applies.
Not assessed by Morse	No Morse check has assessed this yet.

Each category lists its checks and a note on what Morse does not assess. There is no percentage and no overall pass. Some mappings are evidence only:

Guardrail coverage and failing guardrail verdicts are evidence for LLM01 and ASI01, never a pass. LLM01 shows Check passed on an agent only when its guardrail coverage is met and its seed suite passed on its latest release. ASI01 is never a pass.
The tool allowlist is evidence only for LLM06, because calls off the allowlist are not checked yet.
A tool surface change on a pay or exec tool also counts as a gap on LLM06.

The evidence export also carries AIUC-1 rows that link Morse checks to the AIUC-1 requirements A003, A006, A008, B002, B005 and B006. A row is evidence mapping only, not an AIUC-1 certification.

Turn it on: compliance evidence appears once a check has been measured for an agent.

Remediation

Remediation is a panel on Overview, not a tab. Over the fix lookback (90 days by default) it shows:

Findings opened.
Verified fixes: findings closed as resolved by a person.
Median to fix: the median days from a finding opening to a person verifying its fix.
False-positive rate per signal: of each finding type’s closures, the share a person dismissed as not relevant. Only “not relevant” dismissals count. A change accepted as intended is neither a false positive nor a fix, so it is left out of both the closures and the rate. When a type reaches 30% dismissals over at least 10 closures, the row reads “Morse is tuning this detector”.
Accepted as intended: a column beside the rate that counts, per finding type, the changes an owner or admin accepted (including those closed by saving an allowlist). A footnote on the panel reads “Accepted changes are not counted as closures or in the false-positive rate.”

The evidence export carries the same figures: closures and the rate leave out accepted changes, and an accepted-as-intended count per finding type is listed beside them. Each closed finding in the export carries who closed it (closed_by) and their role in the workspace now (closed_by_role). Both are empty for an open finding or a close Morse made. If the person’s account has since been deleted, closed_by reads “Former member”.

How verification works

Only a person closes a finding as resolved. Morse moves a finding to Awaiting verification once its saved cases pass in your CI 3 times on the fixed release, or once the problem has stopped and the finding has a saved case; a teammate with write access then clicks Verify fix. Only those person-verified fixes count here and toward Open findings owned and fixes verified. See how a finding closes.