The risks of using AI —
and how to mitigate each one.
A practical field guide for teams adopting AI. Every major risk of using AI at work, with two ways to address it: what you can do manually (policy, process, and tooling) and what MoorAI does on the device. Each risk is mapped to the OWASP LLM Top 10 and the compliance frameworks (ISO/IEC 42001, NIST AI RMF, EU AI Act). Each entry says whether MoorAI covers the risk on its own or is one layer of several.
The risks, and how to mitigate them
Each risk below has a manual mitigation, a MoorAI mitigation, and the OWASP LLM Top 10 + framework clauses it maps to. See the full compliance crosswalk for the control-by-control view.
Staff paste secrets, customer PII, source code or confidential documents into AI tools. The data may be stored by the provider, used to train a model, or exposed to others.
Mitigate manually
- Written data-handling policy + staff training
- Use enterprise "no-training" provider tiers
- Keep secrets in a vault, never in prompts
- Apply PETs (anonymization, differential privacy) or run models on-prem
With MoorAI
- On-device DLP reviews every prompt for secrets, API keys and PII before it leaves the machine
- Blocks or coaches in the moment
- Only category · risk · keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival) reach the console — content stays on the device
Malicious instructions hidden in a web page, file or tool result hijack the agent into ignoring its guardrails or exfiltrating data.
Mitigate manually
- Deploy guardrails / model-armor
- Validate and sanitize inputs
- Keep security tooling current
- Prefer on-prem models for sensitive work
With MoorAI
- On-device gateway reviews prompts and tool inputs before they reach the model
- Lethal-trifecta / toxic-flow detection flags injection + exfiltration paths
- Block or coach per policy
An agent wired to tools (MCP servers, APIs, the shell) takes actions the user never intended — deletes files, calls the wrong service, chains tools unsafely.
Mitigate manually
- Govern MCP / A2A connections
- Least-privilege tool access
- Require human approval for sensitive actions
- Document which tools each agent may use
With MoorAI
- On-device MCP tool-call gateway blocks calls before they run
- MCP-server allow-list + per-tool argument rules
- JIT elevation with a time-boxed entitlement envelope
The model produces confident, plausible, but wrong output; accuracy drifts over time as the world changes (concept / model drift).
Mitigate manually
- Human review of consequential outputs
- Ground answers with RAG / CAG
- Sample-based QA
- Monitor for drift (MLOps); re-validate against KPIs
With MoorAI
- Model-endpoint allow-list bounds which models answer
- Output review flags risky responses
- Per-agent assurance score surfaces agents to watch
- ⚠ MoorAI enforces and records — it does not fact-check. Pair it with human review + grounding.
Skewed training data yields outputs that disadvantage groups or individuals — a fairness and legal-rights risk.
Mitigate manually
- Fairness testing + bias-evaluation frameworks
- Debiasing (reweighting, adversarial debiasing)
- Strong data governance
- Expert (legal / DPO) review
With MoorAI
- Policy enforcement + human-in-the-loop coaching at the point of use
- A content-free audit trail of what was allowed, for review
- ⚠ MoorAI is not a bias-testing tool; it supports oversight and evidence, not statistical fairness analysis.
Staff adopt AI apps, browser assistants and coding agents the organization never approved or inventoried. You can't govern what you can't see.
Mitigate manually
- Maintain an approved-tools list
- Network / endpoint discovery
- Periodic audits
- Keep an AI system registry
With MoorAI
- Shadow-AI agent, app and browser discovery on every enrolled machine
- A live AIBOM inventory of the agents, models and MCP servers actually running
Decisions come from a black box with no explanation and no tamper-evident record — you can't show an auditor what happened or why.
Mitigate manually
- Prefer explainable (XAI) models
- Publish model cards / datasheets
- Log usage centrally
With MoorAI
- Every decision recorded as a cryptographically signed, content-free record
- Content-free Event-Flow / data-lineage view
- AIBOM as a live model / agent inventory — evidence without egress
Untrusted models, poisoned dependencies, or tampered agent instruction files (CLAUDE.md / .cursorrules) quietly change agent behavior.
Mitigate manually
- Vet model sources
- Scan dependencies
- Pin and review agent config
- Restrict which model endpoints are reachable
With MoorAI
- Model-endpoint allow-list
- AIBOM inventory of models / MCP in use
- Rules-file poisoning detection for CLAUDE.md / .cursorrules
People defer to AI output without scrutiny, eroding judgement and accountability.
Mitigate manually
- Keep a human in the loop for consequential decisions
- Disclose AI involvement to affected users
- Train staff on the tool's limitations
With MoorAI
- Coach / alert in the moment keeps a human in the loop
- Disclosure + justification prompts at the point of use
- Assurance score tempers how much autonomy an agent earns
Inputs may be retained by the provider or used to train future models; confidential IP and third-party rights can leak through prompts.
Mitigate manually
- Use enterprise no-train tiers
- Contractual data-use terms
- Policy on what may be shared
- On-prem for the most sensitive work
With MoorAI
- Content-free by construction — nothing in the telemetry for anyone to retain
- Model-endpoint allow-list bounds where inference is allowed to go
The very tool meant to inspect AI traffic can become the leak (if it forwards content to a cloud), and controls can fail open when a device is offline.
Mitigate manually
- Prefer on-prem / on-device inspection
- Harden and monitor the tooling
- Define explicit offline behavior
With MoorAI
- Content-free by default — the guard never becomes the leak, because content stays on the device
- Break-glass / offline fail-closed keeps the last-known policy enforced with no network
How to run it — the risk-management lifecycle
Responsible AI use repeats: triage on the way in, a plan, live operation, and an incident path.
Quick guide for everyday users
These habits prevent most incidents and work from day one, before any tooling is in place.
Do
- Confirm the tool is organization-approved before using it for work.
- Verify consequential output against reliable, independent sources.
- Disclose when a result was AI-assisted.
- Report problems, wrong answers or harms through your incident channel.
- Consult your DPO / legal before using personal or restricted data.
Don't
- Paste restricted, personal, secret or IP-protected data into AI tools.
- Let an agent take a specific action without human oversight.
- Treat a single AI output as the final decision.
- Use unapproved "shadow" AI tools.
- Assume the model's knowledge is current or complete.
Where MoorAI fits. MoorAI is the on-device enforcement + evidence layer: it reviews prompts and tool-calls before they run, keeps content on the machine by default (an administrator can turn on an opt-in capture tier, which does store the matched text), and produces content-free, signed records mapped to ISO/IEC 42001, NIST AI RMF, the EU AI Act and the OWASP LLM Top 10. It does not replace the organizational work the frameworks ask for: appointing an AI lead, standing up governance, writing policy, fairness testing, and staff training. It does operationalize and evidence much of that work. Educational guidance, not legal advice.
How MoorAI maps to the OWASP Top 10 lists: questions
Coverage questions for the two OWASP lists this guide maps each risk to.
OWASP Agentic Top 10
Does MoorAI map to the OWASP Agentic Top 10 (ASI01–ASI10)?
MoorAI's 85-threat matrix aligns with the OWASP Top 10 for Agentic Applications at an architecture level. It is a direct on-device control for ASI01 Agent Goal Hijack, ASI02 Tool Misuse & Exploitation, ASI04 Agentic Supply-Chain, ASI05 Unexpected Code Execution, ASI06 Memory & Context Poisoning, and ASI10 Rogue Agents. It partially covers ASI07 Insecure Inter-Agent Communication and ASI09 Human-Agent Trust Exploitation, is adjacent-only on ASI03 Identity & Privilege Abuse (a non-human-identity concern), and detects-and-reconstructs on ASI08 Cascading Failures. This is an alignment, not an OWASP-certified mapping.
Is MoorAI's agentic Top 10 coverage content-free?
Yes. Detection runs on the device and, by default, only content-free signals (a category, a risk level and a keyed one-way hash, plus the login and hostname, which the console pseudonymises on arrival) leave the machine. The one exception is an opt-in capture tier an administrator can turn on explicitly. The agent is open source (MIT), so the behavior is auditable.
OWASP Agentic Top 10, item by item →OWASP LLM Top 10
Does MoorAI cover the whole OWASP LLM Top 10?
MoorAI has on-device detectors mapped to all 10 OWASP LLM Top 10 (2025) items. It is deepest on LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency, and LLM09 Misinformation; it covers LLM05 Output Handling, LLM07 System Prompt Leakage, and LLM08 Vector & Embedding on-device. For LLM04 Data & Model Poisoning it flags an agent writing a poisoned instruction into its own memory files; poisoning of a model's training data is a pipeline concern outside the endpoint. LLM10 Unbounded Consumption is detect-not-cap (hard budgets need a gateway).
How does MoorAI cover LLM06 Excessive Agency?
Through Agency Enforcement: an approved-MCP-server allow-list enforced at call time (non-allow-listed servers are blocked) plus inspection of MCP tool-call arguments. It's one of MoorAI's deepest areas and the direct control for OWASP LLM06.
Is MoorAI's OWASP coverage content-free?
Yes. Detection runs on the device and, by default, only content-free signals (a category, a risk level and a keyed one-way hash, plus the login and hostname, which the console pseudonymises on arrival) leave the machine. The one exception is an opt-in capture tier an administrator can turn on explicitly, which does store the matched text. The agent is open source (MIT), so the behavior is auditable.
OWASP LLM Top 10, item by item →