Memory and Rules

LAST UPDATED: May 10, 2026

Overview

Memory and rules govern how Morpheus AI uses context and enforces policy during Adaptive Tasking investigations. Memory stores contextual signals, like investigation findings, analyst preferences, and lessons learned, to inform later work. Rules define hard constraints that Morpheus applies on every turn.

	Memory	Rules
Behavior	Context is retained and recalled to inform the AI's work.	Requests that violate an active rule are refused.
Lifecycle	Captured automatically during investigation and can also be added explicitly. Append-only history.	Created and managed deliberately by analysts and administrators. Can be enabled or disabled at any time.
Effect	Soft signal that increases relevance and continuity across investigations.	Hard constraint applied to every conversation and investigation.
Best for	Recurring patterns and prior incident context.	Policies the team has defined: "Always do X" or "Never do Y."
Cited	Surfaces in plans and chat as relevant context.	The rule is cited by name when a request is refused because of it.

Memory

Memory is a record of context Morpheus accumulates during investigations and retrieves to inform subsequent cases of similar character.

What Gets Remembered

Memory captures five categories of information from active and resolved investigations:

Investigation observations: Morpheus-identified findings from the incident at hand, including suspicious process trees, confirmed false positives, and novel attack patterns.
IOC context: IPs, domains, hashes, and file paths, paired with the disposition each received (for example, "this hash is internal lab tooling, not malware").
Lessons learned: /Summarize output stored automatically, so future investigations of similar character begin with prior conclusions already in context.
Tool errors and recoveries: integration command failures and the workarounds applied, preventing subsequent analysts from repeating a resolved dead end.
Analyst preferences: explicit instructions (e.g., "I like timestamps in UTC" or "always show me the raw query") stored as soft signals that persist across that analyst's future conversations.

Memory Tiers

Memory is stored at one of three visibility tiers, selected automatically based on the nature of the content being recorded.

Tier	Scope	Visible to
Session (default)	A specific incident	All analysts working that incident
User	One analyst's preferences and shortcuts	Only that analyst, across all incidents
Tenant	Facts, lessons, and patterns applicable across the organization	All analysts in the tenant

A fourth layer, the D3 catalog, provides built-in default knowledge covering command behavior, query syntax, and common attack patterns. This layer is curated by D3 Security and contains no customer data.

READER NOTE

The D3 catalog is read-only from the tenant perspective. Tenant-level memory accumulates separately and never propagates to the catalog or to any other tenant.

How Morpheus Uses Memory

Morpheus searches memory when an analyst submits a question or starts an investigation. Relevant memories can include: IOC associations, similar prior incidents, and recorded tenant-level lessons. A response may reference a prior incident with similar indicators and include the recorded resolution.

Memory retrieval is semantic, matching meaning rather than exact keywords. No special query syntax is required.

Examples - Common Memory Scenarios

EXAMPLE 1 - Recurring IOC

A new incident contains an IP address that appeared in a closed investigation. Morpheus surfaces the closed incident's notes (including the prior disposition of that IP) in the new investigation's context.

EXAMPLE 2 - Analyst Preference

An analyst instructs the Morpheus: "I prefer KQL over FQL." Subsequent chats with that analyst default to KQL examples without requiring the preference to be restated.

EXAMPLE 3 - Phishing Campaign Summary

After a team resolves a phishing campaign, the /Summarize result is stored at tenant tier. Future phishing incidents begin with that summary already in context.

EXAMPLE 4 - Integration Command Failure

A CrowdStrike command times out during an investigation. Morpheus records the failure and the workaround applied. The next time the same condition arises, Morpheus attempts the alternative approach without analyst intervention.

Rules

A Rule is a hard constraint Morpheus applies unconditionally on every conversation turn, regardless of the immediate task or the analyst's request. Unlike memory, which influences behavior softly, a Rule represents a non-negotiable policy.

Examples - Rule Eligibility

Any behavior expressible as "always do X" or "never do Y" qualifies as a Rule.

"Always show the raw FQL query before executing on CrowdStrike."
"Never query production datasets between 09:00 and 17:00 local time."
"Always require manager approval before escalating to Tier 2 on weekends."
"Always reply in Chinese unless the analyst writes in English."
"On phishing incidents, always run the URL reputation lookup before any other action."

Rule Scopes

Each Rule carries one of two scopes, determining which analysts the Rule applies to.

Scope	Set by	Applies to
Personal	The analyst	Only that analyst's conversations and investigations
Organizational	A tenant administrator	Every analyst in the tenant

Personal Rules

Personal rules enable individual analysts to configure ergonomic preferences, such as always displaying timestamps in UTC, without affecting teammates.

Organizational Rules

Organizational rules enforce tenant-wide policy, such as prohibiting auto-remediation on Tier 1 incidents.

An organizational Rule may optionally be tagged to one or more specific sites within the tenant, restricting its applicability to analysts working at those sites. Untagged organizational rules apply tenant-wide.

Site tagging enables a managed security service provider (MSSP) operating across multiple customer sites under a single tenant to maintain per-site policies without cross-site interference.

Rule Precedence

When multiple rules conflict, the system resolves them using the following hierarchy:

System rules
Organizational rules
Personal rules
Current request (instruction submitted in the active message)

The rule name is cited in the reply whenever a rule causes a refusal or override, allowing analysts to identify the applicable policy.

Lifecycle

Rules support full create, read, update, and delete operations, plus an enable/disable toggle that allows temporary deactivation without permanent removal.

Create, Read, Update, and Delete Operations

Create – Personal rules are added from the chat sidebar using Rules > New Rule. Organizational rules are created by administrators from the same interface.

Enable / Disable – Disabled rules remain visible in the management list in a grayed-out state and can be re-enabled at any time. Disabled rules do not influence Morpheus responses or count toward the character budget.

Edit – Rule titles, descriptions, content, site tags, and active states are editable. Each edit increments the rule version number.

Delete – Deleted rules are permanently removed. Personal rules can be deleted only by their owners. Organizational rules can be deleted only by administrators.

Rule Size

The active rules visible to an analyst must not exceed 20,000 characters. Attempts to create or enable rules that exceed the character budget are rejected with a quota-exceeded message.

This limit includes:

Active organizational rules visible to the analyst
Active personal rules owned by the analyst

Disabled rules do not count toward the character budget. No per-rule character limit exists. A single rule may use the analyst's full remaining budget.

NOTE

A typical SOC requires 5,000 to 10,000 characters of policy.

Resolving Rule Budget Limits

When the budget is reached, three options are available:

Disable unused rules. Disabled rules remain available for later re-enablement.
Shorten verbose Rules. Concise constraints (e.g., "never auto-close incidents containing IOC X") perform better than extended procedural narratives.
Move procedures into SOPs. Morpheus consults SOPs on demand, but reads rules on every turn.

Examples - Rule Scope and Precedence

EXAMPLE 1 - Personal Rule

An analyst creates a personal Rule: "Always display timestamps in UTC." The Rule applies only to that analyst's conversations; no other analysts are affected.

EXAMPLE 2 - Organizational Rule

A tenant administrator creates an organizational Rule: "Never approve auto-remediation on Tier 1 incidents." The Rule applies to every analyst in the tenant.

EXAMPLE 3 - Site-Tagged Organizational Rule

An MSSP administrator creates an organizational Rule tagged to Site A: "Always escalate phishing incidents to the Site A SOC manager." Analysts at Site B do not see this Rule and are not subject to it.

EXAMPLE 4 - Precedence in Conflict

A personal Rule states: "Summarize findings in bullet points." An organizational Rule states: "Always present investigation summaries in paragraph form." The organizational Rule takes precedence. The AI produces paragraph-form summaries and cites the organizational Rule by name.

Isolation Guarantees

Morpheus enforces strict scope boundaries for both memory and rules, ensuring that no data crosses tenant or user lines outside explicitly defined parameters.

Tenant Isolation

Memory and rules belonging to one tenant are never visible to any other tenant. Tenant identity is verified at the storage layer on every read and write operation; it is not implemented as a query filter that could be omitted or bypassed. The only knowledge that crosses tenant boundaries is the D3 catalog, which contains no customer data.

Site Isolation

Site-tagged rules and incident-scoped memory respect site boundaries within the tenant. Specifically:

Site-tagged organizational rules are visible only to analysts working at one of the tagged sites.
Untagged organizational rules apply tenant-wide, regardless of site.
Memory captured during an incident inherits that incident's site. Cross-site pivots occur only for IOCs and tenant-level lessons, not for incident-specific notes.

User Isolation

User isolation restricts personal rules and user-tier memory exclusively to the analyst who created them.

Personal rules belong to the analyst who created them. Other analysts cannot access them through the standard chat interface. Administrators can manage analysts' personal rules only through the dedicated admin UI, where cross-user access is explicit and audited.
User-tier memory (analyst preferences) stores analyst preferences and remains private to that analyst. It does not appear in another analyst's chat, including shared-incident work.
Session-tier memory is shared among all analysts working on the same incident.