13. AI Security, Privacy, and Guardrails - AI Application Development with JavaScript: Complete Beginner-to-Production Masterclass (2026)

Threat Modeling for AI Features

Threat-model the whole system, not only the model prompt. Identify assets (secrets, tenant documents, user data, tool capabilities), trust boundaries, attackers, and possible harms. Common threats include prompt injection, data exfiltration, cross-tenant retrieval, unsafe tool execution, insecure output rendering, denial of wallet through expensive requests, and dependency or provider compromise.

Use defense in depth: authentication, authorization, input limits, output encoding, retrieval filters, tool allowlists, egress controls, rate limits, logging, and human approval for high-impact operations. A refusal response from a model is helpful but not a security control.

Diagram

Threat boundary checklist

Browser -> API authentication -> request limits
API -> retrieval authorization -> tenant filter
Model -> tool proposal -> schema + policy validation
Tool -> scoped credentials -> audit log
Output -> safe rendering -> user

💡 Each boundary should have a named control and a test. Ask what happens if the model output is malicious, malformed, or entirely wrong.

Key Takeaways

Map assets, trust boundaries, and failure modes.
Use defense in depth.
Test adversarial cases, not only happy paths.

Knowledge Check

What is the correct security posture for model refusals?

Prompt Injection and Data Exfiltration

Prompt injection attempts to make the model disregard policy, reveal protected information, or misuse tools. It can appear in user messages, retrieved documents, emails, web pages, code comments, and images. Treat retrieved text as untrusted evidence. Never place secrets in context unless absolutely necessary; if the model can see a secret, prompt wording cannot reliably guarantee it will never be repeated.

Limit tool capabilities and data scope. A search tool should enforce the current user's permissions; an email tool should not send messages without appropriate confirmation; a database tool should expose a small, validated query interface rather than arbitrary SQL. Add adversarial tests that try to cross tenant boundaries or trigger unauthorized actions.

Tool allowlist

const allowedTools = new Map([
  ["searchKnowledgeBase", searchKnowledgeBase],
  ["getCurrentUserProfile", getCurrentUserProfile]
]);

async function executeTool(name, args, context) {
  const tool = allowedTools.get(name);
  if (!tool) throw new Error("Tool not allowed");
  return tool(args, context);
}

💡 The allowlist limits the available functions but is not enough by itself: each tool must validate arguments, enforce object-level authorization, and limit returned data.

Key Takeaways

Assume any external content may contain hostile instructions.
Do not expose secrets unnecessarily to the model.
Enforce tenant authorization inside data access tools.

Knowledge Check

What is the safest response to a retrieved document instructing the model to reveal another tenant's records?

Output Safety, XSS, and Sensitive Data

Model output is untrusted text. Render Markdown and HTML safely, sanitize any permitted HTML, and avoid direct unsanitized insertion into the DOM. Treat code, links, citations, and tool arguments as data. Validate URLs before making them clickable, especially schemes and hosts. If the model generates SQL or code, do not execute it automatically in a privileged environment.

Sensitive data handling includes minimization, redaction, retention, access controls, encryption in transit and at rest, and provider-specific review. Logs should be useful for debugging but should not become a secondary database of secrets or private conversations.

Safe text rendering

// Prefer textContent for plain text:
messageElement.textContent = modelResponse;

// If rendering Markdown, use a maintained renderer plus sanitization
// and an explicit link/HTML policy rather than injecting raw HTML.

💡 Using textContent prevents HTML interpretation for plain text. Rich Markdown needs a reviewed rendering pipeline, safe URL handling, and sanitization of any allowed HTML.

Key Takeaways

Escape plain text and sanitize permitted rich content.
Validate generated links and tool arguments.
Redact sensitive values in logs and define retention.

Knowledge Check

Why should model output be treated as untrusted when rendered in a web page?

Rate Limits, Quotas, and Abuse Prevention

AI endpoints can be abused to consume expensive tokens, flood providers, or extract data at scale. Apply per-user and per-tenant rate limits, maximum input/output sizes, request timeouts, concurrency limits, and budget alerts. Use idempotency for retried jobs and queue bulk processing instead of allowing unbounded fan-out.

Rate limits should account for model cost and workload, not just request count. A 100-token classification request and a large multimodal request have different resource profiles. Return retry guidance for throttling and avoid exposing provider credentials or internal quota details unnecessarily.

Quota policy sketch

const limits = {
  requestsPerMinute: 20,
  maxInputCharacters: 20_000,
  maxOutputTokens: 1_000,
  maxConcurrentJobs: 3
};

// Enforce server-side per user/tenant, before provider invocation.

💡 These are illustrative values, not universal defaults. Derive limits from provider quotas, product requirements, user tiers, abuse patterns, and measured cost per request.

Key Takeaways

Limit both frequency and request size.
Track cost by user, tenant, feature, and model.
Queue expensive batch work and set budget alerts.

Knowledge Check

Why is request-count-only rate limiting insufficient for AI workloads?

Threat Modeling for AI Features

Prompt Injection and Data Exfiltration

Output Safety, XSS, and Sensitive Data

Rate Limits, Quotas, and Abuse Prevention

STAY UPDATED WITH BYTES!