- Tactic: [Primary Tactic (ATK-TAXXXX); Secondary Tactic (ATK-TAXXXX), if applicable]
- Framework Profiles: [SAF Core / MCP / Code-Agent / RAG and Memory / Financial-Agent / Model-Lifecycle]
- Lifecycle Status: [Active / Deprecated]
- Technique ID: SAF-T[XXXX]
- Research Packet: research/techniques/SAF-TXXXX
- Traceability Ledger: traceability-ledger.yml
- Documentation Status: [Draft / Under Review / Stable / Deprecated]
- Evidence Status: [Observed / Demonstrated / Research-Derived / Hypothesized]
- Severity: [Critical / High / Medium / Low]
- Severity Rationale: [One sentence explaining the rating and the conditions under which it applies]
- First Observed: [YYYY-MM-DD and source / Not observed in production]
- Last Updated: [YYYY-MM-DD]
[State precisely what adversary behavior this technique covers and the security boundary it crosses.]
- [Behavior, mechanism, or outcome included in this technique]
- [Relevant MCP component, capability, or trust boundary]
- [Closely related behavior covered by another SAF technique]
- [Behavior that may look similar but has a different mechanism or outcome]
[Explain how an analyst can distinguish this technique from its nearest neighbors. Name and link those techniques where appropriate.]
[Define the technique in two to four concise paragraphs. Explain the adversary objective, the MCP-specific mechanism, the affected trust boundary, and why normal platform controls may not prevent it.]
[Separate demonstrated behavior from inference. Do not place mitigation guidance or unsupported impact claims in this section.]
- Primary Vector: [Principal delivery or exploitation path]
- Secondary Vectors:
- [Secondary vector and when it applies]
- [Secondary vector and when it applies]
- Affected Components: [MCP host, client, server, transport, tool, resource, prompt, model, memory, registry, or external service]
- Trust Boundary Crossed: [Boundary the adversary crosses or abuses]
- [Required access, capability, configuration, or victim action]
- [Required weakness or missing control]
- [Environmental condition, if applicable]
- Reconnaissance or Setup: [How the adversary identifies or prepares the opportunity]
- Delivery: [How attacker-controlled input, software, identity, or state reaches the target]
- Trigger or Execution: [The MCP or agent action that activates the technique]
- Boundary Crossing: [The security decision, trust assumption, or control that fails]
- Objective: [The immediate adversary outcome]
- Follow-On Activity: [Likely persistence, escalation, collection, exfiltration, or impact]
[Describe one realistic end-to-end scenario. Identify the actor, entry point, vulnerable assumption, observable behavior, and outcome.]
{
"example": "Use a sanitized MCP message, tool definition, event, or configuration",
"placeholder": "Do not include live credentials, destructive commands, or operational secrets"
}
| ID or Name | Mechanism | Distinguishing Observables |
|---|
| SAF-T[XXXX].001 or [Variant Name] | [How this variant works] | [Signals unique to the variant] |
flowchart LR
A[Adversary-controlled input] --> B[MCP or agent component]
B --> C[Failed trust boundary]
C --> D[Adversary objective]
| Claim ID | Claim | Evidence Status | Source ID and Source | Limitations |
|---|
| SAF-T[XXXX]-C001 | [Core technique claim] | [Observed / Demonstrated / Research-Derived / Hypothesized] | SRC-[source]: Primary source | [What the source does not establish] |
- Affected Environments: [Known products, deployment patterns, or preconditions]
- Known Exploitation: [Observed activity, public demonstrations, or none identified]
- Available Protections: [Relevant platform controls, patches, or protocol guidance]
- Residual Risk: [What remains possible after common protections are applied]
| Event or Identifier | Date and Environment | Impact and Remediation | Relationship to This Technique | Evidence Limitation |
|---|
| [Incident, CVE, GHSA, or demonstration] | [Event/publication date; affected product, versions, and configuration] | [Observed or bounded potential consequence; patch or mitigation status] | [Direct production incident / direct vulnerability / direct demonstration / enabling vulnerability / adjacent] | [What the evidence does not establish] |
[Describe only what the cited source establishes. Explain the connection to this technique and any important differences from the documented MCP scenario.]
| Dimension | Rating | Rationale and Conditions |
|---|
| Confidentiality | [Critical / High / Medium / Low / None] | [Data exposed and required conditions] |
| Integrity | [Critical / High / Medium / Low / None] | [State or decisions altered and required conditions] |
| Availability | [Critical / High / Medium / Low / None] | [Disruption and required conditions] |
| Scope | [Local / Adjacent / Multi-System / Ecosystem-Wide] | [Expected blast radius and limiting factors] |
- Severity increases when: [Privileges, connectivity, automation, sensitive data, or missing controls]
- Severity decreases when: [Isolation, scoped credentials, approval gates, or other constraints]
| Source | Events or Actions | Required Fields | Collection Notes |
|---|
| [MCP host/client/server audit log] | [Relevant request, response, or lifecycle event] | [Timestamp, session, actor, server, tool, arguments, result, approval state] | [Correlation or retention requirement] |
| [Identity, endpoint, network, model, or application log] | [Relevant activity] | [Fields needed by the analytic] | [Clock, normalization, or privacy considerations] |
- [Artifact, identifier, file, endpoint, account, or configuration change]
- [Artifact, identifier, file, endpoint, account, or configuration change]
- [None known, if the technique produces no reliable durable artifact]
- [Observable sequence or deviation that may indicate the technique]
- [Cross-source correlation that increases confidence]
- [Condition that separates suspicious behavior from normal administration]
The standalone example analytic is maintained in detection-rule.yml. Do not duplicate the complete rule in this document.
- Analytic Goal: [What behavior the rule detects]
- Rule Status: [Experimental / Test / Stable]
- Detection Logic: [Selections, correlation, sequence, or threshold in plain language]
- Correlation Window: [Duration or sequence boundary, if applicable]
- Known False Positives: [Expected legitimate activity]
- Known Limitations: [Blind spots, evasion opportunities, or unavailable telemetry]
- Tuning Guidance: [Environment-specific thresholds, allowlists, or baselines]
- Test Data: test-logs.json
- Validation Script: test_detection_rule.py
- Expected Result: [Number of positive and negative cases and required outcome]
- Detection Maturity: [Proposed / Syntax Validated / Fixture Tested / Telemetry Replay Tested / Field Evaluated]
- Last Validated: [YYYY-MM-DD]
- Feasibility Waiver: [None / Specific reason representative validation is not currently possible]
- SAF-M-X: Control Name: [How the control prevents or constrains this technique]
- SAF-M-X: Control Name: [Implementation requirement or boundary]
- [Platform or Protocol Control]: [Control not represented by an existing SAF mitigation, with citation]
- SAF-M-X: Control Name: [Telemetry, alerting, or review requirement]
- SAF-M-X: Control Name: [How the control increases detection confidence]
- [Contain the session, identity, server, tool, or affected resource]
- [Revoke or rotate exposed credentials where applicable]
- [Preserve and correlate the required telemetry]
- [Determine entry point, affected scope, and follow-on activity]
- [Remove the root cause or unsafe configuration]
- [Restore affected state and validate recovery]
- [Add regression coverage or monitoring for recurrence]
| ATT&CK ID | Technique | Mapping Type | Rationale |
|---|
| TXXXX | [ATT&CK Technique Name] | [Direct / Analogous] | [Behavioral correspondence and important limitations] |
| Framework | ID | Name | Rationale |
|---|
| [MITRE ATLAS / OWASP / NIST / Other] | [Identifier] | [Control or technique name] | [Why the mapping applies] |
- SRC-[source]: Model Context Protocol Specification - [Relevant section and claim supported]
- SRC-[source]: Primary source title - Author or Organization, Year - [Claim supported]
- SRC-[source]: Additional source title - Author or Organization, Year - [Claim supported]
| Version | Date | Changes | Author |
|---|
| 0.1 | [YYYY-MM-DD] | Initial draft | [Name or handle] |