// AI risk training

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). MoorAI is honest about where it's the whole answer and where it's one layer of several.

1 Inclusive growth & well-being 2 Human-centered values & rights 3 Transparency & explainability 4 Robustness, security & safety 5 Accountability

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.

01Sensitive-data & privacy leakagePrivacy

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 · one-way hash reach the console — content stays on the device
FrameworksOWASP LLM02 Sensitive Info Disclosure · EU AI Act Art 10 · ISO 42001 Annex A · NIST AI RMF (Measure)
02Prompt injection & jailbreaksSecurity

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
FrameworksOWASP LLM01 Prompt Injection · NIST AI RMF (Manage) · EU AI Act Art 15
03Excessive agency / loss of control over agentsGovernance

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
FrameworksOWASP LLM06 Excessive Agency · ISO 42001 Clause 8 · EU AI Act Art 14
04Hallucination & inaccuracyReliability

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.
FrameworksOWASP LLM09 Misinformation · NIST AI RMF (Measure) · EU AI Act Art 15
05Bias & discriminationHuman rights

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.
FrameworksEU AI Act Art 10 · NIST AI RMF (Measure) · ISO 42001 Annex A
06Shadow AI — ungoverned tools & agentsGovernance

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
FrameworksOWASP LLM03 Supply Chain · ISO 42001 Clause 5.4 · NIST AI RMF (Map)
07No transparency or audit trailTransparency

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
FrameworksEU AI Act Art 12–13 · ISO 42001 Clause 9 · NIST AI RMF (Govern)
08Supply-chain & model-integrity riskSecurity

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
FrameworksOWASP LLM03 Supply Chain · LLM04 Data/Model Poisoning · LLM07 System-Prompt Leakage · EU AI Act Art 15
09Over-reliance & automation biasGood governance

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
FrameworksOWASP LLM09 Misinformation · EU AI Act Art 14 · NIST AI RMF (Govern)
10Data retention & IP / commercial rightsPrivacy

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
FrameworksOWASP LLM02 Sensitive Info Disclosure · EU AI Act Art 10 · ISO 42001 Annex A
11Security of the AI-security stack itselfSecurity

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 construction — the guard never becomes the leak, because content never leaves the device
  • Break-glass / offline fail-closed keeps the last-known policy enforced with no network
FrameworksOWASP LLM10 Unbounded Consumption · EU AI Act Art 15 · ISO 42001 Clause 8

How to run it — the risk-management lifecycle

Responsible AI use is a loop, not a one-time gate. A simple triage on the way in, a plan, live operation, and an incident path.

01
Analyze & triage
Rate each AI use case's risk and route it — a traffic-light gate on the way in.
02
Build a plan
Pick the mitigations above that fit the risk; set the guardrails and controls.
03
Operate
Run with enforcement + monitoring; sample outputs; watch for drift.
04
Handle incidents
Detect, contain, roll back, and feed lessons back into the plan.
Green — low risk, fast-track Yellow — medium, added controls Red — high, careful sign-off Blue — break-glass / time-boxed trial

Quick guide for everyday users

The habits that prevent most incidents — useful on 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.

What MoorAI is — and isn't. MoorAI is the on-device enforcement + evidence layer: it reviews prompts and tool-calls before they run, keeps content on the machine, 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 — but it operationalizes and evidences much of it. Educational guidance, not legal advice.

✉ Get a free AI governance quick guide → Framework crosswalk → How MoorAI works →
glick.run — AGPL-3.0