← Frameworks
AML.T0086

Exfiltration via AI Agent Tool Invocation

How AML.T0086 Exfiltration via AI Agent Tool Invocation shows up in practice: the mapped risk classes in this atlas, the documented incidents that prove it's real, and the scenarios and controls to learn and defend against it.

Real-world cases

54

Documented incidents, disclosed vulnerabilities and research that illustrate AML.T0086 — latest first, each with sources.

Aur0ra ransomware crew reportedly used the Cursor AI coding agent to hack seven firms27 Aug 2026

A Reuters exclusive reportedly documented a Russian-speaking ransomware group using the Cursor AI coding assistant as a hacking copilot, jailbreaking its guardrails with a simulation/test-environment framing to obtain vulnerability-identification, credential-theft and exploitation guidance against at least seven companies.

CISA/NSA/FBI warn of AI-generated exploit scripts targeting Siemens S7 PLCs (AA26-231A)19 Aug 2026

A joint US government advisory reportedly warned that threat actors are using AI-generated Python scripts disguised as legitimate OT monitoring tools for reconnaissance and read/write attacks on internet-exposed Siemens S7-series PLCs across critical-infrastructure sectors.

CoSnitch: one-click exfiltration and persistent memory rules in Microsoft Copilot Personal (CVE-2026-24301)18 Aug 2026

Varonis Threat Labs reportedly chained flaws in consumer Microsoft Copilot Personal so a crafted link with a hidden autorun parameter fired prompt execution on a single click, exfiltrated data from connected OAuth apps, and planted persistent memory rules that survived password resets and device re-enrollment; reportedly patched Aug 2026 with no evidence of abuse.

Encrypted chain-of-thought isn't private: stealing reasoning traces from frontier APIs10 Aug 2026

A paper reportedly showing that the encrypted reasoning envelopes returned by Anthropic/OpenAI/Google APIs are interchangeable across a provider's own models, so replaying one into a weaker sibling recovers the hidden chain-of-thought in plaintext, with PII and credentials extracted from scraped blocks.

AI Recommendation Poisoning: Ask-AI web links silently write trusted-source into assistant memory06 Aug 2026

Microsoft Security reportedly catalogued an in-the-wild technique across dozens of companies where websites embed hidden prompt-injection payloads behind Ask-AI deep-links that, clicked in an authenticated assistant session, silently write a permanently-trust-this-vendor tag into the assistant's long-term memory.

LLM Heist: hijacking a LiteLLM gateway for traffic interception, key theft and forged tool-calls03 Aug 2026

Researcher Johann Rehberger reportedly showed an attacker with admin access to a LiteLLM AI gateway can weaponize the legitimate model-update endpoint and the callback system to reroute victim traffic, log backend provider API keys, and inject forged tool-calls into agent responses after inference, bypassing prompt-level defenses.

Hermes AI agent run unattended ('YOLO' mode) to automate post-exploitation at Thailand's Ministry of Finance23 Jul 2026

Threat-intel firm Hunt.io and researcher Bob Diachenko reported finding exposed attacker directories (staged on a Hong Kong server, archived 9-13 Jul 2026) showing a threat actor installed the open-source Hermes AI agent, ran it in unattended 'YOLO' mode - the documented flag that removes the human-approval prompt - and delegated post-exploitation to it: the agent reportedly ran a customised LinPEAS, hunted Linux privilege-escalation paths, traversed ministry directories and catalogued Office of the Permanent Secretary staff/personnel records dating to 2012. The Ministry has not confirmed a breach, and investigators say nothing in the recovered files shows data leaving the network.

AgentForger — ChatGPT Agent Builder cross-site agent forgery deploys a persistent attacker-controlled Workspace agent from one link23 Jul 2026

Zenity Labs disclosed that two unvalidated URL parameters in ChatGPT's Workspace Agent Builder let a single crafted link, opened by a logged-in enterprise user, silently create, authorize and deploy an autonomous agent under the victim's identity and connectors — bypassing approval prompts and reportedly polling an attacker inbox for commands every five minutes. Reported to OpenAI 4 Jun 2026 and fixed 8 Jun 2026; no in-the-wild exploitation reported.

Azure DevOps MCP confused-deputy — hidden PR comments hijack AI review agents21 Jul 2026

Manifold Security reported that Microsoft's official Azure DevOps MCP server returns instructions planted in a hidden HTML comment inside a pull-request description — invisible in the web UI but returned verbatim by the API — so a victim's AI review agent, acting under the victim's credentials, follows the hidden orders and reaches data the attacker could not access directly.

Context Contamination: passive prompt injection poisons LLM security-log analysis16 Jul 2026

A red-team study shows adversaries can hide prompt-injection payloads inside network-log fields (usernames, URLs, user-agents) that fire when a SOC analyst asks an LLM to triage the logs — reportedly reaching up to 88.2% success at concealing malicious activity or exfiltrating data, turning the audit trail itself into the injection channel.

ServiceNow AI Platform pre-auth sandbox-escape RCE (CVE-2026-6875)13 Jul 2026

A reported CVSS 9.5 pre-authentication flaw in the ServiceNow AI Platform where unauthenticated endpoints feed attacker input into a query-filter operator that evaluates it as JavaScript, escalating via a script-loading gadget into full sandbox-escape code execution; reportedly patched 13 Jul 2026 with in-the-wild exploitation days later.

xAI Grok Build CLI — covert full-repo/secrets upload despite privacy opt-out12 Jul 2026 / 13 Jul 2026

A security researcher (Cereblab) captured xAI's Grok Build CLI silently uploading complete local Git repositories — untracked working files, full commit history, and unredacted secrets — to a Google Cloud Storage bucket, reportedly roughly 27,800x more data than the coding task needed, with the user-facing privacy toggle having no effect on the uploads.

+ 42 more via the mapped risk pages above.

Browse all real-world cases →

Practise it — interactive scenarios

🔗One Click, Permanent Trust

An 'Ask AI' button quietly plants a permanent 'trusted source' rule in your assistant's memory

🔑The Agent With the Master Key

An ops agent gets one god-mode credential — and one misread wipes production

🪄The Approval That Lied

A coding agent asks to write ./notes.txt — the file it actually overwrites is your SSH keys

📧The Email That Gave Orders

A support email hides instructions — and the assistant obeys them

🗄️When the Query Bites Back

A text-to-SQL agent runs the model's output straight at the database

👂Overheard Through the Cache

A speed optimisation becomes a cross-tenant listening device

🪟Stealing the Model

Two doors to the same secret: reconstruct the model through its API, or just walk off with the weight file

🪤The Bug Report That Ran Code

A fake Sentry error report hijacks a developer's coding agent into running a shell command

🔗The Chain of Innocent Commands

Every command is harmless on its own — the sequence is the exploit

📼The Compromised Flight Recorder

The forensic record is itself the attack surface — an agent's log is poisoned, then quietly rewritten

🕵️The Link That Hired an Insider

One click provisions an attacker-configured agent inside your own workspace

🕵️The Logs That Lied

An attacker plants prompt injection in the audit trail — so the LLM that hunts them erases the evidence

📡The Message in Morse

Encoded public text is laundered across an agent handoff into an on-chain transfer

🖼️The Picture That Whispered

A screenshot that's harmless at full size becomes an order once the system shrinks it

🎫The Stolen Session

An attacker captures the agent's bearer token — and inherits its authority

🥸The Uninvited Agent

A forged peer registers on the agent directory — and the planner enlists it

🪪The Worker Who Spoke for the Boss

A poisoned web page hijacks a research agent — and the planner acts on its behalf

🖱️What You Click Is Not What You Get

A GUI agent clicks 'Continue' — but the screen moved, and it lands on 'Send'

🖼️Zero-Click Leak by Picture

An inbox summary quietly ships a secret to an attacker's server

Controls & guardrails that address this

6212 proposed

Guardrails across the risks mapped to AML.T0086, grouped by control function. Filter by control category below.

Control category
Preventive · 39
Approved storage location policy from collection

Establish data transfer and storage policy for AI training data. Enforce approved storage locations from point of collection.

Lifecycle stage2 – Data Acquisition & Processing
DLP controls in data acquisition environment

Implement DLP controls in the data acquisition environment to prevent unauthorised extraction or transfer of training data.

Lifecycle stage2 – Data Acquisition & Processing
Approval-gated data transfers from build environment

Enforce data handling policy in the build environment. Require explicit approval for any data transfers outside the environment.

Lifecycle stage3 – Onboarding, Build & Review
DLP controls confining build-environment training data

Configure DLP controls in the build environment to block training data from leaving approved boundaries.

Lifecycle stage3 – Onboarding, Build & Review
Privacy risk assessment and DPIA determination

Conduct a privacy risk assessment at use case design stage. Determine if a DPIA is required before data acquisition.

Lifecycle stage1 – Use Case Context & Design
Consent, minimisation, and anonymisation during acquisition

Apply S1-defined privacy controls during data acquisition: verify consent, minimise data, anonymise personal data.

Lifecycle stage2 – Data Acquisition & Processing
Validated anonymisation and masking before training

Apply anonymisation and masking controls to personal data before use in model training. Validate de-identification effectiveness.

Lifecycle stage2 – Data Acquisition & Processing
Privacy by Design via differential privacy

Apply Privacy by Design in model architecture using differential privacy or federated learning where technically feasible.

Lifecycle stage3 – Onboarding, Build & Review
Operational consent management and privacy notice

Publish the privacy notice and confirm consent management is operational before go-live.

Lifecycle stage4 – Deployment
Purpose-limitation enforcement on agent tool calls and cross-system data aggregation

Define and sign off a purpose-to-data-source matrix with lawful basis at intake. Make it the approved baseline for runtime enforcement.

source: NIST AI RMF MAP 1.1 / MANAGE 2.2 (context and intended purpose); NIST SP 800-53 AC-4 / AC-3 (purpose-based access enforcement)
Lifecycle stages1 – Use Case Context & Design5 – Usage, Monitoring & Change
Inference-time PII redaction and third-party LLM data-processing controls

Sign zero-retention/no-training terms with each model provider and obtain DPO sign-off on the data flow before enabling any endpoint.

source: OWASP Top 10 for LLM Apps LLM02:2025 Sensitive Information Disclosure; NIST SP 800-53 SC-8 / AC-4 (information flow enforcement)
Lifecycle stages3 – Onboarding, Build & Review4 – Deployment
Role-based access controls

Restrict access to pre-anonymisation personal data to the minimum authorised set. Enforce at point of acquisition.

Lifecycle stages1 – Use Case Context & Design2 – Data Acquisition & Processing4 – Deployment
Input filtering

Apply robust de-identification (k-anonymity, l-diversity, differential privacy) during data processing. Validate effectiveness.

Input/output filtering

Implement output filters to detect and suppress quasi-identifying attribute combinations in model responses.

Query-time access-control filtering of the retrieval/RAG corpus by caller entitlements (document-level ACL enforcement)

Propagate source ACLs and classification labels onto every chunk at ingestion. Reject documents whose entitlements cannot be resolved.

source: OWASP Top 10 for LLM Apps LLM02:2025 Sensitive Information Disclosure; NIST SP 800-53 AC-3 / AC-4 Information Flow Enforcement; OWASP Agentic AI Threats & Mitigations (privilege compromise)
Lifecycle stages2 – Data Acquisition & Processing3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
Output-side DLP inspection with named-entity and PII redaction on the response path

Scan every model response inline with DLP before delivery; redact or block PII, PAN and MNPI matches. Keep the rule set version-controlled.

source: OWASP Top 10 for LLM Apps LLM02:2025 Sensitive Information Disclosure; NIST SP 800-53 SC-7(10) Prevent Exfiltration, SI-4
Lifecycle stages4 – Deployment5 – Usage, Monitoring & Change
Vet allowlisted egress destinations for server-side-fetch (SSRF) primitives; exclude or proxy-inspect any allowlisted service that can fetch arbitrary attacker-controlled URLs✚ proposed

An egress allowlist only contains exfiltration if no allowlisted destination can be coerced into fetching an attacker-controlled URL. Audit each allowlisted domain/endpoint for image-search / link-preview / URL-fetch features (SSRF proxies), and either remove them, pin them to fixed paths, or route them through an inspecting forward proxy. Pair with finishing output sanitization before render so no auto-fetch fires un-inspected.

source: Case study: searchleak-copilot (Varonis Threat Labs, CVE-2026-42824; reported by Microsoft as critical, mitigated server-side ~Jun 2026)
Lifecycle stage4 – Deployment & Serving
Egress allowlisting & DLP on tool argumentsinteractive

Controlling where the AI can send data, so secrets can't be quietly shipped to a stranger's address or website.

Per-user retrieval ACLsinteractive

Making sure the library only returns documents this particular user is allowed to see.

Serving-stack & provisioning attestation, cache isolationinteractive

Making sure the machinery running the model — and the template used to stamp out new agents — is the real, unmodified version, and that one user's data can't leak into another's through shared shortcuts.

Human approval gate on irreversible and high-impact tool calls

Classify tools by impact and reversibility at design and define which calls require human approval. Obtain governance sign-off on the thresholds before build.

source: OWASP Top 10 for LLM Apps LLM06:2025 Excessive Agency (require human approval for high-impact actions); NIST AI RMF MANAGE 2.4
Lifecycle stages1 – Use Case Context & Design3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
AddressesTool Misuse
Per-agent tool allow-list with strict JSON-schema argument validation

Bind each agent role to an explicit tool allow-list and validate every call against a strict JSON Schema at the orchestrator. Reject unlisted tools and out-of-bounds arguments before dispatch.

source: OWASP Top 10 for LLM Apps LLM06:2025 Excessive Agency (limit tools/permissions); OWASP Agentic AI Threats & Mitigations (tool access restriction)
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
AddressesTool Misuse
Least-privilege per-tool scoped, short-lived credentials

Mint short-lived, task-scoped credentials per tool. Block issuance outside the approved scope register and enforce automatic expiry.

source: NIST SP 800-53 AC-6 Least Privilege; OWASP Top 10 for LLM Apps LLM06:2025 Excessive Agency (limit permissions)
Lifecycle stages4 – Deployment5 – Usage, Monitoring & Change
AddressesTool Misuse
Egress destination allow-listing with DLP inspection of tool arguments

Review DLP hits and blocked-egress events, tune detectors, and recertify the destination allow-list periodically. Route new destinations through security change control.

source: NIST SP 800-53 SC-7 Boundary Protection / AC-4 Information Flow Enforcement; OWASP Top 10 for LLM Apps LLM02:2025 Sensitive Information Disclosure
Lifecycle stage5 – Usage, Monitoring & Change
AddressesTool Misuse
Classify each tool/MCP integration's data channel by who can write to it; taint-gate tool-response data from any third-party-writable source so it cannot drive actions without a provenance-aware approval gate✚ proposed

When onboarding an MCP/tool integration, do not stop at vetting the tool's code/manifest — also classify whether an unauthenticated or external party can write the data the tool returns (open ingestion, public write keys like a Sentry DSN, shared inboxes/issue trackers). Treat tool-response data from any third-party-writable source as untrusted ingress: taint-mark it and require a provenance-aware HITL gate (showing the exact action and its originating tool response) before any command/tool call derived from it executes. Closes the agentjacking vector where a trusted integration's legitimate data channel carries attacker-written instructions; pairs with least-privilege session scope and sandboxed execution without ambient credentials.

source: Case study: agentjacking-sentry-mcp
Lifecycle stage4 – Deployment & Serving
AddressesTool Misuse
Gate execution of any workspace/repo-provided agent tool config (e.g. .amazonq/mcp.json) behind an explicit workspace-trust consent prompt, and spawn tool processes with scoped env + constrained egress so they cannot inherit or exfiltrate ambient cloud credentials✚ proposed

Never auto-execute tool/MCP server configuration that ships inside an opened workspace. Before starting any workspace-declared server, surface the exact command + its source and require explicit developer consent (default reject), tied to a workspace-trust decision — the fix AWS shipped for CVE-2026-12957. As defence-in-depth, run spawned tool subprocesses with a scrubbed/scoped environment (no inherited AWS_* session tokens or SSH agent sockets) and an egress allowlist, so an auto-launched or approved-by-mistake server cannot read and stream live cloud credentials. Closes the zero-click 'open a folder → cloud compromise' confused-deputy vector where the tool-config loader — not the model — is the deputy.

source: Case study: amazon-q-mcp-autoload-cred-theft
Lifecycle stage4 – Deployment & Serving
AddressesTool Misuse
Enforce sandbox self-integrity: make the containment enforcer immutable to sandboxed code, keep its writable-path allow-list independent of model-controlled arguments, and fail closed on path canonicalization✚ proposed

When an agent executes model-issued commands in a sandbox, harden the sandbox against subversion by the code it contains: (1) never derive a security-relevant parameter such as the writable-path allow-list from an LLM-controlled argument (e.g. a `working_directory`) — pin it to a fixed project subtree and reject system paths; (2) make the sandbox-enforcing binary/config immutable or attested so sandboxed processes cannot overwrite it; (3) canonicalize paths with a fail-closed policy so symlink-resolution failure denies the write rather than reverting to the original in-workspace path; and (4) run the sandbox under least-privilege OS context so any residual escape inherits minimal authority. Closes the DuneSlide vector where an indirect prompt injection rewrites the enforcer and escapes to OS-level RCE; complements injection filtering, MCP pinning, and egress control rather than relying on them.

source: Case study: cursor-duneslide-sandbox-rce
Lifecycle stage4 – Deployment & Serving
AddressesTool Misuse
Treat execution-sensitive config as a protected write class: the agent's file-write/edit tool must hard-gate writes to auto-loading trust-boundary files (mcp.json, tasks.json, .vscode/*, hooks/settings), and any change to execution config must pass an effective consent gate before it auto-reloads or executes✚ proposed

Never let the agent's own write tool silently modify configuration that decides what code runs. Restrict the file-write/edit tool from execution-sensitive paths (mcp.json, .vscode/tasks.json, hooks, settings) without an out-of-band, effective human-approval gate — the boundary AWS added for CVE-2026-10591 by adding access-control restrictions to the write tool. Equally, the reload/execute step must honour a rejection: a warning prompt that reloads and runs the config regardless of the user's response is not a gate. As defence-in-depth, spawn tool subprocesses with least privilege (no inherited developer credentials) and an egress allowlist, so a self-authored or approved-by-mistake server cannot exfiltrate. Closes the zero-click 'summarise a page -> agent rewrites its own execution config -> RCE' self-modification vector, where the confused deputy is the agent's own write tool.

source: Case study: aws-kiro-mcp-config-rce
Lifecycle stage4 – Deployment & Serving
AddressesTool Misuse
Verified production-grade containment for capability-evaluation & red-team harnesses✚ proposed

Before running any capability-evaluation or red-team harness that grants a model autonomous tools, enforce containment at the infrastructure layer — network egress denied by default with any allowed destination on a tested allowlist, hermetic sandboxes, and non-ambient / non-production credentials — and independently verify (out-of-band, not via the model's prompt) that the isolation is real. Treat the evaluation vendor's infrastructure as in-scope for the same assurance, and apply compensating containment whenever model-level safeguards are deliberately disabled for testing, since the harness is then the only boundary.

source: Case study: frontier-eval-harness-containment-failures
Lifecycle stage3 – Onboarding, Build & Review
AddressesTool Misuse
Extend the containment boundary to every trusted consumer of agent-writable state; deny the agent write access to auto-execution trigger paths, or gate a host tool acting on an agent-written file behind explicit consent✚ proposed

Where a sandboxed agent can write files, treat every trusted host tool that later runs, loads or scans those files as part of the containment boundary. (1) Enumerate the deferred-execution paths from agent-writable state to unsandboxed action — hook/task engines, IDE interpreter discovery, filesystem watchers/scanners, and privileged daemon sockets (e.g. Docker). (2) For each, either run the consumer inside the same sandbox, require explicit developer consent before it acts on an agent-written file, or deny the agent write access to the trigger path (`.claude`/`.vscode`/interpreter/`.git` metadata). (3) Keep privileged daemon sockets unreachable from the workspace, and validate the actual command invocation rather than trusting a command name (e.g. a read-only `git show` allowlist that doesn't pin the invocation). (4) Run host consumers under least privilege so a residual escape inherits minimal authority. Closes the 'Week of Sandbox Escapes' vector where an agent that never breaks its sandbox writes a file a trusted out-of-sandbox tool executes; complements — does not rely on — injection filtering, MCP pinning, and egress control. Distinct from sandbox self-integrity hardening: the enforcer here is intact; the gap is that it never enclosed the consumer.

source: Case study: week-of-sandbox-escapes
Lifecycle stage4 – Deployment & Serving
AddressesTool Misuse
Deny auto-execution of AI-agent hook/config files (.claude, IDE tasks) from untrusted checkouts, and bring agent config into supply-chain scanning and review scope✚ proposed

Treat every autorun surface an AI coding agent honours as attacker-populatable, and cover both the package lifecycle and the agent-hook path. (1) Do not auto-execute project-scoped agent hook/config files (`.claude/settings*.json` hooks, VS Code tasks) from an untrusted workspace on repo-open — require explicit developer consent, or restrict auto-run to an allowlist of vetted repositories. (2) Bring agent hook/config files into SCA and code-review scope so they are inspected like `package.json` scripts (they are code, not just settings). (3) On the supply-chain side, pin and verify dependency provenance (lockfiles, integrity hashes, signed releases) and install with scripts suppressed (`--ignore-scripts`) inside a sandbox — noting this does NOT cover the repo-open hook path, which needs control (1). (4) Scope CI/cloud credentials to least privilege with short-lived tokens and egress allow-listing, so a payload that does run cannot harvest broadly, move laterally, or reuse publish rights to propagate. Closes the keyv-worm vector where committed agent-hook files execute on checkout-open; distinct from lifecycle-script mitigations, which the agent-hook path bypasses.

source: Case study: keyv-npm-worm-ai-hook-persistence
Lifecycle stage4 – Deployment & Serving
AddressesTool Misuse
Decode-time output constraints (low temperature, grammar/JSON-schema-constrained decoding)✚ proposed

Constrain generation at decode time with low temperature and grammar/schema-constrained decoding so the model emits well-formed, low-variance structured output by construction, preventing malformed responses and erratic tool-call arguments before they are produced.

source: Interactive-control reconciliation: ctrl-decoding-controls (partial coverage)
Lifecycle stage4 – Deployment
AddressesTool Misuse
Memory-write integrity validation with provenance tagging, audit/purge and TTL bounds✚ proposed

Gate every write to an agent's persistent/self-modifying memory through schema validation and provenance/trust tagging, expose stored entries for user-visible audit and purge, and apply TTLs so any planted instruction self-expires and cannot silently persist across sessions.

source: Interactive-control reconciliation: ctrl-memory-validation (partial coverage)
Lifecycle stage5 – Usage, Monitoring & Change
AddressesTool Misuse
Tool/MCP manifest hashing with diff-triggered re-review and namespace isolation against tool shadowing✚ proposed

Treat each tool/MCP description as untrusted code by hashing the manifest, blocking and re-reviewing any silent diff on update instead of auto-accepting it, and namespacing tool identifiers so a poisoned description cannot shadow a trusted tool.

source: Interactive-control reconciliation: ctrl-mcp-pinning (partial coverage)
Lifecycle stage5 – Usage, Monitoring & Change
AddressesTool Misuse
Tool argument validation & sandboxinginteractive

Double-checking the details of every action the AI wants to take, and running risky actions in a locked-down environment.

Human-in-the-loop approval on high-risk actionsinteractive

Pausing to ask a person before doing anything big or hard to undo — sending money, deleting data, emailing customers.

Decoding controls (temperature, constrained output)interactive

Turning down randomness and forcing answers into a strict format so the model improvises less.

Per-agent identity & taint-marked messagesinteractive

Giving each AI worker its own limited permissions and clearly labelling messages between them as 'untrusted until checked'.

Detective · 11
Real-time monitoring of anomalous data transfers

Monitor production for anomalous data transfers in real time. Alert on any transfer outside approved data flow boundaries.

Lifecycle stage5 – Usage, Monitoring & Change
Automated DSAR and right-to-erasure propagation across AI artefacts

Tag personal data with subject identifiers at ingestion and maintain an artefact inventory map of every store it reaches. Keep lineage current so erasure can propagate.

source: NIST AI RMF MANAGE 4.1 (post-deployment response); NIST SP 800-53 SI-12 Information Management and Retention, PT-2/PT-3 (personal data processing)
Lifecycle stages2 – Data Acquisition & Processing5 – Usage, Monitoring & Change
Vulnerability assessment

Conduct periodic privacy vulnerability assessments including re-identification risk testing as new techniques emerge.

Canary-token and membership-inference red-team probes against training/fine-tuning data memorisation

Seed registered canary records into the fine-tuning corpus during data preparation. Control the seed manifest so canaries stay traceable and tamper-proof.

source: MITRE ATLAS AML.T0024 (Exfiltration via ML Inference API), AML.T0024.000 (Infer Training Data Membership); NIST AI RMF MEASURE 2.7
Lifecycle stages2 – Data Acquisition & Processing3 – Onboarding, Build & Review
Input guardrail / injection classifierinteractive

A screen that reads incoming messages and blocks obvious attacks or banned topics before the model sees them.

Full-trace audit logginginteractive

Recording everything — questions, documents fetched, actions taken — so you can investigate when something goes wrong.

Anomaly detection on tool-call sequences and rates

Define per-agent behavioural baselines and detection rules during build. Validate against simulated misuse and sign off thresholds before release.

source: NIST AI RMF MEASURE 2.6 / MANAGE 2.2; NIST SP 800-53 SI-4 System Monitoring
Lifecycle stage3 – Onboarding, Build & Review
AddressesTool Misuse
Immutable, signed tool-call audit log with full call context

Build signed, append-only tool-call logging into the orchestrator against a defined audit schema. Block release until completeness and tamper-evidence tests pass.

source: NIST SP 800-53 AU-2 / AU-9 / AU-10 (audit events, protection of audit info, non-repudiation); MITRE ATLAS AML.M0015 (monitoring / validate inputs)
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
AddressesTool Misuse
Egress monitoring & allowlisting of outbound AI/LLM-provider API traffic from enterprise endpoints (living-off-trusted-services C2)✚ proposed

Treat outbound connections to AI/LLM provider APIs as a monitored egress channel: allowlist which hosts may reach them, baseline usage (cadence, entropy, initiating process), and alert on out-of-profile traffic — because a high-reputation destination cannot itself be trusted once it is programmable and can relay encrypted commands/results.

source: Case study: sesameop-openai-assistants-api-c2
Lifecycle stage5 – Usage, Monitoring & Change
AddressesTool Misuse
Loop/cost circuit-breakers & consistency checksinteractive

Automatic stop-switches when AIs get stuck in loops, burn too much money, or start disagreeing with each other.

Corrective · 15
Production privacy incident monitoring and regulator notification

Monitor for privacy incidents in production including personal data appearing in outputs. Notify regulators within required timeframes.

Lifecycle stage5 – Usage, Monitoring & Change
Privacy hygiene for agent memory and RAG/vector stores (retention, scoping, erasure of embeddings)

Tag every memory and vector record with subject-id and retention class; partition stores per tenant/user. Prove the erasure and isolation paths in testing before release.

source: OWASP Agentic AI Threats & Mitigations (memory/knowledge-base privacy); NIST SP 800-53 SI-12 Information Management and Retention
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
Red teaming

Test de-identification approach against known re-identification attacks (quasi-identifier linkage, singling-out). Remediate if risk is high.

Penetration testing

Penetration test AI system data access boundaries (API endpoints, system prompt exposure, memory leakage).

Vulnerability assessment

Conduct periodic data leakage audits including training data memorisation testing. Escalate confirmed leakage incidents to PDPA notification process.

Forensic evidence preservation and incident logging

Implement tamper-evident capture of prompts, outputs, and version state during build. Verify a full incident timeline can be reconstructed before go-live.

source: NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response; ISO/IEC 27037 evidence handling; NIST SP 800-61r2 (Detection & Analysis – evidence handling)
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
Egress allow-listing and tool-call sandboxing to block exfiltration of injected/sensitive data by agents

Run agent tool calls in a network-restricted sandbox behind a deny-by-default egress allow-list. Require security approval for any destination added.

source: OWASP Top 10 for LLM Apps LLM02:2025 Sensitive Information Disclosure; OWASP Agentic AI Threats & Mitigations (tool-misuse / exfiltration); NIST SP 800-53 SC-7 Boundary Protection / AC-4
Lifecycle stages4 – Deployment5 – Usage, Monitoring & Change
Sandboxed tool execution with no-egress-by-default isolation

Build sandbox profiles per tool class and run escape and egress tests before release. Treat any containment failure as a blocking defect.

source: NIST SP 800-53 SC-39 Process Isolation; MITRE ATLAS AML.M0020 (Generative AI Guardrails / restrict execution environment)
Lifecycle stages3 – Onboarding, Build & Review4 – Deployment
AddressesTool Misuse
Taint-tracking of tool outputs to suppress instruction execution

Label tool and external content as tainted and propagate the label through the agent context. Block privileged calls whose parameters derive from tainted outputs and prove it with injection tests before release.

source: OWASP Top 10 for LLM Apps LLM01:2025 Prompt Injection (segregate/flag untrusted content); MITRE ATLAS AML.M0015 (Adversarial Input Detection / validate inputs)
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
AddressesTool Misuse
Out-of-band kill-switch to revoke agent tool access

Build credential revocation and dispatch blocking out-of-band of the agent loop. Gate release on an end-to-end kill test meeting the latency target.

source: OWASP Agentic AI Threats & Mitigations (kill-switch / emergency stop); NIST AI RMF MANAGE 2.4
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
AddressesTool Misuse
Idempotency keys and rollback/dry-run for state-changing tools

Require idempotency keys, dry-run, and rollback on every state-changing tool. Gate onboarding on duplicate-call and rollback tests passing.

source: NIST SP 800-53 SI-10 Information Input Validation / CP-10 System Recovery and Reconstitution
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
AddressesTool Misuse
Pre-deployment red-team of tool-misuse and privilege-escalation paths

Red-team tool-misuse and privilege-escalation paths before release. Gate deployment on remediation or signed risk acceptance of all findings.

source: NIST AI RMF MEASURE 2.7 (adversarial testing); MITRE ATLAS AML.M0019 (Red Teaming); OWASP Top 10 for LLM Apps LLM06:2025 Excessive Agency
Lifecycle stages3 – Onboarding, Build & Review5 – Usage, Monitoring & Change
AddressesTool Misuse
Egress destination allow-listing with DLP inspection of tool arguments

Permit outbound tool calls only to allow-listed destinations and DLP-scan arguments and payloads. Block or quarantine calls carrying sensitive data to disallowed sinks.

source: NIST SP 800-53 SC-7 Boundary Protection / AC-4 Information Flow Enforcement; OWASP Top 10 for LLM Apps LLM02:2025 Sensitive Information Disclosure
Lifecycle stage4 – Deployment
AddressesTool Misuse
Per-task tool budgets and rate/quota circuit breakers

Enforce hard per-task ceilings on tool calls, spend, and data volume with a circuit breaker that halts the run. Fail closed when any ceiling is hit.

source: OWASP Top 10 for LLM Apps LLM10:2025 Unbounded Consumption; OWASP Agentic AI Threats & Mitigations (resource/rate limiting)
Lifecycle stages4 – Deployment5 – Usage, Monitoring & Change
AddressesTool Misuse
Anomaly detection on tool-call sequences and rates

Baseline normal tool-call behaviour per agent and alert on rate, sequence, or argument anomalies. Auto-throttle or quarantine on high-confidence deviations.

source: NIST AI RMF MEASURE 2.6 / MANAGE 2.2; NIST SP 800-53 SI-4 System Monitoring
Lifecycle stage5 – Usage, Monitoring & Change
AddressesTool Misuse
Open the Control Library →

AI RiskAtlas is an educational model of how GenAI & agentic systems work and fail. Architectures and payloads are illustrative and simplified for learning — not operational guidance. Real-world cases are summarised from public reporting.

Sources & further reading →·Built by Shi Yuan ↗