OWASP LLM Top 10 → NIST 800-53: Your Controls Already Cover This

Audience: CISOs, security architects, AppSec leads, AI/ML engineers with a security brief

---

The real problem isn’t the OWASP list. It’s the organisational gap it’s falling into.

OWASP published version 2.0 of their Top 10 for Large Language Model Applications in 2025. It’s a solid, practitioner-authored list of the most critical security risks facing organisations that build or deploy LLM-powered systems.

It’s also being read almost exclusively by AI engineers — the people building the systems — while the security controls teams who know how to address these risks are still getting briefed on “what an LLM is.”

That’s the gap. Not knowledge. Not tooling. Organisational language.

The OWASP LLM Top 10 is the Rosetta Stone between your AppSec team and your AI team. Every item on the list is a known vulnerability class with a known control family in NIST 800-53. The problem categories are not new. The attack surfaces are.

This article maps each of the ten risks to the controls your security organisation already operates — and tells you what to do about it on Monday morning.

---

Why this framing matters

Security teams get handed a new framework roughly every 18 months. Most of them create work without creating protection. The instinct — understandably — is to treat the OWASP LLM list as another framework to assess against, budget for, and eventually deprioritise.

It’s not. It’s a vocabulary translation exercise.

When you see “Prompt Injection,” read: input validation failure. When you see “Excessive Agency,” read: least privilege violation. When you see “Supply Chain Vulnerabilities,” read: third-party risk — the same risk your team already manages for software libraries, cloud providers, and SaaS vendors.

Once you make that translation, the path forward is obvious: extend your existing controls to cover the new attack surface, rather than standing up a parallel “AI security programme” that reports to nobody and owns nothing.

The organisations that will handle AI risk well aren’t the ones building new frameworks. They’re the ones that recognise AI deployments as in-scope for the security programme they already run.

---

LLM01: Prompt Injection

What it is

Prompt injection is the insertion of attacker-controlled text into a prompt in a way that overrides or manipulates the model’s intended instructions. In direct prompt injection, the attacker interacts with the model themselves. In indirect prompt injection — the more dangerous variant — the attacker embeds malicious instructions in content the model will later retrieve and process: a web page, a document, an email, a database record.

The model has no reliable way to distinguish between “instructions from the developer” and “text retrieved from the environment.” That distinction has to be enforced architecturally.

Why it matters for enterprises

An LLM agent with access to email, calendars, and file systems that retrieves and processes external content is a pivot point. A single malicious document — opened by the agent during a routine task — can instruct it to exfiltrate data, send messages, or modify records. The user who triggered the task may never know.

This is not theoretical. Researchers have demonstrated this class of attack against deployed AI assistants with tool access.

NIST 800-53 mapping

• SI-10 (Information Input Validation): Validate and sanitise all inputs before they reach the model, including retrieved content from external sources. Treat retrieved text as untrusted data, not trusted instructions.
• SC-07 (Boundary Protection): Implement prompt security boundaries between the user input layer and the system instruction layer. Use separate, immutable system prompts where architecturally possible.
• SI-03 (Malicious Code Protection): Content filtering on model inputs and outputs — equivalent to scanning file uploads before processing.
• AC-04 (Information Flow Enforcement): Restrict which external data sources an agent can retrieve from. Not every agent needs internet access.

What to do Monday morning

1. Audit every place in your LLM pipelines where externally-sourced content is incorporated into a prompt. Document each one.
2. Apply input sanitisation to retrieved content — strip or encode characters that could be interpreted as instructions.
3. Review agent tool permissions: does the agent need access to everything it currently has? Scope it down.
4. Add prompt injection test cases to your existing security testing pipeline. Treat it like SQLi or XSS.

dig8ital Security Factory coverage

The Threat Intelligence Agent operates within an explicit trust boundary that separates system instructions from retrieved external content. Retrieved data is treated as unstructured input, never as executable instruction. Tool calls require authorisation before execution, and all agent actions are logged to an immutable audit trail.

---

LLM02: Insecure Output Handling

What it is

LLM output is, by default, untrusted data. When that output is passed downstream — into a browser renderer, a shell executor, an SQL query, or an API call — without sanitisation or validation, it becomes an injection vector. The model might produce content that, when rendered, executes scripts (XSS), triggers OS commands (command injection), or alters database queries (SQLi).

The model itself isn’t the vulnerability. The application’s treatment of model output as trusted is.

Why it matters for enterprises

Agentic systems increasingly use LLM output as a direct input to other system calls. Code generation assistants produce code that gets executed. Document generation systems produce content that gets rendered. An attacker who can influence what the model outputs — through prompt injection or by poisoning retrieved content — can inject malicious payloads into downstream systems.

NIST 800-53 mapping

• SI-10 (Information Input Validation): Applied to model output as input to downstream systems. Output is untrusted input for the next layer in the stack.
• SC-18 (Mobile Code): Restrict and control the execution of model-generated code. Do not execute LLM output directly without human review or sandboxed execution.
• SI-07 (Software, Firmware, and Information Integrity): Validate that model outputs conform to expected structure and content policies before downstream use.

What to do Monday morning

1. Map every path where LLM output is passed to a downstream system (shell, browser, database, API).
2. Apply output encoding appropriate to the rendering context — same as you’d do for user-supplied input.
3. Establish an allow-list of permitted output formats for each use case. Flag deviations.
4. For code generation: sandbox execution environments. No direct-to-production model output without review.

dig8ital Security Factory coverage

All agent outputs are validated against output schemas before being passed to downstream systems or presented to users. Code generation tasks execute in sandboxed environments. Agent outputs are logged and reviewable before consequential actions are triggered.

---

LLM03: Training Data Poisoning

What it is

Training data poisoning occurs when an attacker introduces malicious, biased, or misleading data into the dataset used to train or fine-tune a model. The result: a model that behaves subtly incorrectly in ways that are difficult to detect — producing wrong answers in specific contexts, exhibiting biased outputs, or containing backdoors triggered by specific inputs.

Fine-tuning is particularly exposed because organisations often fine-tune on proprietary datasets they’ve assembled from internal sources, third-party corpora, or web scrapes — all of which can be poisoned.

Why it matters for enterprises

If you’re fine-tuning a model on customer data, support logs, or internal documentation, that training pipeline is an attack surface. An attacker who can influence what goes into that dataset — even a small proportion of training examples — can influence model behaviour. The attack is persistent: the compromise lives in the model weights until you retrain.

NIST 800-53 mapping

• SA-12 (Supply Chain Protection): The training dataset is a supply chain input. Apply the same rigour to data provenance that you apply to software dependencies.
• SI-07 (Software, Firmware, and Information Integrity): Integrity verification of training datasets. Checksums, provenance tracking, anomaly detection on training data distributions.
• SR-03 (Supply Chain Controls and Plans): Establish controls for third-party training data suppliers, including data quality agreements and right-to-audit clauses.
• RA-03 (Risk Assessment): Include training pipeline risks in your AI system risk assessments. Most current risk assessments don’t cover the training data layer.

What to do Monday morning

1. Inventory every dataset being used for fine-tuning or RAG retrieval. Document provenance for each.
2. Apply integrity checks (checksums, diff monitoring) to training datasets. Know when they change.
3. Add data supplier assessments to your third-party risk process. Treat training data providers like software vendors.
4. Establish baseline model behaviour tests. Run them after every fine-tuning cycle to detect drift.

dig8ital Security Factory coverage

The Security Factory’s AI components do not rely on fine-tuning on customer data. Knowledge bases used for retrieval-augmented generation are version-controlled, integrity-checked, and sourced exclusively from verified internal and authoritative external sources. Update pipelines are gated and logged.

---

LLM04: Model Denial of Service

What it is

Model denial of service (DoS) exploits the computational cost of LLM inference. Attackers submit crafted inputs designed to maximise token consumption, context length, or processing complexity — flooding inference capacity, exhausting API quotas, or triggering runaway processing loops in agentic systems.

Unlike traditional DoS, the cost is often borne by the API consumer, not the provider — making this an availability and financial risk.

Why it matters for enterprises

API inference costs scale with usage. An attacker who can force your system to process pathologically expensive queries can run up your cloud bill, degrade service availability, or starve legitimate workloads of inference capacity. In agentic systems with recursive or self-invocating loops, a single malformed input can trigger unbounded execution chains.

NIST 800-53 mapping

• SC-05 (Denial of Service Protection): Rate limiting, throttling, and quota enforcement on LLM API endpoints — equivalent to DDoS mitigation for web services.
• AU-06 (Audit Review, Analysis, and Reporting): Monitor inference usage patterns for anomalies. A sudden spike in token consumption is a detection signal.
• SI-12 (Information Management and Retention): Set hard limits on context length, output length, and recursion depth in agent execution environments.
• CP-02 (Contingency Planning): Ensure inference capacity degradation is in your service continuity plans. What happens when your LLM API is unavailable or rate-limited?

What to do Monday morning

1. Implement per-user and per-session token quotas on all LLM API endpoints. Hard limits, not just soft warnings.
2. Add inference cost monitoring to your SOC dashboard. Anomalous spend is a detection signal.
3. Set maximum context length and output length constraints at the application layer, not just the API layer.
4. Review agent execution loops for potential runaway conditions — add hard iteration and time-box limits.

dig8ital Security Factory coverage

All agent invocations run within execution budgets: maximum token consumption per turn, per session, and per day. Anomalous consumption patterns trigger alerts in the monitoring pipeline. Agent loops have hard recursion depth limits and wall-clock timeouts.

---

LLM05: Supply Chain Vulnerabilities

What it is

LLM supply chain risk encompasses the full dependency graph of an AI system: the base model, the fine-tuning pipeline, the training data, the inference infrastructure, the AI SDK, the plugin ecosystem, and the third-party services integrated via tool calls. A compromise anywhere in this chain — a backdoored model weight file, a malicious PyPI package, a compromised plugin — propagates into the production system.

Why it matters for enterprises

The AI supply chain is currently immature from a security perspective. Model weights are distributed via hosting platforms with varying integrity guarantees. AI SDKs update frequently with limited security review. Plugins and integrations often come from individual developers rather than vetted vendors.

This is the same supply chain risk story as Log4Shell or SolarWinds — the AI stack just has a shorter institutional memory for why it matters.

NIST 800-53 mapping

• SA-12 (Supply Chain Protection): Treat your AI model provider, fine-tuning vendor, and inference infrastructure as Tier-1 suppliers.
• SR-03 (Supply Chain Controls and Plans): Supplier security requirements for all AI component vendors. Include in procurement contracts.
• SR-11 (Component Authenticity): Pin model versions and verify integrity of model artefacts before deployment. Know what changed between model versions.
• SA-04 (Acquisition Process): Include AI-specific security requirements in procurement — data handling, model provenance, security testing cadence.
• CM-03 (Configuration Change Control): Model version upgrades are configuration changes. Put them through your change process.

What to do Monday morning

1. Build an “AI SBOM” — a software bill of materials for your AI stack: models, versions, SDKs, plugins, data sources.
2. Pin model versions in production. Don’t auto-update.
3. Add your AI model provider to your third-party risk register and complete a supplier assessment.
4. Review your AI SDK dependencies for known vulnerabilities. Run them through your existing SCA tooling.

dig8ital Security Factory coverage

The Security Factory maintains a versioned, integrity-verified AI component inventory. Model updates go through the same change management process as software deployments. Third-party AI vendors are subject to the standard supplier assessment programme. AI dependencies are scanned in the CI/CD pipeline.

---

LLM06: Sensitive Information Disclosure

What it is

LLM systems can disclose sensitive information through multiple paths: the model may have memorised sensitive data from training and reproduce it in responses; the application may include sensitive context (credentials, PII, internal data) in prompts that are logged or transmitted insecurely; or the model may be manipulated into surfacing confidential information it has access to through retrieval.

Context windows are ephemeral — but what enters them may not be.

Why it matters for enterprises

This is the most immediate, high-frequency risk on the list for most enterprises. Developers routinely include API keys, internal documentation, customer data, and confidential business context in prompts — often without considering where that data goes. It goes into provider logs. It may go into fine-tuning datasets. It may persist in agent memory stores.

Most data classification policies were written before “context window” was a meaningful concept. They don’t cover the prompt layer.

NIST 800-53 mapping

• SC-28 (Protection of Information at Rest): Encrypt data at rest in any prompt cache, conversation history store, or agent memory system. Apply the same controls as any other sensitive data store.
• MP-04 (Media Protection): Treat prompt logs and conversation histories as sensitive media. Apply appropriate retention, access, and disposal controls.
• AC-04 (Information Flow Enforcement): Control what data classifications are permitted to enter the prompt layer. PII, credentials, and confidential data should require explicit authorisation.
• SC-08 (Transmission Confidentiality and Integrity): Encrypt all LLM API calls in transit. Verify TLS certificates for third-party inference endpoints.
• AU-02 (Event Logging): Log what goes into prompts (with appropriate redaction) for audit and incident response purposes.

What to do Monday morning

1. Review your data classification policy: does it explicitly cover prompt content? Update it if not.
2. Audit production prompts for sensitive data — credentials, PII, internal document contents. Redact or replace with references.
3. Request and review your LLM provider’s data retention and logging policy. Get it in writing.
4. Apply the same access controls to conversation history stores as you apply to the source data.

dig8ital Security Factory coverage

The Security Factory enforces data classification at the prompt layer. Sensitive data is never included directly in prompts — only references and identifiers are passed, with data retrieved in controlled execution contexts. Conversation histories are encrypted at rest, access-controlled, and subject to configurable retention policies.

---

LLM07: Insecure Plugin Design

What it is

LLM plugins and tools extend model capability by allowing it to call external APIs, execute code, query databases, and interact with external services. When these integrations are poorly designed — overly permissive, insufficiently validated, inadequately authenticated — they become the mechanism through which prompt injection and excessive agency become exploitable.

A poorly scoped plugin is an escalation path. An attacker who can inject a malicious prompt and trigger a broad-permission plugin can cause real-world harm with minimal effort.

Why it matters for enterprises

Enterprise AI deployments increasingly connect models to business-critical systems: CRMs, ERPs, ticketing systems, email, calendars, code repositories. Each integration is an API with an authentication credential and a scope. If that scope is broader than the task requires, and if inputs to the plugin aren’t validated, the attack surface expands significantly.

The principle is identical to OAuth scope creep — a problem the industry spent years learning to address.

NIST 800-53 mapping

• AC-06 (Least Privilege): Plugin credentials should have the minimum permissions required for the task. A plugin that reads email shouldn’t be able to send it. A plugin that queries a database shouldn’t be able to write to it.
• SA-08 (Security Engineering Principles): Apply secure design principles to plugin architectures: input validation, authentication for every call, explicit output sanitisation.
• IA-08 (Identification and Authentication — Non-Organisational Users): Agent tool calls authenticate as non-human identities. These identities should be scoped, audited, and revocable.
• AU-02 (Event Logging): Every plugin call should generate an audit log entry: what was called, with what parameters, by which agent session.

What to do Monday morning

1. Inventory every plugin/tool your LLM agents can currently invoke. Document the permissions each uses.
2. Apply least-privilege scoping: revoke any permissions that aren’t required for the current use case.
3. Add input validation to every plugin endpoint — treat agent-supplied parameters as untrusted input.
4. Implement per-plugin audit logging and route it to your SIEM.

dig8ital Security Factory coverage

All agent tools in the Security Factory use purpose-scoped service credentials. Tool invocations are logged at the agent level and the API gateway level. Sensitive tool calls — those that write data, send communications, or modify system state — require explicit authorisation before execution. Plugin inputs are validated against strict schemas.

---

LLM08: Excessive Agency

What it is

Excessive agency occurs when an LLM agent is granted more capability, permission, or autonomy than its task requires — and exercises that capability in unintended, harmful, or attacker-directed ways. This can arise from overly broad tool access, insufficient human oversight, or prompt injection that redirects the agent’s actions.

An agent that can read files, send emails, modify records, and call external APIs — without human approval for each action category — is a single compromised prompt away from doing all of those things on an attacker’s behalf.

Why it matters for enterprises

This is the agentic risk category with the highest potential impact. As organisations deploy agents to automate complex workflows, the blast radius of an agent compromise grows with the agent’s capability set. An agent that manages supplier communications and has write access to the ERP is categorically different from a read-only query assistant.

The instinct to give agents broad access to make them more useful is precisely the instinct that creates this risk.

NIST 800-53 mapping

• CM-07 (Least Functionality): Configure agent capability sets to the minimum required for the intended task. Disable or remove tool integrations not required for the current deployment context.
• AC-05 (Separation of Duties): Separate the agent’s ability to plan actions from its ability to execute them. Require human approval for consequential actions.
• AC-06 (Least Privilege): Apply least privilege not just to credentials but to the scope of actions the agent can autonomously take.
• IR-10 (Integrated Information Security Analysis Team): When agents take unexpected actions, treat it as a security incident. Have a playbook.

What to do Monday morning

1. For each deployed agent, document: what tools it has access to, what data it can read, what actions it can take autonomously.
2. Categorise agent actions into “read-only” (can be autonomous) and “consequential” (require human approval). Enforce the boundary.
3. Implement an agent kill-switch: a mechanism to immediately revoke an agent’s ability to execute tool calls, independent of the application layer.
4. Add “unexpected agent action” to your incident classification taxonomy.

dig8ital Security Factory coverage

The Security Factory implements a three-tier action model: autonomous (read-only data retrieval), supervised (actions that modify state, requiring human approval in the workflow), and blocked (actions outside the defined scope of the current deployment). Agents cannot escalate their own permissions. All consequential actions generate approval requests before execution.

---

LLM09: Overreliance

What it is

Overreliance occurs when users or systems trust LLM outputs without appropriate verification — treating model-generated content, decisions, or recommendations as authoritative when the model may be hallucinating, biased, or operating outside its reliable knowledge boundary.

This is as much an organisational risk as a technical one. When AI outputs drive production decisions without human review, the model’s error rate becomes the organisation’s error rate.

Why it matters for enterprises

The business impact of overreliance scales with the consequentiality of the decision. An LLM writing marketing copy can be wrong and the cost is an embarrassing typo. An LLM assessing contract clauses, evaluating credit risk, or generating security incident triage decisions can be wrong in ways that cause regulatory, financial, or operational harm.

The risk is compounded when the AI-assisted process runs faster than human attention can follow — when “the AI reviewed it” becomes a rubber stamp rather than a checkpoint.

NIST 800-53 mapping

• CM-03 (Configuration Change Control): AI-generated recommendations driving system configuration changes should go through the same change process as human-authored changes. Your CAB doesn’t care who wrote the change request.
• CA-07 (Continuous Monitoring): Monitor AI output quality over time. Track error rates, user correction patterns, and downstream incident attributions.
• AT-02 (Awareness and Training): Train staff on the limitations of LLM systems — specifically on when AI outputs require verification and what verification looks like.
• SA-11 (Developer Testing): Build verification mechanisms into AI-assisted workflows. Require human sign-off for high-stakes outputs. This isn’t slowing down AI — it’s making it reliable.

What to do Monday morning

1. Audit every AI-assisted workflow in production: which ones include human review before action, and which ones are fully automated?
2. For fully automated AI workflows, document the risk rationale. Why is human review not required? What’s the rollback mechanism?
3. Add AI output accuracy to your operational metrics. You track application error rates. Track AI error rates too.
4. Establish explicit policy: for which categories of decision is AI output authoritative, and for which does it require human verification?

dig8ital Security Factory coverage

The Security Factory is designed as a human-in-the-loop architecture by default. AI agents surface findings, recommendations, and draft actions — humans approve before execution. Confidence scoring on agent outputs surfaces uncertainty to analysts. All AI-generated security assessments include provenance metadata so reviewers know what the model had access to and what it didn’t.

---

LLM10: Model Theft

What it is

Model theft encompasses attacks that aim to extract, reproduce, or clone a proprietary AI model — either by stealing model weights directly, or by querying a deployed model sufficiently to reconstruct its behaviour (model extraction via API). Stolen models represent stolen intellectual property, lost competitive advantage, and potentially a vector for creating adversarially-tuned variants.

Why it matters for enterprises

If your organisation has invested in proprietary fine-tuning — training a model on your internal data, processes, or domain expertise — that model is an IP asset. It should be protected like one. An attacker with access to model weights can run the model offline, reverse-engineer training data characteristics, or create adversarial variants that exploit known model behaviours.

API-based extraction — reconstructing model behaviour through systematic querying — is subtler but equally concerning, particularly for models trained on proprietary knowledge.

NIST 800-53 mapping

• AC-03 (Access Enforcement): Strict access controls on model weight storage and inference infrastructure. Who can access model artefacts? Audit and enforce the list.
• SC-28 (Protection of Information at Rest): Encrypt model weights at rest. Apply the same controls as any other high-value IP asset.
• PE-03 (Physical Access Control): For on-premises model deployments, physical security controls on inference hardware.
• AU-02 (Event Logging): Monitor API access patterns for extraction attempts — unusually high query volumes, systematic coverage of input space, or queries designed to probe model boundaries.
• SC-07 (Boundary Protection): Rate limiting and access controls on inference APIs. Distinguish between legitimate operational use and systematic extraction activity.

What to do Monday morning

1. Add your proprietary fine-tuned models to your IP asset register.
2. Apply access controls to model artefact storage equivalent to your source code repository — need-to-know basis, with audit logging.
3. Implement anomaly detection on inference API usage. Define what “normal” looks like. Alert on deviations.
4. Review your AI vendor contracts: who owns model weights produced through fine-tuning on your data? Get legal clarity.

dig8ital Security Factory coverage

Security Factory agent models are treated as IP assets. Model artefacts are stored in access-controlled, encrypted repositories with audit logging. Inference APIs enforce per-client rate limits and log all access. Usage anomalies trigger security review. Vendor contracts explicitly address model IP ownership for any fine-tuning performed on customer data.

---

CISO Cheat Sheet: OWASP LLM Top 10 → NIST 800-53

OWASP LLM Risk	Risk Category	Primary NIST Controls	Quick Action
LLM01: Prompt Injection	Input Validation	SI-10, SC-07, SI-03, AC-04	Treat retrieved content as untrusted input. Add to pen test scope.
LLM02: Insecure Output Handling	Output Sanitisation	SI-10, SC-18, SI-07	Encode LLM outputs before downstream use. Sandbox code execution.
LLM03: Training Data Poisoning	Supply Chain / Integrity	SA-12, SI-07, SR-03, RA-03	Inventory training datasets. Add provenance tracking.
LLM04: Model Denial of Service	Availability	SC-05, AU-06, SI-12, CP-02	Implement token quotas. Monitor inference costs as a security signal.
LLM05: Supply Chain Vulnerabilities	Third-Party Risk	SA-12, SR-03, SR-11, SA-04, CM-03	Build AI SBOM. Pin model versions. Complete supplier assessments.
LLM06: Sensitive Information Disclosure	Data Classification	SC-28, MP-04, AC-04, SC-08, AU-02	Audit prompts for sensitive data. Update data classification policy.
LLM07: Insecure Plugin Design	API Security / Least Privilege	AC-06, SA-08, IA-08, AU-02	Scope plugin credentials. Add input validation. Enable audit logging.
LLM08: Excessive Agency	Least Functionality	CM-07, AC-05, AC-06, IR-10	Require human approval for consequential agent actions.
LLM09: Overreliance	Human Oversight	CM-03, CA-07, AT-02, SA-11	Audit automated AI workflows. Add human review checkpoints.
LLM10: Model Theft	IP Protection / Access Control	AC-03, SC-28, PE-03, AU-02, SC-07	Add model weights to IP asset register. Apply access controls.

---

The organisational gap that matters more than the technical gap

Most organisations have the controls. Most AI deployments aren’t inside them.

This happens for predictable reasons. AI projects typically start in innovation or product teams, not in security-gated environments. They move fast. They use external APIs and third-party models that haven’t been through the standard procurement process. They store data in ways that haven’t been through data classification. They grant permissions that haven’t been through least-privilege review.

By the time security teams are involved, there’s a production system to defend rather than a design to shape. The retrofit is harder and more expensive than building it right the first time.

The OWASP LLM Top 10 gives you a concrete, specific checklist for the security gates that AI projects need to pass through — before they reach production. Every item on the list translates directly to a question your security architecture review process should already be asking.

The question is whether your AI projects are in scope for that process.

---

How dig8ital Security Factory addresses these risks by design

dig8ital Security Factory is a set of AI security agents built for enterprise security operations. Every agent in the platform is designed with the OWASP LLM risk surface in mind — not as an afterthought, but as a foundational architecture constraint.

The platform’s security posture across the OWASP LLM Top 10:

Prompt Injection (LLM01): Strict separation between system instructions and user/retrieved content. All external data is treated as untrusted input. Tool execution requires explicit authorisation.

Output Handling (LLM02): All agent outputs are validated against output schemas. Code execution is sandboxed. Outputs to external systems are sanitised and logged.

Training Data Integrity (LLM03): No fine-tuning on customer data. RAG knowledge bases are version-controlled, integrity-verified, and sourced from authoritative sources.

Denial of Service (LLM04): Hard execution budgets per agent, per session, per day. Anomalous consumption triggers alerts.

Supply Chain (LLM05): Versioned AI SBOM. Model version pinning. Vendor supplier assessments. AI dependencies in CI/CD scanning pipeline.

Sensitive Data Disclosure (LLM06): Data classification enforced at the prompt layer. Conversation histories encrypted at rest. Provider data handling contracts in place.

Plugin Security (LLM07): Purpose-scoped service credentials for all tools. All tool calls logged. Sensitive operations require pre-execution authorisation.

Excessive Agency (LLM08): Three-tier action model (autonomous / supervised / blocked). No self-escalation of permissions. Human approval required for all consequential actions.

Overreliance (LLM09): Human-in-the-loop by default. Confidence scoring on agent outputs. Provenance metadata on all AI-generated assessments.

Model Theft (LLM10): Model artefacts treated as IP assets. Access-controlled, encrypted storage. Inference API anomaly detection.

---

What to do now

If you’re a CISO or security architect, the action is clear: put AI deployments inside your existing security programme scope. Today.

That means:

• AI projects through your security architecture review — before they reach production
• AI model providers through your third-party risk process — same as any Tier-1 supplier
• AI data flows through your data classification policy — including the prompt layer
• AI agent actions through your least-privilege review — tools, credentials, permissions
• AI-assisted decisions through your change management process — the CAB doesn’t care if a human or a model wrote the recommendation

The OWASP LLM Top 10 isn’t asking you to build a new security programme. It’s telling you where your existing one has gaps in scope. Close the scope gaps. Apply the controls you already have.

The controls already cover this. The question is whether the AI deployment is inside the perimeter.

---

Ready to see what enterprise-grade AI security looks like in practice?

Book a demo of dig8ital Security Factory — or explore the platform to see how each agent addresses these risks by design.

---

dig8ital builds AI-powered security operations infrastructure for enterprises. Security Factory is a suite of AI agents covering threat intelligence, vulnerability management, compliance automation, and incident response — built to operate within enterprise security frameworks, not around them.