SAF-MCP, CSA ATF and Careful Adoption, item by item
Three agentic AI frameworks, each mapped from its own list to MoorAI. Every SAF-MCP technique, every recommendation in Careful adoption of agentic AI services and every core requirement of the Agentic Trust Framework gets one status, the MoorAI components that earn a credit, and the limit of a partial credit or the reason for a gap: 243 items in all.
Scroll sideways →
| Framework | Items | Covered | Partial | Not covered | Not applicable | Covered or partial, of applicable |
|---|---|---|---|---|---|---|
| SAF-MCP | 78 | 2 | 43 | 33 | 0 | 45 of 78 (58%) |
| Careful adoption of agentic AI services | 140 | 7 | 56 | 16 | 61 | 63 of 79 (80%) |
| CSA Agentic Trust Framework | 25 | 2 | 14 | 8 | 1 | 16 of 24 (67%) |
A status is a mechanism claim, not a detection rate. A credit says a shipped MoorAI mechanism addresses the item for an AI agent MoorAI watches. It does not say how often that mechanism fires, or misses. Most credits are partial, and each partial credit states its limit.
Mapped, not certified. This is MoorAI’s own mapping, not a certification or an endorsement by any of the three publishers. The Agentic Trust Framework governs the organisation that runs an agent; MoorAI is a third-party guard beside it, so a credit means MoorAI can supply that requirement for an agent it watches, not that MoorAI is ATF conformant.
How each item is scored
Each framework is read at its official location and mapped the other way round from the rule-base mappings: from the framework’s own list to MoorAI. Every item gets exactly one status:
- covered a shipped mechanism meets the whole item.
- partial a shipped mechanism meets part of it, and the limit says which part.
- not covered a runtime control MoorAI does not provide, and the reason says what is missing.
- not applicable organisational work (governance, procurement, staffing, assessment, research) or work done inside the agent itself (its model training, prompts, evaluation, error handling, infrastructure), not a runtime tool’s job. SAF-MCP has none: every technique is a runtime attack, so one MoorAI misses is a gap.
Every credit names the MoorAI components that earn it, each a file and a symbol in the agent repository that the agent’s own test checks still exist, and the rule-base threats it rests on. Credits considered and turned down are listed under each framework with the reason. “Covered or partial, of applicable” leaves not-applicable items out of the denominator.
The data is the agent repository’s data/crosswalks/ at v1.45.1, published here unchanged; the method and the most notable gaps are in the agent’s docs/CROSSWALKS.md. MoorAI’s rules are also mapped rule by rule to the OWASP LLM, Agentic and MCP Top 10s, MITRE ATLAS and MITRE ATT&CK v20: see the threat rule-base.
SAF-MCP: Secure Agentic Framework for Model Context Protocol
- Publisher
- OpenSSF SIG-SAF-MCP
- Version
- Framework Model v2 (no release tag); commit of 2 September 2026
- Source
- SAF-MCP repository · research/framework-model.yml at commit d3d4029 (read 9 October 2026)
- Scope
- The 78 techniques with lifecycle_status: active in research/framework-model.yml at the commit above. The 8 deprecated ids are listed under `deprecated` with what replaced them and are not mapped.
- Licence
- Technique ids and titles are SAF-MCP's, under CC BY 4.0.
2 covered, 43 partial, 33 not covered of 78 techniques.
Scroll sideways →
| Id | Technique | Status | MoorAI: limit or reason, and evidence |
|---|---|---|---|
| SAF-T1001 | Tool Poisoning Attack | partial | lexical scan of descriptions and schema text; report-first, a tool is quarantined only under a blocking policyEvidence: tools/list scan (tool stage); Tool-poisoning scan (#60, mcp-tool-poisoning); Tool description asking for a credential file (#60, mcp-tool-cred-path); Hidden content in tool metadata (#50, mcp-hidden-canary); MCP stdio proxy; HTTP MCP gateway; Approved tool baselines and quarantine (mcpToolDrift: block)Rules: #60 AI rules/config file poisoning; #50 Invisible or obfuscated text in content |
| SAF-T1002 | Supply Chain Compromise | partial | MCP server packages scored at first launch (provenance, repository link, install scripts) and install commands; artifact signatures are not verified, and reputation reports unless mcpReputation.blockBelow is setEvidence: MCP server reputation scoring; MCP server reputation at first launch and version change; Registry provenance and repository link check; Install from an untrusted source (#57, pkg-install-untrusted); Hallucinated or typosquatted dependency (#62, dep-typosquat)Rules: #57 Unsanctioned or malicious package install; #62 Hallucinated or typosquatted dependency |
| SAF-T1003 | Malicious MCP-Server Distribution | partial | known-malicious and typosquatted names and opt-in catalogue verdicts at first launch, plus the server allow-list; a new malicious package with a clean name scores goodEvidence: MCP server reputation scoring; MCP server reputation at first launch and version change; MCP server allow-list (policy.mcpAllow)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1005 | Exposed Endpoint Exploit | not covered | MoorAI does not discover or close an MCP endpoint exposed to an untrusted network or origin |
| SAF-T1004 | Server Impersonation / Name-Collision | partial | lookalike package names against the popular-server list, and a tool name claimed by a second server; server identity is never authenticatedEvidence: MCP server reputation scoring; Tool-drift baselines (description, schema, shadowing); MCP server allow-list (policy.mcpAllow)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1006 | User-Social-Engineering Install | partial | the installed server is scored at its first launch and refused only off the allow-list or under blockBelow; the deception itself is not seenEvidence: MCP server reputation at first launch and version change; MCP server allow-list (policy.mcpAllow)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1007 | OAuth Authorization Phishing | not covered | MoorAI is not in the OAuth authorization flow |
| SAF-T1207 | Hijack Update Mechanism | partial | a new version is re-scored and its tool listing compared with the baseline; the update channel itself is not verifiedEvidence: MCP server reputation at first launch and version change; Tool-drift baselines (description, schema, shadowing)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1008 | Cross-Server Tool Shadowing | partial | cross-tool directive phrasing in a description ('when using X, also send ...'); there is no provenance boundary between servers' descriptorsEvidence: tools/list scan (tool stage); Tool-poisoning scan (#60, mcp-tool-poisoning)Rules: #60 AI rules/config file poisoning |
| SAF-T1101 | Command Injection | partial | known malicious command shapes in tool arguments and in the agent's own shell commands; injection inside a server's own process launcher is not observedEvidence: Argument checks: detectors over tools/call arguments; Reverse shell / remote exec (#54, exec-reverse-shell); Download-then-run (#57, fetch-then-exec); Destructive shell command (#43, destructive-command)Rules: #54 Reverse shell / remote code execution; #57 Unsanctioned or malicious package install; #43 Destructive command execution |
| SAF-T1009 | Authorization Server Mix-up | not covered | MoorAI is not in the OAuth authorization flow |
| SAF-T1102 | Prompt Injection (Multiple Vectors) | partial | text channels: prompts, MCP prompts and resources, tool descriptions and results; image and audio blocks in results are skippedEvidence: Instruction-override detectors (#3, inj-ignore); Directives in ingested content (#40, inj-untrusted-directive); Invisible or smuggled instructions (#50, obf-invisible-instructions); Tool-result scan (file stage); tools/list scan (tool stage)Rules: #2 Direct Prompt Injection; #3 Indirect Prompt Injection; #40 Second-Order Prompt Injection; #50 Invisible or obfuscated text in content; #60 AI rules/config file poisoning |
| SAF-T1103 | Fake Tool Invocation (Function Spoofing) | not covered | nothing checks that a tool-call record came from the trusted workflow |
| SAF-T1105 | Path Traversal via File Tool | not covered | no check compares a path argument with the server's configured file scope |
| SAF-T1106 | Autonomous Loop Exploit | partial | identical calls and short cycles with unchanged results, plus opt-in rate and call budget; token cost is not measuredEvidence: Runaway-loop circuit breaker (#38)Rules: #38 AI Cost Abuse |
| SAF-T1111 | AI Agent CLI Weaponization | partial | recent agent activity scored against eight autonomous-attack tells; report-only and after the factEvidence: Autonomous-agent behaviour signature (moorai-agentwatch) |
| SAF-T1110 | Multimodal Prompt Injection via Images/Audio | partial | text recovered by on-device OCR from images pasted into the desktop app; audio, and images inside tool results, are not inspectedEvidence: On-device OCR of pasted imagesRules: #2 Direct Prompt Injection; #3 Indirect Prompt Injection |
| SAF-T1201 | Post-Approval Tool Mutation | partial | description, schema and annotations; a changed implementation behind unchanged metadata is not seenEvidence: Tool-drift baselines (description, schema, shadowing); Approved tool baselines and quarantine (mcpToolDrift: block); Tool fingerprint (description, schema, annotations)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1202 | OAuth Token Persistence | not covered | MoorAI does not see OAuth refresh-token use |
| SAF-T1203 | Backdoored Server Binary | not covered | nothing fingerprints a server's executable |
| SAF-T1204 | Context Memory Implant | partial | writes that carry an instruction, into agent memory and instruction files and into MCP memory or vector-store tools; factual implants are not detectedEvidence: Instructions written into agent memory (#22, memory-poisoning); Vector-store and memory writes (index stage); Instructions headed into a knowledge base (#21, rag-poisoning)Rules: #22 Memory Poisoning; #21 Knowledge-base poisoning / RAG Poisoning |
| SAF-T1206 | Credential Implant in Config | partial | a changed MCP config file is reported as skill-file drift when the hook reads it; the credential inside it is not judgedEvidence: Skill-surface file drift, MCP configs included (#60); Skill-surface file list (.mcp.json and host MCP configs)Rules: #60 AI rules/config file poisoning |
| SAF-T1302 | Agentic Confused Deputy | partial | lexical check that a risky call's targets were named in the task, and outbound calls after untrusted content; no requestor authorization is bound to the callEvidence: Intent alignment: risky call vs the stated task (#64); Session risk: taint, sequences, slow exfiltration (#59); High-impact actions default to human approvalRules: #64 Agent entitlement drift (out-of-scope action); #59 Lethal trifecta exposure |
| SAF-T1304 | Credential Relay Chain | not covered | credentials a server forwards downstream are not seen |
| SAF-T1303 | Sandbox Escape via Server Exec | not covered | server-side process launch is not observed |
| SAF-T1305 | Host OS Priv-Esc (RCE) | not covered | exploitation of a host-side MCP component is not detected |
| SAF-T1307 | Confused Deputy Attack | not covered | the initiating principal's identity is not carried through an intermediary |
| SAF-T1308 | Token Scope Substitution | not covered | token audience and scope are not inspected |
| SAF-T1406 | Metadata Manipulation | partial | a changed description, schema or annotation after the baseline; a misleading descriptor on first sight is judged only for directive textEvidence: Tool-drift baselines (description, schema, shadowing); Tool fingerprint (description, schema, annotations)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1401 | Line Jumping | partial | a tool name claimed by a second server is flagged, and quarantined in block mode; prompts and resources are not comparedEvidence: Tool-drift baselines (description, schema, shadowing); Approved tool baselines and quarantine (mcpToolDrift: block)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1403 | Consent-Fatigue Exploit | not covered | repeated approval prompts to a person are not counted |
| SAF-T1402 | Instruction Steganography | partial | invisible Unicode, control characters, rendering-hidden markup and file metadata; images and opaque model-state fields are not decodedEvidence: Hidden content in tool metadata (#50, mcp-hidden-canary); Invisible or smuggled instructions (#50, obf-invisible-instructions); Directives in file metadata (#72)Rules: #50 Invisible or obfuscated text in content; #72 Instructions in file metadata |
| SAF-T1404 | Response Tampering | not covered | responses carry no integrity check MoorAI verifies |
| SAF-T1405 | Tool Obfuscation/Renaming | partial | on a server with an approved baseline a renamed tool is quarantined as added (block mode); the tool title is not fingerprinted and lookalike names are not judgedEvidence: Approved tool baselines and quarantine (mcpToolDrift: block); Tool fingerprint (description, schema, annotations)Rules: #25 MCP / Connector Tool Poisoning |
| SAF-T1408 | OAuth Protocol Downgrade | not covered | MoorAI is not in the OAuth authorization flow |
| SAF-T1407 | Server Proxy Masquerade | not covered | a remote server's identity is not authenticated beyond its configured route |
| SAF-T1503 | Env-Var Scraping | not covered | a stdio server reads its own environment without crossing anything MoorAI watches |
| SAF-T1501 | Full-Schema Poisoning (FSP) | partial | schema strings (descriptions, titles, defaults, enums, property names) by the same lexical detectors; coordination across paths is not modelledEvidence: tools/list scan (tool stage); Tool-poisoning scan (#60, mcp-tool-poisoning); Hidden content in tool metadata (#50, mcp-hidden-canary)Rules: #60 AI rules/config file poisoning; #50 Invisible or obfuscated text in content |
| SAF-T1502 | File-Based Credential Harvest | partial | known credential locations (SSH, cloud, .env, git, keychain) and secret-shaped values in resultsEvidence: Credential-file access (#55, cred-file-access); Files named in MCP arguments; Secret-file upload (#55, secret-file-upload); Tool description asking for a credential file (#60, mcp-tool-cred-path); Tool-result scan (file stage); Secret-shape detectors (#39)Rules: #55 Credential / secret-file access; #39 Secret / credential exposure; #60 AI rules/config file poisoning |
| SAF-T1504 | Token Theft via API Response | partial | token shapes the secret detectors know, in MCP results; forwarded by default (#39 notifies) unless policy deniesEvidence: Tool-result scan (file stage); Secret-shape detectors (#39)Rules: #39 Secret / credential exposure |
| SAF-T1505 | In-Memory Secret Extraction | partial | environment dumps the agent runs (printenv piped to grep for secrets; env to a file or /proc/*/environ, then outbound); process memory and runtime state are not readEvidence: Credential-file access (#55, cred-file-access); Environment dump staged for egress (session-risk sequence); Session risk: taint, sequences, slow exfiltration (#59)Rules: #55 Credential / secret-file access; #59 Lethal trifecta exposure |
| SAF-T1507 | Authorization Code Interception | not covered | MoorAI is not in the OAuth authorization flow |
| SAF-T1506 | Infrastructure Token Theft | partial | the egress proxy refuses cloud metadata addresses unless a rule names the IP literal; projected service-account tokens are not coveredEvidence: Egress proxy: cloud metadata addresses refused |
| SAF-T1601 | MCP Server Enumeration | partial | ingested content asking the agent to list its tools, servers or permissions; enumeration by the host is not flaggedEvidence: Capability reconnaissance in ingested content (#69, recon-agent-capabilities)Rules: #69 Agent capability enumeration |
| SAF-T1602 | Tool Enumeration | not covered | tools/list is issued by the host and is never flagged |
| SAF-T1603 | System Prompt Disclosure | covered | Evidence: System-prompt extraction (#51, sysprompt-extract); Instruction-file leakage (#52, instr-leak-output)Rules: #51 System-prompt extraction attempt; #52 System-prompt or instruction leakage in output |
| SAF-T1604 | Server Version Enumeration | not covered | version metadata release is not observed |
| SAF-T1605 | Capability Mapping | partial | ingested content asking the agent to list its tools, servers or permissions; enumeration by the host is not flaggedEvidence: Capability reconnaissance in ingested content (#69, recon-agent-capabilities)Rules: #69 Agent capability enumeration |
| SAF-T1606 | Directory Listing via File Tool | not covered | directory listings through a file tool are not judged |
| SAF-T1701 | Cross-Tool Contamination | partial | an injection-class finding on a result followed by an outbound call or credential read in the same session; other follow-on calls are not linkedEvidence: Session risk: taint, sequences, slow exfiltration (#59); Tool-result scan (file stage)Rules: #59 Lethal trifecta exposure |
| SAF-T1703 | Tool-Chaining Pivot | partial | outbound calls after untrusted content, and risky calls whose targets the task never namedEvidence: Session risk: taint, sequences, slow exfiltration (#59); Intent alignment: risky call vs the stated task (#64)Rules: #59 Lethal trifecta exposure; #64 Agent entitlement drift (out-of-scope action) |
| SAF-T1704 | Compromised-Server Pivot | partial | instructions in a server's results are detected, and blocked under a deny policy; the server's own side effects are not seenEvidence: Tool-result scan (file stage); Directives in ingested content (#40, inj-untrusted-directive); Session risk: taint, sequences, slow exfiltration (#59)Rules: #40 Second-Order Prompt Injection; #3 Indirect Prompt Injection; #59 Lethal trifecta exposure |
| SAF-T1706 | OAuth Token Pivot Replay | not covered | bearer-token replay at a resource is not observed |
| SAF-T1112 | Sampling Request Abuse | not covered | server-to-client sampling requests are not scanned |
| SAF-T1705 | Cross-Agent Instruction Injection | partial | sub-agent prompts and returns inside one Claude Code session; remote agent peers are not seenEvidence: Sub-agent delegation gate (#66); Directives in ingested content (#40, inj-untrusted-directive)Rules: #66 Sub-agent / A2A delegation; #40 Second-Order Prompt Injection |
| SAF-T1801 | Automated Data Harvesting | partial | a mass read of distinct local files followed by an upload of 4 KB or more to a new destination; MCP resource reads are not countedEvidence: Session risk: taint, sequences, slow exfiltration (#59)Rules: #59 Lethal trifecta exposure |
| SAF-T1803 | Database Dump | not covered | a database export is not recognised |
| SAF-T1707 | CSRF Token Relay | not covered | MoorAI is not in the OAuth authorization flow |
| SAF-T1804 | API Data Harvest | not covered | MCP resource reads and query results are not counted against the task |
| SAF-T1910 | Covert Channel Exfiltration | partial | data in rendered-image URLs, known local secret values and credential-shaped tokens in egress, and listed collection hosts; obscured prose in an ordinary argument is not recognisedEvidence: Data in a rendered image URL (#71, egress-rendered-image); Local secret value fingerprint matched on egress (#65); Credential-shaped token in egress (#65, egress-credential-shaped); Out-of-band collection hosts (#78, oast-exfil)Rules: #71 Exfiltration through rendered output; #65 Local secret value egress; #78 Data sent to an out-of-band collection host |
| SAF-T1911 | Parameter Exfiltration | partial | secret, payment and personal-data shapes and known local secret values in tool arguments; arbitrary confidential text is not recognisedEvidence: Argument checks: detectors over tools/call arguments; Secret-shape detectors (#39); Personal and payment data detectors (#1, #15, #90); Local secret value fingerprint matched on egress (#65); HTTP MCP gateway local-secret egress check (#65)Rules: #39 Secret / credential exposure; #65 Local secret value egress; #1 Sensitive data leak; #15 Employee or customer privacy violation; #90 Cardholder data handled by an AI agent |
| SAF-T1904 | Chat-Based Backchannel | not covered | a chat identity steering the agent is not recognised |
| SAF-T1915 | Cross-Chain Laundering via Bridges/DEXs | not covered | no financial-tool or chain-transaction analysis |
| SAF-T2101 | Data Destruction | covered | Evidence: Destructive shell command (#43, destructive-command); Destructive tool / MCP call (#56, mcp-destructive-call); High-impact actions default to human approvalRules: #43 Destructive command execution; #56 Destructive tool / MCP call |
| SAF-T1903 | Malicious Server Control Channel | not covered | a server's own outbound control channel is not identified |
| SAF-T2102 | Service Disruption | partial | runaway loops, oversized inputs, the gateway's response-size cap and opt-in per-client cool-down; volumetric attacks on a server are not seenEvidence: Runaway-loop circuit breaker (#38); Oversized input (#53, oversized-input); HTTP MCP gateway response size cap; HTTP MCP gateway per-client cool-downRules: #38 AI Cost Abuse; #53 Oversized or runaway input |
| SAF-T2104 | Fraudulent Transactions | not covered | transaction tools are not recognised and value is not bounded |
| SAF-T2105 | Disinformation Output | not covered | false assertions and fabricated provenance are not judged |
| SAF-T2103 | Code Sabotage | partial | exploitable constructs in code the agent writes; whether an edit is authorised is not judgedEvidence: Insecure code the agent writes (#61, code-* detectors)Rules: #61 Insecure code generation |
| SAF-T2106 | Context Memory Poisoning via Vector Store Contamination | partial | instruction-carrying content on its way into a store (SDK, sidecar, MCP writes); the store is not read at retrieval and factual poisoning is not detectedEvidence: Vector-store and memory writes (index stage); Instructions headed into a knowledge base (#21, rag-poisoning)Rules: #21 Knowledge-base poisoning / RAG Poisoning |
| SAF-T3001 | RAG Backdoor Attack | partial | inserts that carry an instruction, at write time, and instructions in retrieved content; a trigger-conditioned factual answer is not detectedEvidence: Vector-store and memory writes (index stage); Instructions headed into a knowledge base (#21, rag-poisoning); Directives in ingested content (#40, inj-untrusted-directive)Rules: #21 Knowledge-base poisoning / RAG Poisoning; #40 Second-Order Prompt Injection |
| SAF-T2107 | AI Model Poisoning via MCP Tool Training Data Contamination | not covered | training-corpus contamination is outside the runtime path |
| SAF-T1901 | Outbound Webhook C2 | partial | listed request-capture hosts, webhook sends gated as external comms, and egress rules where an org sets them; a fresh attacker host is judged only by rulesEvidence: Out-of-band collection hosts (#78, oast-exfil); External email / message / webhook sends (#47, action-external-comms); Egress rules (binary, host, port, method, path)Rules: #78 Data sent to an out-of-band collection host; #79 Out-of-band collection host contacted; #47 Sending external email or notifications |
| SAF-T1805 | Context Snapshot Capture | not covered | reads of agent transcripts or session state are not flagged |
| SAF-T1802 | File Collection | partial | credential files, the contents of files an MCP argument names (scanned at the file stage), and mass read then upload; other approved-path breaches are not judgedEvidence: Files named in MCP arguments; Credential-file access (#55, cred-file-access); Session risk: taint, sequences, slow exfiltration (#59)Rules: #55 Credential / secret-file access; #59 Lethal trifecta exposure |
| SAF-T1902 | Response-Borne Covert Channel | partial | hidden text and rendered-image URLs in responses; other encodings are not decodedEvidence: Hidden text in fetched or generated content (#50, obf-invisible-output); Data in a rendered image URL (#71, egress-rendered-image); Tool-result scan (file stage)Rules: #50 Invisible or obfuscated text in content; #71 Exfiltration through rendered output |
| SAF-T1913 | HTTP POST Exfil | partial | secret shapes and known local secret values in tools/call arguments through the HTTP gateway; other confidential content is not recognisedEvidence: HTTP MCP gateway; Argument checks: detectors over tools/call arguments; HTTP MCP gateway local-secret egress check (#65)Rules: #39 Secret / credential exposure; #65 Local secret value egress |
| SAF-T1914 | Tool-to-Tool Exfil | partial | taint-then-outbound and staged-credential sequences in one session, and known local secret values in the sink callEvidence: Session risk: taint, sequences, slow exfiltration (#59); Local secret value fingerprint matched on egress (#65)Rules: #59 Lethal trifecta exposure; #65 Local secret value egress |
8 deprecated SAF-MCP ids point at their replacements and are not mapped: SAF-T1104 Over-Privileged Tool Abuse (now SAF-T1302); SAF-T1109 Debugging Tool Exploitation (now SAF-T1005, SAF-T1101); SAF-T1205 Persistent Tool Redefinition (now SAF-T1201); SAF-T1301 Cross-Server Tool Shadowing (now SAF-T1008); SAF-T1306 Rogue Authorization Server (now SAF-T1009); SAF-T1309 Privileged Tool Invocation via Prompt Manipulation (now SAF-T1102, SAF-T1302); SAF-T1702 Shared-Memory Poisoning (now SAF-T1204); SAF-T1912 Stego Response Exfil (now SAF-T1902).
20 credits considered for SAF-MCP and turned down
Scroll sideways →
| Id | Credit considered | Why it is not a credit |
|---|---|---|
| SAF-T1005 | HTTP MCP gateway | the gateway binds loopback by default to protect itself; it does not detect or close an exposed MCP endpoint |
| SAF-T1008 | Tool-drift baselines (description, schema, shadowing) | the shadow signal is a second server claiming the same tool NAME (SAF-T1004, SAF-T1401), not one descriptor steering a different tool |
| SAF-T1105 | #55 Credential / secret-file access; Files named in MCP arguments | the file-argument check judges a path that lands on a credential file (credited under SAF-T1502); it does not compare the path with the server's configured scope |
| SAF-T1105 | #64 Agent entitlement drift (out-of-scope action); Entitlement envelope (#64) | the entitlement envelope's paths apply to the hook's Read, Bash and Write branches; an MCP call is checked by server name only |
| SAF-T1203 | MCP server reputation at first launch and version change | reputation is cached per server identity and version; a binary patched in place keeps both and is not re-scored |
| SAF-T1304 | Placeholder credentials (model proxy, MCP gateway) | keeps a bound secret on its own gateway route; tokens a server forwards downstream are outside it |
| SAF-T1307 | #64 Agent entitlement drift (out-of-scope action); Intent alignment: risky call vs the stated task (#64) | judges the model's call against the user's task (SAF-T1302); it does not carry the initiating principal's identity through an intermediary |
| SAF-T1403 | #38 AI Cost Abuse; Runaway-loop circuit breaker (#38) | counts repeated identical tool calls, not repeated approval prompts to a person |
| SAF-T1404 | HTTP MCP gateway staged message validation | validates message structure, not integrity; a well-formed substituted response passes |
| SAF-T1503 | #65 Local secret value egress; Local secret value fingerprint matched on egress (#65) | the local-secret fingerprint watches the agent's egress; a stdio server reading its own environment never crosses it |
| SAF-T1602 | #69 Agent capability enumeration; Capability reconnaissance in ingested content (#69, recon-agent-capabilities) | #69 catches content asking the model to recount its tools (credited under SAF-T1601 and SAF-T1605); the host's tools/list is not flagged |
| SAF-T1112 | Tool-result scan (file stage) | server-to-client requests (sampling/createMessage) are excluded from the result scan by design (resultOfResponse in mcp-proxy/tool-scan.mjs) |
| SAF-T1803 | #59 Lethal trifecta exposure; Session risk: taint, sequences, slow exfiltration (#59) | the archive-then-outbound sequence needs an outbound step; a dump kept local, or read through a database tool, raises nothing |
| SAF-T1804 | #59 Lethal trifecta exposure; Session risk: taint, sequences, slow exfiltration (#59) | mass reads count distinct local files, not MCP resource reads or query results |
| SAF-T1904 | #47 Sending external email or notifications; External email / message / webhook sends (#47, action-external-comms) | gates the agent sending a message; it does not see a chat identity steering the agent |
| SAF-T1903 | Sandbox network policy from egress rules (MXC, Seatbelt, OpenShell) | egress rules confine whatever is routed through them, but nothing identifies a server's control channel, and an MCP server process behind them was not measured |
| SAF-T2104 | #11 BEC, Business Email Compromise | bec-payment is a coach-mode match on a few payment-change phrases; it neither recognises transaction tools nor bounds value |
| SAF-T2105 | #75 Deceptive link in AI output; Deceptive link in output (#75, out-link-deceptive) | catches a link whose shown address differs from its target; false assertions and fabricated provenance are not judged |
| SAF-T1805 | #73 Agent chat-history tampering; Agent transcript tampering (#73, agent-history-tamper) | deliberately silent on reads of transcripts; it fires on deletion and rewriting |
| SAF-T1206 | #65 Local secret value egress | the local-secret fingerprint matches known values leaving the device; a credential written into config is not egress |
Careful adoption of agentic AI services
- Publisher
- ASD's ACSC, with CISA, NSA, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK (the 'authoring agencies')
- Version
- May 2026 (no version number; PDF metadata CreationDate 2026-04-30); published 1 May 2026
- Source
- CISA resource page · The PDF read (NCSC-NZ copy) (read 9 October 2026)
- Scope
- Every 'Recommended best practices' bullet under 'Best practices for securing agentic AI systems' and 'Defend against future risks', and every Appendix A prerequisite: 140 items. The risk descriptions and the 'Further information' reading list are not controls and are not mapped.
- Licence
- Each recommendation's text is the guidance's own wording, reproduced under CC BY 4.0, © Commonwealth of Australia 2026. The guidance numbers nothing, so the ids are MoorAI's locators: stage, subsection and position in that subsection's list.
7 covered, 56 partial, 16 not covered, 61 not applicable of 140 recommendations.
Scroll sideways →
| Id | Recommendation | Status | MoorAI: limit or reason, and evidence |
|---|---|---|---|
| design/controlled-context/1 | Structure prompt context using a clear instruction hierarchy to ensure agent behaviour aligns with intended priorities and constraints | not applicable | how the agent's own prompt context is structured |
| design/controlled-context/2 | Implement grounding by providing relevant contextual information using retrieval augmented generation and prompt engineering to mitigate hallucinations and other LLM-related errors | not applicable | grounding the agent's model with retrieval and prompt engineering |
| design/oversight-mechanisms/1 | Include mechanisms to facilitate human control and oversight to ensure that agentic AI systems approved for non-sensitive, low-risk tasks cannot autonomously progress into higher-risk activities | partial | declared envelopes and workload profiles refuse out-of-scope tools, paths, MCP servers and hosts; the risk level of a task is not modelledEvidence: Entitlement envelope (#64); Declared workload profilesRules: #64 Agent entitlement drift (out-of-scope action) |
| design/oversight-mechanisms/2 | Implement human control points throughout the agent workflow, such as live monitoring and interruption during task execution, mandatory human approval for decision-making steps, auditing and reversibility following task execution to ensure security | partial | approval (justify) for listed high-impact action classes, a kill verdict that ends the session, and a content-free audit; no live interruption on demand and no reversibilityEvidence: High-impact actions default to human approval; Kill verdict terminates the agent session; Content-free action audit logRules: #11 BEC, Business Email Compromise; #43 Destructive command execution; #46 Changing security settings, IAM, or firewall; #47 Sending external email or notifications; #48 Creating users, tokens, or API keys; #49 Deploying to a production environment |
| design/oversight-mechanisms/3 | Define explicit control flows to bound autonomous planning and prevent agents from deviating beyond authorised objectives or actions | partial | bounds the actions an agent may take, not its planEvidence: Entitlement envelope (#64); Declared workload profilesRules: #64 Agent entitlement drift (out-of-scope action) |
| design/identity-management/1 | Embed strong identity management mechanisms into agents using manage identity services, decentralised identifiers or public key infrastructure | not covered | MoorAI does not issue or manage agent identities |
| design/identity-management/2 | Authenticate all inter-agent and agent-to-service API calls using mutual transport layer security to ensure non-repudiation | not covered | MoorAI does not terminate or authenticate agent-to-service TLS |
| design/identity-management/3 | Maintain a trusted registry and bind identities to authorised roles; periodically reconcile the registry against the live set of agents | not covered | no registry of agent identities bound to roles |
| design/identity-management/4 | Deny access for any agent or cryptographic key that is not present in the trusted registry | not covered | no registry of agent identities or keys to deny against |
| design/identity-management/5 | Apply role-based identity management and limit agent permissions to the minimum scope required for approved tasks | partial | per-agent envelope of tools, paths and MCP servers, and per-tool argument rules; roles and the agent's own permissions are not managedEvidence: Entitlement envelope (#64); Per-tool argument rules (policy.mcpToolRules)Rules: #64 Agent entitlement drift (out-of-scope action) |
| design/identity-management/6 | Enforce identity-based boundaries to restrict agents’ to authorised actions only | partial | workload profiles keyed on a service id or repository; the strongest match is a service id from the system file or launch environmentEvidence: Declared workload profilesRules: #64 Agent entitlement drift (out-of-scope action) |
| design/defence-in-depth/1 | Avoid reliance on a single security mechanism by implementing multiple, overlapping layers of security controls | partial | MoorAI adds independent layers (hook, MCP proxy and gateway, model proxy, egress proxy) that overlap on MCP and model traffic; it is one product, not the whole defenceEvidence: MCP stdio proxy; HTTP MCP gateway; Model proxy; Egress proxy: cloud metadata addresses refused |
| design/defence-in-depth/2 | Apply security controls at all points where information enters or exits the system, including user inputs, tool calls, data pre-processing and model inference | partial | prompts, tool calls and results, content headed for an index, and model calls through the model proxy; only on hooked hosts and routed trafficEvidence: Instruction-override detectors (#3, inj-ignore); Argument checks: detectors over tools/call arguments; Tool-result scan (file stage); Vector-store and memory writes (index stage)Rules: #2 Direct Prompt Injection; #3 Indirect Prompt Injection; #40 Second-Order Prompt Injection; #21 Knowledge-base poisoning / RAG Poisoning |
| design/defence-in-depth/3 | Separate agents for different functions and apply strict boundaries and operational controls to the handoffs from one agent to another | partial | a sub-agent delegation gets the parent's envelope and its prompt is scanned; one host onlyEvidence: Sub-agent delegation gate (#66); Entitlement envelope (#64)Rules: #66 Sub-agent / A2A delegation |
| develop/comprehensive-testing/1 | Use reward modelling and adversarial testing to detect specification gaming, explicitly incorporating security constraints alongside performance goals | not applicable | training and testing the agent's model |
| develop/comprehensive-testing/2 | Train LLM agents in simulated, controlled environments to learn the implications of actions without causing real security harm | not applicable | training the agent's model |
| develop/comprehensive-testing/3 | Leverage synthetic data generation to create adversarial training examples that reflect real-world operating scenarios | not applicable | training data generation for the agent's model |
| develop/comprehensive-testing/4 | Apply active learning to adversarial training scenarios to expose agents to high uncertainty inputs and more efficiently discover unexpected behaviours | not applicable | training the agent's model |
| develop/appropriate-evaluation/1 | Use relevant threat models to define evaluation scenarios, including edge cases beyond typical training conditions | not applicable | evaluating the agent before deployment |
| develop/appropriate-evaluation/2 | Use techniques, such as Best-of-N sampling (selecting the best output from multiple model responses to the same prompt), multistep reasoning prompts and inference time scaling to draw out the full range of agent behaviours and skills | not applicable | evaluating the agent before deployment |
| develop/appropriate-evaluation/3 | Evaluate systems across different levels of autonomy to understand performance and risk under changing environmental conditions, including changes in tool, models and resource access, such as web search or code execution | not applicable | evaluating the agent before deployment |
| develop/appropriate-evaluation/4 | Vary contextual conditions, such as presence or absence of other agents and the timing of evaluation, to understand their impact on task performance | not applicable | evaluating the agent before deployment |
| develop/appropriate-evaluation/5 | Conduct capability evaluations continuously across the agent development lifecycle | not applicable | evaluating the agent across its development lifecycle |
| develop/input-management/1 | Implement robust input validation and sanitisation for all agent inputs | partial | detection on prompts, files and tool results on hooked surfaces, and message validation through the HTTP gateway; sanitisation is masking on the Claude Code hook, and on tool results at the MCP guard, the MCP gateway and the model proxy in enforce modeEvidence: Instruction-override detectors (#3, inj-ignore); Directives in ingested content (#40, inj-untrusted-directive); HTTP MCP gateway staged message validation; Masking a finding in place (Claude Code hook; tool results at the MCP guard, MCP gateway and model proxy)Rules: #2 Direct Prompt Injection; #3 Indirect Prompt Injection; #40 Second-Order Prompt Injection; #50 Invisible or obfuscated text in content |
| develop/input-management/2 | Integrate prompt injection filters and semantic analysis to detect malicious instructions | covered | Evidence: Instruction-override detectors (#3, inj-ignore); Directives in ingested content (#40, inj-untrusted-directive); Invisible or smuggled instructions (#50, obf-invisible-instructions); On-device model second opinion (#58)Rules: #2 Direct Prompt Injection; #3 Indirect Prompt Injection; #40 Second-Order Prompt Injection; #50 Invisible or obfuscated text in content; #70 Content aimed only at the AI client; #72 Instructions in file metadata; #74 Self-replicating prompt; #58 Model-escalated risk (on-device second opinion) |
| develop/input-management/3 | Validate context to ensure the system correctly interprets intent before execution | partial | a lexical check that a risky call's targets were named in the task; interpretation of intent in general is not checkedEvidence: Intent alignment: risky call vs the stated task (#64)Rules: #64 Agent entitlement drift (out-of-scope action) |
| develop/red-teaming/1 | Deploy sandbox environments to test agent behaviour before production deployment | not applicable | pre-production testing practice |
| develop/red-teaming/2 | Conduct red teaming exercises to identify potential loopholes and unintended behaviour | not applicable | red-team exercise against the agent |
| develop/red-teaming/3 | Use capability elicitation techniques to probe for unexpected or emergent abilities, especially any that could create substantial resource or environment risks | not applicable | capability elicitation against the agent |
| develop/red-teaming/4 | Implement agent simulation tests, such as multi-agent red teaming or chaos testing. | not applicable | simulation testing of the agent |
| develop/resilience/1 | Embed agentic AI systems with fail-safe defaults and containment mechanisms that limit the blast radius of unexpected behaviours | partial | a kill verdict ends the agent session on the desktop host, macOS isolation is opt-in, and MoorAI itself fails open unless the fail-closed posture is setEvidence: Kill verdict terminates the agent session; Desktop host agent isolation (macOS Seatbelt); Offline fail-closed posture (opt-in) |
| develop/resilience/2 | Implement data loss prevention controls specifically tuned to AI agent behaviours | covered | Evidence: Secret-shape detectors (#39); Personal and payment data detectors (#1, #15, #90); Protected health information (#44, phi-hipaa); Secret-file upload (#55, secret-file-upload); Local secret value fingerprint matched on egress (#65); Session risk: taint, sequences, slow exfiltration (#59)Rules: #1 Sensitive data leak; #15 Employee or customer privacy violation; #39 Secret / credential exposure; #44 Protected health information (HIPAA / PHI); #55 Credential / secret-file access; #59 Lethal trifecta exposure; #65 Local secret value egress; #77 AI model or dataset collection; #90 Cardholder data handled by an AI agent |
| develop/resilience/3 | Implement versioning and rollback mechanisms to safely revert a system to known-good agent behaviours when unpredictability is observed | not covered | MoorAI does not version or roll back agent behaviour |
| develop/accountability/1 | Integrate comprehensive artefact logging mechanisms by default | partial | content-free records of every tool call MoorAI sees, by default; no content or reasoning is keptEvidence: Content-free action audit log; Chain-stamped session ledger; Tamper-evident record chain |
| develop/accountability/2 | Integrate unified audit logs for all inter-agent interactions to maintain observability of all agent exchanges | partial | sub-agent handoffs on one host are logged; remote agent-to-agent exchanges are not seenEvidence: Sub-agent delegation gate (#66); Chain-stamped session ledgerRules: #66 Sub-agent / A2A delegation |
| develop/accountability/3 | Use interpretability tools to ensure observability of and reasoning behind agent decisions | not applicable | interpretability of the agent's model |
| develop/accountability/4 | Require specific information referencing for agents that show where key aspects of their response originated from. | not applicable | source referencing in the agent's responses |
| develop/third-party-components/1 | Verify all external third-party components originate from trusted sources and are up to date before inclusion in agentic AI systems | partial | MCP server packages scored at first launch (provenance, repository link, known-malicious and typosquat names) and install commands judged; whether a component is up to date is not checkedEvidence: MCP server reputation scoring; Registry provenance and repository link check; Install from an untrusted source (#57, pkg-install-untrusted); Hallucinated or typosquatted dependency (#62, dep-typosquat)Rules: #57 Unsanctioned or malicious package install; #62 Hallucinated or typosquatted dependency |
| develop/third-party-components/2 | Maintain a trusted registry of third-party components | partial | an allow-list of MCP servers and console-approved tool fingerprints; other component types are not registeredEvidence: MCP server allow-list (policy.mcpAllow); Approved tool baselines and quarantine (mcpToolDrift: block)Rules: #25 MCP / Connector Tool Poisoning |
| develop/third-party-components/3 | Reference CISA’s A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity and 2025 Minimum Elements for a Software Bill of Materials (SBOM) when procuring agentic AI systems | not applicable | a procurement reference to CISA SBOM documents |
| develop/third-party-components/4 | Restrict tool use to an approved allow list of tools and versions that are regularly verified as secure | partial | servers by label and approved tool fingerprints; versions are not pinned and the tools are not verified as secureEvidence: MCP server allow-list (policy.mcpAllow); Approved tool baselines and quarantine (mcpToolDrift: block); Entitlement envelope (#64)Rules: #25 MCP / Connector Tool Poisoning |
| develop/third-party-components/5 | Verify agent behaviour related to tool usage aligns with documented security policies | partial | each tool call is judged against the signed policy on hooked hosts and on MCP traffic routed through the proxy or gatewayEvidence: Argument checks: detectors over tools/call arguments; Entitlement envelope (#64); Signature-verified policyRules: #64 Agent entitlement drift (out-of-scope action); #25 MCP / Connector Tool Poisoning |
| develop/third-party-components/6 | Log agent tool usage and ensure results are captured in system logs in a human-readable format | partial | content-free records (tool, server, decision, reason code, hash); results are not capturedEvidence: Content-free action audit log; Verdict provenance (policy id, reason code) |
| develop/third-party-components/7 | Establish trigger-action protocols that automatically restrict agent permissions when unexpected behaviour emerges | partial | the circuit breaker can pause a session and session risk can raise outbound calls to ask; permissions themselves are not changedEvidence: Runaway-loop circuit breaker (#38); Session risk: taint, sequences, slow exfiltration (#59)Rules: #38 AI Cost Abuse; #59 Lethal trifecta exposure |
| develop/third-party-components/8 | Codify separation of duties by defining roles, such as ‘Orchestrator’, ‘Reader’ and ‘Actuator’ with clear boundaries, consensus mechanisms and delegations expiry | not covered | no Orchestrator / Reader / Actuator roles or consensus mechanism |
| develop/third-party-components/9 | Implement consensus controls for actions based on risk; use multi agent approval for moderate stakes actions and human in the loop approval in addition to multi agent consensus for high stakes actions | not covered | no multi-agent consensus control |
| develop/third-party-components/10 | Prohibit agents from modifying their own privileges or initiating unapproved delegation without explicit expiry timers and recorded grant chains | partial | IAM and credential changes gated, delegation held to the parent's envelope, weakened agent settings reported, elevation grants time-boxed; grant chains are not recordedEvidence: Security / IAM / firewall change (#46, action-security-config); User, token or API-key creation (#48, action-credential-create); Sub-agent delegation gate (#66); Agent posture: hook state and weakened settings; Time-boxed JIT elevation grantsRules: #46 Changing security settings, IAM, or firewall; #48 Creating users, tokens, or API keys; #66 Sub-agent / A2A delegation |
| develop/third-party-components/11 | Standardise tool descriptions using a consistent format that avoids persuasive language | partial | directive and hidden content in third-party tool descriptions is flagged; descriptions are not standardisedEvidence: tools/list scan (tool stage); Tool-poisoning scan (#60, mcp-tool-poisoning)Rules: #60 AI rules/config file poisoning |
| deploy/threat-modelling/1 | Perform realistic threat modelling using up-to-date risk taxonomies for agentic AI systems, such as OWASP GenAI Security Project and MITRE ATLAS™ | not applicable | threat modelling practice |
| deploy/threat-modelling/2 | Design and implement security controls that address emerging and evolving agent capabilities | not applicable | control design process |
| deploy/threat-modelling/3 | Harmonise agentic AI controls with existing security frameworks, national guidance and allied agreements, such as common Zero Trust principles and the National Institute of Standards and Technology’s Zero Trust Architecture guidance | not applicable | harmonising controls with frameworks |
| deploy/threat-modelling/4 | Develop and test incident response procedures to detect, contain and recover from agent compromise | not applicable | incident response procedure |
| deploy/threat-modelling/5 | Establish regular third-party reviews of privileged architectures, share actionable intelligence with trusted partners and update risk models to reflect emerging malicious trends | not applicable | third-party review and intelligence sharing |
| deploy/governance/1 | Implement and maintain governance policies to manage autonomous agents | not applicable | governance policy |
| deploy/governance/2 | Define legal accountability and risk ownership for agentic AI systems in policies | not applicable | legal accountability and risk ownership |
| deploy/governance/3 | Upskill the organisation to build AI literacy | not applicable | training staff |
| deploy/progressive-deployment/1 | Implement phased deployment with progressively increasing access and autonomy, limiting the action space where required, such as restricted APIs or sandboxing | partial | the action space can be restricted (envelope, profiles, opt-in isolation); phasing is the operator'sEvidence: Entitlement envelope (#64); Declared workload profiles; Desktop host agent isolation (macOS Seatbelt)Rules: #64 Agent entitlement drift (out-of-scope action) |
| deploy/progressive-deployment/2 | Use graduated autonomy to incrementally increase agent independence whilst maintaining human oversight and understanding | not applicable | how far to extend autonomy is an operator decision |
| deploy/progressive-deployment/3 | Use continuous evaluation to determine when to expand system scope or when to roll back autonomy and access in response to failures | not applicable | deciding to expand or roll back scope |
| deploy/secure-by-default/1 | Set system configurations to fail-safe by default requiring agents to stop and escalate issues to human reviewers in uncertain scenarios | partial | uncertain risky calls can be raised to ask a person; MoorAI itself fails open unless the fail-closed posture is setEvidence: Intent alignment: risky call vs the stated task (#64); Session risk: taint, sequences, slow exfiltration (#59); High-impact actions default to human approval; Offline fail-closed posture (opt-in)Rules: #64 Agent entitlement drift (out-of-scope action); #59 Lethal trifecta exposure |
| deploy/secure-by-default/2 | Use error-handling and failover management to reduce the impact of system failures | not applicable | the agent's own error handling |
| deploy/secure-by-default/3 | Implement graceful degradation models so that agents maintain partial functionality even if some functions fail | not applicable | the agent's own degradation design |
| deploy/guardrails-and-constraints/1 | Specify clear, constrained objectives with explicit ‘do-not-do’ rules | not applicable | specifying the agent's objectives |
| deploy/guardrails-and-constraints/2 | Implement guardrails and hard constraints, such as deny lists and API-level safety policies | covered | Evidence: MCP server allow-list (policy.mcpAllow); Per-tool argument rules (policy.mcpToolRules); Egress rules (binary, host, port, method, path); Model-endpoint allow-list (#63); Entitlement envelope (#64)Rules: #25 MCP / Connector Tool Poisoning; #63 Unapproved model endpoint (rogue LLM egress); #64 Agent entitlement drift (out-of-scope action) |
| deploy/guardrails-and-constraints/3 | Establish declarative safety contracts with constraints and guardrails that agents cannot override | partial | the policy is signed and an edited cache counts as no policy; the hook runs as the user, so removing it is reported, not preventedEvidence: Signature-verified policy; Agent posture: hook state and weakened settings |
| deploy/guardrails-and-constraints/4 | Apply a layered set of guardrail mechanisms, ranging from anomaly detection and rule-based filtering to specialised machine learning algorithms that detect and filter prohibited behaviour | covered | Evidence: Instruction-override detectors (#3, inj-ignore); Session risk: taint, sequences, slow exfiltration (#59); Learned per-agent first-seen drift (#64); On-device model second opinion (#58)Rules: #58 Model-escalated risk (on-device second opinion); #59 Lethal trifecta exposure; #64 Agent entitlement drift (out-of-scope action) |
| deploy/guardrails-and-constraints/5 | Prioritise review of high-risk incidents, including cases where guardrails are triggered or actions are denied by human reviewers | partial | alerts carry risk level and reason code for triage in the console or a SIEM; the review itself is the operator'sEvidence: Verdict provenance (policy id, reason code); Content-free OpenTelemetry export |
| deploy/guardrails-and-constraints/6 | Deploy a secondary agent to validate new tasks against policy before execution | not covered | no secondary agent validates tasks before execution |
| deploy/isolation/1 | Implement isolation and segmentation to limit blast radius of agent failure scenarios | partial | opt-in Seatbelt isolation for agents the macOS desktop host launches, sandbox network policy generated from egress rules, and the egress proxyEvidence: Desktop host agent isolation (macOS Seatbelt); Sandbox network policy from egress rules (MXC, Seatbelt, OpenShell); Egress proxy: cloud metadata addresses refused |
| deploy/isolation/2 | Separate high-risk agents into distinct domains | not applicable | deployment topology |
| deploy/isolation/3 | Isolate agents into enclaves with no write access to logs | partial | chain-stamped and signed records make edits detectable, and the isolated host denies the agent its console record; without isolation ~/.moorai stays in the agent's write scopeEvidence: Tamper-evident record chain; Signed MCP enforcement decisions; Agent transcript tampering (#73, agent-history-tamper); Desktop host agent isolation (macOS Seatbelt)Rules: #73 Agent chat-history tampering |
| operate/monitoring-and-auditing/1 | Employ monitoring tools that enhance human oversight of agentic AI systems | covered | Evidence: Content-free OpenTelemetry export; Verdict provenance (policy id, reason code); Content-free action audit log |
| operate/monitoring-and-auditing/2 | Monitor all agent operations, including internal processes, not just the inputs and outputs | partial | tool calls, sub-agents, failures and end-of-turn claims; internal reasoning is not seenEvidence: Content-free action audit log; Sub-agent delegation gate (#66); Claimed success vs failed tool calls |
| operate/monitoring-and-auditing/3 | Monitor and log identity and privilege changes and audit regularly for drift, impersonation or misconfiguration | partial | IAM and credential changes the agent makes, out-of-envelope actions, and weakened agent settings; identity impersonation is not detectedEvidence: Security / IAM / firewall change (#46, action-security-config); User, token or API-key creation (#48, action-credential-create); Entitlement envelope (#64); Agent posture: hook state and weakened settingsRules: #46 Changing security settings, IAM, or firewall; #48 Creating users, tokens, or API keys; #64 Agent entitlement drift (out-of-scope action) |
| operate/monitoring-and-auditing/4 | Monitor agent outputs and behaviour for indicators of bias, emerging data drift and other anomalous patterns, including user prompts, tool calls, memory interactions, internal reasoning, decisions made and actions taken | partial | prompts, tool calls, memory writes and outputs; bias and internal reasoning are not monitoredEvidence: Learned per-agent first-seen drift (#64); Session risk: taint, sequences, slow exfiltration (#59); Instructions written into agent memory (#22, memory-poisoning)Rules: #64 Agent entitlement drift (out-of-scope action); #59 Lethal trifecta exposure; #22 Memory Poisoning |
| operate/monitoring-and-auditing/5 | Maintain comprehensive logs and real-time monitoring of live agent behaviour and decision-making | partial | content-free logs and live alerts; decision-making is not loggedEvidence: Content-free action audit log; Chain-stamped session ledger; Content-free OpenTelemetry export |
| operate/monitoring-and-auditing/6 | Implement runtime monitoring and anomaly detection using rules or behavioural baselines to identify unusual patterns and trigger alerts or pauses | covered | Evidence: Learned per-agent first-seen drift (#64); Learned per-agent behavioural baseline; Session risk: taint, sequences, slow exfiltration (#59); Runaway-loop circuit breaker (#38)Rules: #64 Agent entitlement drift (out-of-scope action); #59 Lethal trifecta exposure; #38 AI Cost Abuse |
| operate/monitoring-and-auditing/7 | Establish anomaly detection mechanisms that flag discrepancies between stated intentions and observed behaviours | partial | a lexical task-to-target check on risky calls, and success claims compared with failed callsEvidence: Intent alignment: risky call vs the stated task (#64); Claimed success vs failed tool callsRules: #64 Agent entitlement drift (out-of-scope action) |
| operate/monitoring-and-auditing/8 | Use multiple independent monitoring systems that cross-validate agent reports and system logs | partial | hook, proxy and gateway MCP counts are compared per device and day, and the agent's success claim is compared with tool outcomesEvidence: Hook vs proxy vs gateway MCP usage cross-check; Claimed success vs failed tool calls |
| operate/monitoring-and-auditing/9 | Monitor for goal drift by comparing active objectives against approved baseline specifications before execution | partial | actions are compared with an approved envelope before they run; objectives are notEvidence: Entitlement envelope (#64); Declared workload profilesRules: #64 Agent entitlement drift (out-of-scope action) |
| operate/monitoring-and-auditing/10 | Integrate source checks with agent logs to record which tools the system used and what information it retrieved | partial | the tools used and the destinations reached are recorded content-free; what was retrieved is not storedEvidence: Content-free action audit log; Content-free destination log |
| operate/monitoring-and-auditing/11 | Implement auditing practices that combine human review with automated analysis of system logs | partial | automated evidence packs and chain verification support the review; the human review is the operator'sEvidence: Compliance evidence packs; Tamper-evident record chain |
| operate/monitoring-and-auditing/12 | Support adaptive defences by using monitoring data to enable rapid responses, such as patches based on problems identified in system logs | not applicable | operator response process |
| operate/monitoring-and-auditing/13 | Use storage-efficient logging methods to manage log volume without losing critical information | partial | content-free, capped logs; the oldest rows are trimmedEvidence: Chain-stamped session ledger; Content-free action audit log |
| operate/monitoring-and-auditing/14 | Conduct regular security assessments, including penetration testing and red team exercises specifically targeting agentic behaviours | not applicable | security assessment practice |
| operate/validate-outputs/1 | Validate agent outputs by confirming accuracy of critical aspects against multiple sources | not covered | agent outputs are not checked against other sources |
| operate/validate-outputs/2 | Validate agents through cross-checking in environments with redundant agents that validate each other’s outputs | not covered | no redundant agents |
| operate/validate-outputs/3 | Validate tool responses to prevent malicious or unsafe instructions and standardise tool descriptions to avoid persuasive language | partial | tool results and descriptions are scanned, results blocked under a deny policy (report-first by default); descriptions are not standardisedEvidence: Tool-result scan (file stage); Directives in ingested content (#40, inj-untrusted-directive); tools/list scan (tool stage); Tool-poisoning scan (#60, mcp-tool-poisoning)Rules: #40 Second-Order Prompt Injection; #3 Indirect Prompt Injection; #60 AI rules/config file poisoning |
| operate/human-in-the-loop/1 | Ensure decisions about when human approval is required are determined by system designers or operators, not delegated to the agentic AI system | covered | Evidence: High-impact actions default to human approval; Signature-verified policy |
| operate/human-in-the-loop/2 | Prevent agents from autonomously executing high impact actions or outputs without prior human approval | partial | listed action classes, matched by pattern; the Claude Code hook asks, while the MCP proxy treats justify as allow and recordEvidence: High-impact actions default to human approvalRules: #11 BEC, Business Email Compromise; #43 Destructive command execution; #46 Changing security settings, IAM, or firewall; #47 Sending external email or notifications; #48 Creating users, tokens, or API keys; #49 Deploying to a production environment |
| operate/human-in-the-loop/3 | Insert human-in-the-loop review or approval checkpoints for actions where the cost of error is high, such as system resets, network egress or deletion of critical records. | partial | deletion and external sends can require approval; network egress is allowed, alerted or blocked by rule, not held for approvalEvidence: Destructive shell command (#43, destructive-command); Destructive tool / MCP call (#56, mcp-destructive-call); External email / message / webhook sends (#47, action-external-comms); Egress rules (binary, host, port, method, path)Rules: #43 Destructive command execution; #56 Destructive tool / MCP call; #47 Sending external email or notifications |
| operate/human-in-the-loop/4 | Quarantine requests to delete logs or audit records until reviewed and approved by a human | partial | deleting agent transcripts and destructive commands; system and audit logs are not recognised as suchEvidence: Agent transcript tampering (#73, agent-history-tamper); Destructive shell command (#43, destructive-command)Rules: #73 Agent chat-history tampering; #43 Destructive command execution |
| operate/human-in-the-loop/5 | Clearly assign responsibility and accountability for errors or adverse outcomes caused by the system | not applicable | assigning responsibility |
| operate/human-in-the-loop/6 | Conduct risk assessments to classify agent actions by potential impact, likelihood and reversibility, and apply appropriate safeguards | partial | the rule base scores each action class by severity and likelihood; reversibility is not scored, and assessing the organisation's own actions stays with itEvidence: Rule base: severity x likelihood per threat |
| operate/performance-monitoring/1 | Assess agents’ ability to evade security measures particularly in sensitive or high-impact systems | not applicable | assessment of the agent |
| operate/performance-monitoring/2 | Conduct regular assessments of an agent’s ability to bypass safeguards, such as communication barriers, guardrails, monitors, human-in-the-loop processes and input filters | not applicable | assessment of the agent |
| operate/performance-monitoring/3 | Use the results from these evaluations to validate existing controls and guide the development of stronger security measures | not applicable | using assessment results |
| operate/performance-monitoring/4 | Limit agent resource usage by applying controls, such as rate-limit components to interrupt long-running tasks and disrupt malicious workflows | partial | runaway loops pause a session in deny mode, oversized input is flagged; rate and call budget are opt-inEvidence: Runaway-loop circuit breaker (#38); Oversized input (#53, oversized-input)Rules: #38 AI Cost Abuse; #53 Oversized or runaway input |
| operate/privileges-and-authentication/1 | Limit privileges of AI agents to the minimum required for its task | partial | MoorAI confines what the agent does; it does not grant privilegesEvidence: Entitlement envelope (#64)Rules: #64 Agent entitlement drift (out-of-scope action) |
| operate/privileges-and-authentication/2 | Restrict scope of privileges to narrowest possible level to allow fine-grained control over allowed actions | partial | per-tool argument rules and path-prefix envelopesEvidence: Per-tool argument rules (policy.mcpToolRules); Entitlement envelope (#64)Rules: #64 Agent entitlement drift (out-of-scope action) |
| operate/privileges-and-authentication/3 | Implement agent reputation and trust scoring mechanisms and reduce trust levels when anomalous behaviour is detected | partial | a decaying session risk score raises outbound calls to ask; reputation scores MCP servers, not agentsEvidence: Session risk: taint, sequences, slow exfiltration (#59); MCP server reputation scoringRules: #59 Lethal trifecta exposure |
| operate/privileges-and-authentication/4 | Require just-in-time credentials for high-impact or privileged actions | partial | time-boxed elevation grants for out-of-envelope capabilities; MoorAI issues no credentialsEvidence: Time-boxed JIT elevation grantsRules: #64 Agent entitlement drift (out-of-scope action) |
| operate/privileges-and-authentication/5 | Verify API caller identity against a user or agent groups | not covered | API caller identity is not verified |
| operate/privileges-and-authentication/6 | Authenticate agents with fresh cryptographic proofs before every privileged call | not covered | agents are not authenticated |
| operate/privileges-and-authentication/7 | Require cryptographic signing for authorised commands and instructions | not covered | agent commands are not required to be signed |
| operate/privileges-and-authentication/8 | Apply cryptographic integrity checks for task definitions and constraints | partial | the constraints (MoorAI's policy) are signed and verified on the device; task definitions are notEvidence: Signature-verified policy |
| operate/privileges-and-authentication/9 | Require agents to perform cryptographic attestation where agents must prove that they are running expected and unmodified code | not covered | no code attestation of the agent |
| operate/privileges-and-authentication/10 | Continuously verify identity and authorisation at runtime using a centralised policy decision point for each request | partial | every hooked call is decided against a centrally distributed, verified policy; identity is not verifiedEvidence: Argument checks: detectors over tools/call arguments; Signature-verified policy |
| future/threat-intelligence/1 | Strengthen collaboration between stakeholders to keep pace with evolving threats to agentic AI systems | not applicable | collaboration |
| future/threat-intelligence/2 | Coordinate with major AI developers and government organisations to compile and maintain threat information | not applicable | collaboration |
| future/threat-intelligence/3 | Adopt a collaborative security approach, such as those described in CISA’s AI Cybersecurity Collaboration Playbook | not applicable | collaboration |
| future/threat-intelligence/4 | Implement alerting, data collection and tracking methods for malicious actors and techniques | partial | content-free alerts to the console or a SIEM and STIX 2.1 export; actor tracking is not doneEvidence: Content-free OpenTelemetry export; STIX 2.1 export of findings |
| future/threat-intelligence/5 | Conduct targeted analysis of threats and capabilities over time to improve situational awareness | not applicable | threat analysis practice |
| future/threat-intelligence/6 | Harmonise threat intelligence across industries to build shared threat taxonomies that improve threat modelling and support more effective mitigation design | not applicable | shared taxonomies |
| future/agent-specific-evaluations/1 | Develop robust evaluation methods to address the gaps in validating agentic AI systems | not applicable | research |
| future/agent-specific-evaluations/2 | Generate benchmark datasets to cover new domains and represent realistic deployment contexts | not applicable | research |
| future/agent-specific-evaluations/3 | Use evaluation results to validate emerging security practices and identify failure points in agents | not applicable | research |
| future/agent-specific-evaluations/4 | Share evaluation findings to strengthen security assessments and support the development of improved security practices across the field | not applicable | research |
| future/system-theoretic-analysis/1 | Use system-theoretic approaches to analyse agentic AI systems and identify appropriate security measures | not applicable | analysis method |
| future/system-theoretic-analysis/2 | Apply System Theoretic Process Analysis (STPA) and its security extension, STPA for Security (STPA-Sec), to analyse notional or operational systems, identify security issues, assess mission risk and inform potential mitigations | not applicable | analysis method |
| future/system-theoretic-analysis/3 | Use Causal Analysis using System Theory (CAST) to investigate security incidents and identify underlying root causes at the system level | not applicable | analysis method |
| future/system-theoretic-analysis/4 | Apply STPA and CAST to address safety and security concerns concurrently across agentic AI system lifecycles | not applicable | analysis method |
| appendix-a/design/1 | Implement strong authentication by following Secure by Design principles | not applicable | authentication design of the agent system |
| appendix-a/design/2 | Design transparency requirements into the system architecture to enable detection of deception indicators | partial | success claims over failed calls and autonomous-attack tells; transparency is not designed into the agentEvidence: Claimed success vs failed tool calls; Autonomous-agent behaviour signature (moorai-agentwatch) |
| appendix-a/design/3 | Use frameworks, such as zero trust, the Application Security Verification Standard or OAuth2 | not applicable | choice of frameworks |
| appendix-a/design/4 | Build system infrastructure in a secure, sandboxed environment with encryption, rate limiting and sanitisation | not applicable | building the agent's infrastructure |
| appendix-a/design/5 | Apply the principle of least privilege, assigning only the minimum access required for each role | partial | MoorAI confines what the agent does; it does not assign accessEvidence: Entitlement envelope (#64)Rules: #64 Agent entitlement drift (out-of-scope action) |
| appendix-a/design/6 | Limit entitlements to the exact resources, operations and timeframes needed | partial | resources and operations by envelope; timeframes by time-boxed elevation grants onlyEvidence: Entitlement envelope (#64); Time-boxed JIT elevation grantsRules: #64 Agent entitlement drift (out-of-scope action) |
| appendix-a/design/7 | Replace static, long-lived secrets with ephemeral credentials that expire when the job is complete | not covered | MoorAI issues no ephemeral credentials |
| appendix-a/design/8 | Dynamically scope privilege for sub-tasks and revoke elevated rights immediately when finished, mitigating scope creep | partial | a sub-agent gets the parent's envelope and elevation grants expire; privilege is not scoped per sub-taskEvidence: Sub-agent delegation gate (#66); Time-boxed JIT elevation grantsRules: #66 Sub-agent / A2A delegation; #64 Agent entitlement drift (out-of-scope action) |
| appendix-a/design/9 | Build applications with secure protocols and safe defaults that adhere to communication standards and security policies | not applicable | building the agent's protocols |
| appendix-a/design/10 | Implement message validation by default so that message components include integrity and freshness checks before use | not covered | no integrity or freshness check on messages |
| appendix-a/development/1 | Apply secure development principles from U.S. Department of War Enterprise DevSecOps Fundamentals | not applicable | secure development principles |
| appendix-a/development/2 | Minimise application scope and monitor components for unusual or unexpected behaviour | partial | MCP servers are watched for tool drift, reputation and their results; other components are notEvidence: Tool-drift baselines (description, schema, shadowing); MCP server reputation at first launch and version change; Tool-result scan (file stage) |
| appendix-a/development/3 | Enforce application understanding and only incorporate components into systems that the owner fully understands and accepts the risks of (including possible external effects and processes that it may trigger) | not applicable | owner risk acceptance |
| appendix-a/development/4 | Refer to frameworks, such as the NIST Secure Software Development Framework or SLSA’s Safeguarding artifact integrity across any software supply chain | not applicable | choice of frameworks |
| appendix-a/development/5 | Use supply chain risk management practices for third-party dependencies | partial | install commands and MCP server packages are judged at the point of use; supply-chain risk management is the organisation'sEvidence: MCP server reputation scoring; Install from an untrusted source (#57, pkg-install-untrusted); Hallucinated or typosquatted dependency (#62, dep-typosquat)Rules: #57 Unsanctioned or malicious package install; #62 Hallucinated or typosquatted dependency |
| appendix-a/development/6 | Apply existing governance and organisational management policies | not applicable | governance policy |
| appendix-a/development/7 | Conduct threat modelling using frameworks, such as OWASP Top 10:2025, MITRE ATT&CK® and MITRE D3FEND™ and use the results to inform mitigations tailored to the operational environment | not applicable | threat modelling practice |
| appendix-a/development/8 | Plan and regularly test incident response plans and teams | not applicable | incident response planning |
12 credits considered for Careful adoption of agentic AI services and turned down
Scroll sideways →
| Id | Credit considered | Why it is not a credit |
|---|---|---|
| design/identity-management/3 | Agent posture: hook state and weakened settings | agent posture inventories which agent hosts run on a device; it is not a registry of agent identities bound to roles |
| design/identity-management/4 | #25 MCP / Connector Tool Poisoning; MCP server allow-list (policy.mcpAllow) | the allow-list denies MCP servers, not agents or keys |
| develop/red-teaming/2 | moorai-redteam: the adversarial corpus against the live policy | moorai-redteam tests MoorAI's own policy against its corpus, not the agent |
| develop/third-party-components/3 | AI bill of materials (moorai-aibom) | the AIBOM is an inventory MoorAI produces; the recommendation is about procurement |
| develop/third-party-components/8 | Time-boxed JIT elevation grants | elevation grants expire, but there are no roles, boundaries between them or consensus |
| develop/third-party-components/9 | High-impact actions default to human approval | human approval for listed actions exists (credited under human-in-the-loop); multi-agent consensus does not |
| deploy/guardrails-and-constraints/6 | #58 Model-escalated risk (on-device second opinion); On-device model second opinion (#58) | the on-device model gives a second opinion on flagged text; it does not validate tasks against policy |
| operate/validate-outputs/1 | #29 Fake links and sources generated by AI | out-citation coaches on every citation marker; it checks nothing against a source |
| operate/privileges-and-authentication/7 | Signed MCP enforcement decisions | signs MoorAI's own enforcement decisions for the audit trail; it does not require the agent's commands to be signed |
| operate/privileges-and-authentication/9 | moorai-attest: in-toto export of governance records | moorai-attest exports governance records as in-toto statements; it does not attest the agent's code |
| appendix-a/design/7 | Placeholder credentials (model proxy, MCP gateway) | the agent holds a placeholder instead of the secret, but the real secret is neither ephemeral nor expiring |
| appendix-a/design/10 | HTTP MCP gateway staged message validation | validates JSON-RPC and MCP structure; there is no integrity or freshness check |
Agentic Trust Framework (ATF)
- Publisher
- Josh Woodruff (MassiveScale.AI), published through the Cloud Security Alliance
- Version
- 0.9.1 (Public Review Draft); CONFORMANCE.md, which holds the requirement ids, is headed 0.9.0; published 3 April 2026; commit of 11 April 2026
- Source
- CONFORMANCE.md at v0.9.1 · Cloud Security Alliance announcement (read 9 October 2026)
- Scope
- The 25 core requirements in CONFORMANCE.md (I-1 to R-5). The maturity levels and promotion gates are organisational processes and are not mapped.
- Licence
- Requirement ids, titles and descriptions are the framework's, under CC BY 4.0.
2 covered, 14 partial, 8 not covered, 1 not applicable of 25 requirements.
Scroll sideways →
| Id | Requirement | Status | MoorAI: limit or reason, and evidence |
|---|---|---|---|
| I-1 | IdentityUnique IdentifierGlobally unique, immutable identifier for each agent instance | not covered | MoorAI labels what it observes (a keyed actor hash per device and user, a keyed session hash) but issues no identity to an agent instance |
| I-2 | IdentityCredential BindingAgent identity bound to cryptographic credentials | not covered | agent identities are not bound to credentials |
| I-3 | IdentityOwnership ChainClear documentation of ownership and operational responsibility | not applicable | documentation of ownership and responsibility |
| I-4 | IdentityPurpose DeclarationDocumented intended use and operational scope | partial | the operational scope is declared machine-readably (envelope, workload profiles) and enforced; the intended use is not recordedEvidence: Entitlement envelope (#64); Declared workload profilesRules: #64 Agent entitlement drift (out-of-scope action) |
| I-5 | IdentityCapability ManifestMachine-readable list of claimed agent capabilities | partial | the AIBOM inventories each device's agents, models and MCP servers; the tools a server advertises are fingerprinted, not listedEvidence: AI bill of materials (moorai-aibom); Tool fingerprint (description, schema, annotations) |
| B-1 | Behavioral MonitoringStructured LoggingAll agent actions logged in machine-parseable format | partial | every tool call MoorAI sees (hook, MCP proxy and gateway) is logged content-free; actions outside those surfaces are notEvidence: Content-free action audit log; Chain-stamped session ledger; Content-free OpenTelemetry export |
| B-2 | Behavioral MonitoringAction AttributionEvery action tied to agent identity and session context | partial | each record carries a keyed actor hash and, for known agent sessions, a keyed session hash; there is no agent identity to tie it toEvidence: Content-free action audit log; Verdict provenance (policy id, reason code) |
| B-3 | Behavioral MonitoringBehavioral BaselineEstablished patterns of normal operation for anomaly detection | partial | first-seen tools, paths, servers and hosts per agent, and a learned behavioural baseline; latency and token metrics are not baselinedEvidence: Learned per-agent first-seen drift (#64); Learned per-agent behavioural baselineRules: #64 Agent entitlement drift (out-of-scope action) |
| B-4 | Behavioral MonitoringAnomaly DetectionIdentification of deviations from expected behavior | partial | rule- and baseline-based deviations; no statistical model of latency, tokens or error ratesEvidence: Learned per-agent first-seen drift (#64); Session risk: taint, sequences, slow exfiltration (#59); Runaway-loop circuit breaker (#38); Autonomous-agent behaviour signature (moorai-agentwatch)Rules: #64 Agent entitlement drift (out-of-scope action); #59 Lethal trifecta exposure; #38 AI Cost Abuse |
| B-5 | Behavioral MonitoringExplainabilityAbility to retrieve rationale for agent decisions | not covered | the agent's rationale is not captured |
| D-1 | Data GovernanceSchema ValidationInputs conform to expected structure and types | partial | JSON-RPC and MCP schema validation for messages through the HTTP MCP gateway onlyEvidence: HTTP MCP gateway staged message validation |
| D-2 | Data GovernanceInjection PreventionDetection of prompt injection and adversarial inputs | covered | Evidence: Instruction-override detectors (#3, inj-ignore); Directives in ingested content (#40, inj-untrusted-directive); Invisible or smuggled instructions (#50, obf-invisible-instructions); tools/list scan (tool stage); Tool-result scan (file stage)Rules: #2 Direct Prompt Injection; #3 Indirect Prompt Injection; #40 Second-Order Prompt Injection; #50 Invisible or obfuscated text in content; #60 AI rules/config file poisoning; #70 Content aimed only at the AI client; #72 Instructions in file metadata; #74 Self-replicating prompt |
| D-3 | Data GovernancePII/PHI ProtectionAutomated detection and masking of sensitive data | partial | pattern detectors for the listed entity types; masking on the Claude Code hook, and on tool results at the MCP guard, the MCP gateway and the model proxy in enforce modeEvidence: Personal and payment data detectors (#1, #15, #90); Protected health information (#44, phi-hipaa); Masking a finding in place (Claude Code hook; tool results at the MCP guard, MCP gateway and model proxy)Rules: #1 Sensitive data leak; #15 Employee or customer privacy violation; #44 Protected health information (HIPAA / PHI); #90 Cardholder data handled by an AI agent |
| D-4 | Data GovernanceOutput ValidationOutputs conform to expected structure and content policies | partial | content policy on output (secrets, instruction leakage, rendered-image exfiltration, deceptive links, insecure code); structure is not validatedEvidence: Secret-shape detectors (#39); Instruction-file leakage (#52, instr-leak-output); Data in a rendered image URL (#71, egress-rendered-image); Deceptive link in output (#75, out-link-deceptive); Insecure code the agent writes (#61, code-* detectors)Rules: #39 Secret / credential exposure; #52 System-prompt or instruction leakage in output; #71 Exfiltration through rendered output; #75 Deceptive link in AI output; #61 Insecure code generation |
| D-5 | Data GovernanceData LineageTracking of data provenance through the agent pipeline | not covered | data provenance through the pipeline is not tracked |
| S-1 | SegmentationResource AllowlistExplicit enumeration of permitted resources | partial | MCP servers, model endpoints, hosts and paths written in a call; resources reached at runtime are not seen, and the MCP proxy and gateway do not judge egress rulesEvidence: MCP server allow-list (policy.mcpAllow); Model-endpoint allow-list (#63); Egress rules (binary, host, port, method, path); Entitlement envelope (#64); Declared workload profilesRules: #25 MCP / Connector Tool Poisoning; #63 Unapproved model endpoint (rogue LLM egress); #64 Agent entitlement drift (out-of-scope action) |
| S-2 | SegmentationAction BoundariesExplicit enumeration of permitted actions | covered | Evidence: Entitlement envelope (#64); Per-tool argument rules (policy.mcpToolRules); Declared workload profilesRules: #64 Agent entitlement drift (out-of-scope action) |
| S-3 | SegmentationRate LimitingMaximum operations per time period | partial | per-session call rate and call budget, off by default; the gateway's cool-down counts refusalsEvidence: Runaway-loop circuit breaker (#38); HTTP MCP gateway per-client cool-downRules: #38 AI Cost Abuse |
| S-4 | SegmentationTransaction LimitsMaximum impact per individual action | not covered | the impact of a single action is not bounded |
| S-5 | SegmentationBlast Radius ContainmentLimits on cumulative impact and cascade effects | partial | a session risk score across calls, the parent's envelope on sub-agents, and opt-in host isolation; cumulative impact is not measuredEvidence: Session risk: taint, sequences, slow exfiltration (#59); Sub-agent delegation gate (#66); Desktop host agent isolation (macOS Seatbelt)Rules: #59 Lethal trifecta exposure; #66 Sub-agent / A2A delegation |
| R-1 | Incident ResponseCircuit BreakerAutomatic halt on repeated failures | partial | halts runaway loops (the same call or cycle with unchanged results) in deny mode; failure counts alone do not trip itEvidence: Runaway-loop circuit breaker (#38)Rules: #38 AI Cost Abuse |
| R-2 | Incident ResponseKill SwitchImmediate manual termination capability (<1 second) | not covered | no manual termination control |
| R-3 | Incident ResponseSession RevocationAbility to invalidate all agent sessions | not covered | agent sessions cannot be invalidated |
| R-4 | Incident ResponseState RollbackAbility to undo agent actions where possible | not covered | agent actions are not undone |
| R-5 | Incident ResponseGraceful DegradationFallback to lower autonomy level on issues | partial | session risk and intent alignment can move calls from allow to ask a person when signals fire; opt-inEvidence: Session risk: taint, sequences, slow exfiltration (#59); Intent alignment: risky call vs the stated task (#64)Rules: #59 Lethal trifecta exposure; #64 Agent entitlement drift (out-of-scope action) |
6 credits considered for CSA Agentic Trust Framework and turned down
Scroll sideways →
| Id | Credit considered | Why it is not a credit |
|---|---|---|
| I-1 | Verdict provenance (policy id, reason code) | the actor and session hashes identify a device, user and session for correlation; they are not an identity issued to an agent instance |
| I-2 | Placeholder credentials (model proxy, MCP gateway) | binds a secret to a route, not an identity to a credential |
| B-5 | Verdict provenance (policy id, reason code) | reason codes and moorai-explain explain MoorAI's own verdict, not the agent's decision |
| D-5 | #59 Lethal trifecta exposure; Session risk: taint, sequences, slow exfiltration (#59) | session taint is a time window flag on the session, not provenance tracked through the pipeline |
| S-4 | High-impact actions default to human approval | approval gates a class of action, not its magnitude |
| R-2 | Kill verdict terminates the agent session | the kill sentinel fires automatically on a kill verdict; there is no manual switch |