AI Security Control Catalog¶

Salient's AI Security Posture module evaluates 34 controls across 7 domains. Every control is mapped to NIST AI Risk Management Framework (AI RMF) functions and carries a risk-weighted severity.

This page is the authoritative reference. Every control. Every rationale.

Scoring summary¶

• Yes — control fully implemented (full credit)
• Partial — control partially implemented or inconsistently applied (50% credit)
• No — control not in place (0%)
• Not Applicable — excluded from scoring entirely

Control weight is based on risk severity:

See Scoring Methodology for domain weighting and the overall-score formula.

Domain 1 — Inventory & Governance¶

AI-INV-1 — AI Tool Inventory Maintained (Critical)¶

Question: Do you maintain a current inventory of all AI tools in use across the organization?

Why: You can't secure what you haven't mapped. Shadow AI is the largest blind spot in most organizations' security posture today.

Include: Sanctioned tools, shadow AI, browser extensions with AI features, SaaS products with embedded AI, internal AI deployments.

NIST AI RMF: MAP 1.1, GOVERN 1.1

AI-INV-2 — Sanctioned AI Policy Exists (High)¶

Question: Does a written AI acceptable use policy exist that defines sanctioned, restricted, and banned tools?

Why: Without a policy, employees default to whatever feels productive — usually personal AI accounts with no data protections. The policy is the basis for everything else.

NIST AI RMF: GOVERN 1.2, GOVERN 6.1

AI-INV-3 — Shadow AI Detection Process (High)¶

Question: Do you have a process to detect shadow AI usage (employees using unapproved AI tools)?

Why: You need to know where the shadow AI is before you can decide whether to sanction it or shut it down.

Options: DNS/proxy log analysis, browser policy enforcement, periodic surveys, network traffic inspection for known AI endpoints.

NIST AI RMF: MAP 1.5, MEASURE 2.5

AI-INV-4 — AI Procurement Review Process (High)¶

Question: Is there a mandatory security review process before a new AI tool can be deployed or used with company data?

Why: Procurement is the choke point where you can enforce DPA requirements, data residency standards, and vendor risk before problems compound.

NIST AI RMF: GOVERN 1.4, MAP 5.1

AI-INV-5 — AI Risk Owner Assigned (Medium)¶

Question: Is there a designated owner for AI security risk — someone accountable for the AI posture program?

Why: Without a named owner, the AI posture program stalls. The role needs authority to enforce policy, not just monitor it.

NIST AI RMF: GOVERN 2.1, GOVERN 2.2

Domain 2 — Data Governance¶

AI-DATA-1 — Data Classification Applied to AI Inputs (Critical)¶

Question: Does your data classification policy explicitly define what data categories are permitted as inputs to AI tools?

Why: This is the control that prevents customer PII, attorney-client privileged data, or regulated health records from silently flowing into consumer AI products with no data protections.

NIST AI RMF: MAP 3.1, GOVERN 1.3

AI-DATA-2 — Data Processing Agreements in Place (High)¶

Question: Do you have signed DPAs with every AI vendor that processes your data?

Why: Consumer-tier AI products typically do not offer DPAs. Enterprise tiers with contractual data protections are required for sensitive data.

NIST AI RMF: GOVERN 1.5, MAP 5.2

AI-DATA-3 — Model Training Opt-Out Confirmed (High)¶

Question: Have you confirmed with each AI vendor that your data is not used for model training, or have you explicitly opted out?

Why: Vendor defaults often permit training on inputs. Enterprise APIs usually disable this, but confirmation matters — especially for regulated industries.

NIST AI RMF: MAP 5.2, GOVERN 1.5

AI-DATA-4 — AI Data Retention Policy Defined (Medium)¶

Question: Is there a defined retention policy for AI conversation logs, generated content, and any data stored by AI vendors?

Why: Consider both your own logs (for audit trails) and vendor-side retention. Request deletion capabilities for sensitive prompts/outputs.

NIST AI RMF: MAP 3.5, GOVERN 1.3

AI-DATA-5 — RAG Pipeline Data Controls (High, skippable)¶

Question: If you use RAG systems, are the knowledge bases access-controlled and integrity-checked?

Why: RAG knowledge bases can be poisoned with adversarial documents. Validate document sources, restrict write access, monitor for unexpected retrievals.

NIST AI RMF: MEASURE 2.6, MAP 2.3

Domain 3 — MCP Security¶

AI-MCP-1 — MCP Server Inventory (Critical)¶

Question: Is there a current inventory of every MCP server connected to AI agents or AI-capable tools in your environment?

Why: MCP is becoming the integration substrate for AI agents. Unknown MCPs = unknown attack surface.

Include: Internal MCP servers, vendor-provided MCPs, custom integrations. List tools and resources each exposes.

NIST AI RMF: MAP 1.1, MAP 2.1

AI-MCP-2 — MCP Least Privilege Enforced (Critical)¶

Question: Are MCP server permissions scoped to least privilege — only the tools and resources actually needed?

Why: An MCP server for calendar access should not have write access to the filesystem. Over-scoped MCPs are how compromised agents pivot.

NIST AI RMF: GOVERN 1.6, MAP 2.2

AI-MCP-3 — MCP Authentication Enforced (Critical)¶

Question: Do all MCP servers require authentication before accepting connections?

Why: MCP servers without auth are accessible to any process that can reach them. Use token-based auth for HTTP transport; validate origin for stdio.

NIST AI RMF: GOVERN 1.6, MEASURE 2.2

AI-MCP-4 — MCP Tool Call Logging (High)¶

Question: Are all MCP tool calls logged — which agent called what, with what arguments, and what was returned?

Why: When an agent takes an unexpected action, you need reasoning traces to distinguish legitimate behavior from manipulation or compromise.

NIST AI RMF: MEASURE 2.5, MANAGE 4.1

AI-MCP-5 — MCP Supply Chain Vetting (High)¶

Question: Are third-party and open-source MCP servers reviewed for malicious tools or unexpected capabilities before deployment?

Why: A malicious MCP server can expose tools that exfiltrate data or pivot through your environment. Vet source code, pin versions, monitor for definition changes.

NIST AI RMF: MAP 5.1, GOVERN 1.4

Domain 4 — Prompt Security¶

AI-PROMPT-1 — Prompt Injection Mitigations (Critical, skippable)¶

Question: Do your AI-powered applications implement mitigations against prompt injection attacks?

Why: Prompt injection allows attackers to override system instructions. Mitigations include input validation, instruction separation, output filtering, and privilege-aware agent design.

NIST AI RMF: MEASURE 2.6, MANAGE 2.2

AI-PROMPT-2 — System Prompts Treated as Secrets (High)¶

Question: Are system prompts and agent instructions treated as sensitive configuration — not exposed to end users or in client-side code?

Why: System prompt leakage reveals business logic and bypass techniques. Never embed in client-side JS or return in API responses.

NIST AI RMF: GOVERN 1.3, MEASURE 2.5

AI-PROMPT-3 — Adversarial Prompt Testing (High, skippable)¶

Question: Are your AI applications red-teamed or tested with adversarial prompts before deployment and after significant changes?

Why: Jailbreak attempts, indirect injection via documents, role-play bypass, and multilingual attacks. Automated fuzzing + manual testing.

NIST AI RMF: MEASURE 2.6, MANAGE 2.1

AI-PROMPT-4 — Output Filtering Applied (High, skippable)¶

Question: Is there an output filtering layer between AI model responses and end-user presentation or downstream system actions?

Why: Unfiltered AI output can contain harmful content, leaked data, or instructions that trigger downstream vulnerabilities (e.g. XSS in rendered markdown, SQL in generated queries).

NIST AI RMF: MEASURE 2.6, MANAGE 2.2

Domain 5 — Agent Security¶

AI-AGENT-1 — Agent Permissions Scoped (Critical, skippable)¶

Question: Are all autonomous AI agents running with least-privilege permissions — no more access than their specific task requires?

Why: An agent that only needs to read calendar events should not have email send or file write permissions.

NIST AI RMF: GOVERN 1.6, MAP 2.2

AI-AGENT-2 — Human-in-the-Loop for High-Risk Actions (Critical, skippable)¶

Question: Do autonomous agents require human approval before executing irreversible, destructive, or high-impact actions?

Why: Define a taxonomy of action risk levels. Auto-approve low-risk reads; require confirmation for writes, sends, deletes, and external API calls.

NIST AI RMF: GOVERN 1.7, MANAGE 1.3

AI-AGENT-3 — Agent Action Logging (High, skippable)¶

Question: Are all autonomous agent actions logged — what the agent did, why (the reasoning trace), and what was the result?

Why: Logs must be immutable and centrally stored. Reasoning traces help distinguish legitimate action from compromise.

NIST AI RMF: MEASURE 2.5, MANAGE 4.1

AI-AGENT-4 — Agent Containment and Blast Radius (Critical, skippable)¶

Question: Are autonomous agents sandboxed or network-segmented so that a compromised agent cannot pivot to sensitive systems?

Why: Map the blast radius: if an agent is compromised via prompt injection, what can it reach? Constrain network egress, filesystem access, inter-service reachability.

NIST AI RMF: MAP 2.2, MANAGE 2.4

AI-AGENT-5 — Agent Identity & Credentials (High, skippable)¶

Question: Do autonomous agents use dedicated service identities and credentials, rather than shared or human user credentials?

Why: Shared human credentials make attribution impossible and credential rotation dangerous. Use service accounts with narrow scopes.

NIST AI RMF: GOVERN 1.6, MEASURE 2.2

Domain 6 — Access Control¶

AI-ACCESS-1 — AI Tool Access Least Privilege (High)¶

Question: Is access to AI tools and platforms managed through role-based access controls aligned to least privilege?

NIST AI RMF: GOVERN 1.6, MAP 2.2

AI-ACCESS-2 — AI API Keys in Secrets Manager (Critical)¶

Question: Are all AI provider API keys stored in a dedicated secrets manager rather than in code, dotfiles, or environment variables checked into source control?

Why: Hardcoded or committed API keys are one of the most common causes of AI cost abuse and data exfiltration.

NIST AI RMF: GOVERN 1.6, MEASURE 2.2

AI-ACCESS-3 — MFA for AI Platform Access (High)¶

Question: Is MFA enforced for access to AI provider consoles, developer portals, and admin interfaces?

Why: An attacker with stolen credentials and no MFA can exfiltrate all API keys, view usage logs, modify billing.

NIST AI RMF: GOVERN 1.6

AI-ACCESS-4 — AI Access Reviews (Medium)¶

Question: Are AI tool access grants reviewed regularly, with access removed for departing employees and role changes?

Why: Former employees with active AI tool access are a persistent risk. Include AI tools in your joiners/movers/leavers process.

NIST AI RMF: GOVERN 1.6, MANAGE 1.4

Domain 7 — Monitoring & Incident Response¶

AI-MON-1 — AI Usage Monitoring (High)¶

Question: Is AI tool usage monitored for anomalous patterns that could indicate misuse, compromise, or data exfiltration?

Why: Sudden spikes in token usage, access from unexpected IPs, or PII patterns in prompts are early indicators. Route AI provider logs to your SIEM.

NIST AI RMF: MEASURE 2.5, MANAGE 4.1

AI-MON-2 — AI Incident Response Plan (High)¶

Question: Does your IR plan specifically cover AI-related incidents — prompt injection, rogue agent behavior, API key compromise, data exfiltration via AI tools?

Why: Generic IR plans don't cover AI-specific containment steps (disable API key, revoke MCP token, roll back agent state).

NIST AI RMF: MANAGE 4.1, MANAGE 4.2

AI-MON-3 — AI Scenarios in TTX Program (Medium)¶

Question: Has your organization conducted tabletop exercises specifically covering AI security scenarios — prompt injection, MCP compromise, rogue agent behavior?

Why: Simulating an agentic attack before it happens is the highest-leverage preparation you can do. Salient's TTX engine ships with these scenarios built in.

NIST AI RMF: MANAGE 4.2, MEASURE 2.7

AI-MON-4 — Cost Anomaly Alerts (Medium)¶

Question: Are cost anomaly alerts configured for all AI API accounts to detect runaway agent loops or API key abuse?

Why: Compromised API keys or runaway agents can generate thousands of dollars of charges before manual discovery. Set hard spending limits and alert thresholds.

NIST AI RMF: MANAGE 4.1, MEASURE 2.5