> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/reference/governance-and-frameworks/g.5-sans-critical-ai-security-guidelines-mapping.md).

# G.5 SANS Critical AI Security Guidelines mapping

How the handbook controls map to the SANS Critical AI Security Guidelines for a practitioner-first cross-check.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
The SANS community repository identifies version 1.1, published in April 2025, as the current public version. It organizes the guidance into Access Controls, Data Protection, Deployment Strategies, Inference Security, Monitoring, and Governance, Risk, Compliance.
{% endhint %}

This page maps the handbook to the SANS categories and to the practitioner questions security teams usually ask when they read AI security guidance:

* Do we know which AI tools are being used?
* Are users on managed accounts?
* Is sensitive data blocked or monitored?
* Are connectors, plugins, MCP servers, and agents reviewed?
* Can agents act without approval?
* Are prompts, files, tool calls, and outputs logged?
* Have we tested prompt injection and exfiltration?
* Do we know who owns incidents and exceptions?

## How to use this page

Use the mapping during intake and quarterly review.

During intake:

* Mark the deployment model.
* Mark the data classes.
* Select the applicable controls.
* Assign owners.
* Record the evidence required before pilot and production.

During review:

* Check whether the tool still matches the original deployment model.
* Check whether new connectors, agents, browser control, desktop control, or code execution were enabled.
* Check whether evidence still exists and is recent.
* Check whether incidents, user complaints, or vendor changes require a stronger posture.

## Additional practitioner cross-checks

The SANS guidance also calls out model protection, augmentation data, model hosting choices, public model risk, prompt and output filtering, focused functionality, API abuse monitoring, model registries, and AI bill-of-materials tracking. The handbook should cover those items through the controls above plus the more detailed pages on supply chain, runtime, data protection, threat modeling, and evidence.

## Suggested minimum posture

For workforce chat:

* SSO and managed accounts.
* Approved tool list.
* Data classification guidance.
* DLP where available.
* Retention and training-use review.
* Audit exports or clear evidence gap.

For coding agents:

* Managed identity.
* Repository trust model.
* Sandbox and approval policy.
* MCP, plugin, skill, hook, and dependency review.
* Secrets protection.
* SIEM routing for command, denial, and tool events.

For browser or desktop agents:

* Explicit cohort approval.
* Endpoint and browser controls.
* Connector and signed-in session review.
* Approval for sensitive write actions.
* Prompt-injection tests against untrusted content.
* Evidence map that includes endpoint, browser, SaaS, and AI platform logs.

For hosted agents and API apps:

* Agent identity and scoped credentials.
* Tool allowlist.
* Egress controls.
* Runtime logging and tracing.
* Abuse-case testing.
* Kill switch and token revocation.
* Vendor resilience and incident evidence.

## Common SANS Critical AI Security Guidelines mapping security failures

* The team says it follows SANS guidance but cannot point to system-level evidence.
* The inventory lists AI vendors but not connectors, agents, or model APIs.
* Prompt injection is tested only in chat, not in tool-using workflows.
* A policy bans sensitive data but no DLP, logging, or review confirms it.
* Security owns the policy while business teams publish low-code agents without review.
* Exceptions do not expire.

## SANS Critical AI Security Guidelines mapping security controls checklist

* Map every guideline to a handbook control and evidence artifact.
* Keep deployment models separate.
* Require evidence before production, not after an incident.
* Re-run the mapping after major vendor feature releases.

## Frequently asked questions about SANS Critical AI Security Guidelines mapping

### Why include this page if the handbook already maps to NIST and ISO?

SANS guidance is written for practitioners who need to secure AI deployments, not only report a management-system posture. NIST and ISO explain program structure. This mapping turns the SANS categories into the specific handbook pages and evidence a team can act on.

### Should this page cite OWASP and MITRE instead?

OWASP and MITRE are better for threat and abuse-case coverage. This page is broader: access, data, deployment, inference, monitoring, and governance. Keep OWASP and MITRE in the threat-modeling and red-team pages, and use this page for the SANS control cross-check.

### What is the most important evidence item?

The inventory. Without a current AI inventory, the team cannot know which controls, owners, logs, or notices apply.

## Applicable handbook articles

This handbook crosswalk maps the public SANS v1.1 control objectives to the most relevant handbook articles and example evidence. It is not an official SANS mapping.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                                                                                       | SANS coverage and example evidence                                                                                                                                                                                                                   |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Identity & access                     | <p>1.1 SSO & SCIM for AI platforms<br>1.2 RBAC across AI platforms<br>1.3 Tenant restrictions: blocking personal accounts<br>1.5 Agent and non-human identity<br>1.6 API keys and service accounts governance<br>1.7 Human-in-the-loop and approval policies</p>                                                          | Access Controls: authentication, authorization, least privilege, and accountable user, agent, and API access. Evidence includes identity settings, role exports, access reviews, and key inventories.                                                |
| 2. Connectors, extensions & supply chain | <p>2.1 Connectors and apps: the integration backbone<br>2.2 MCP servers: securing the protocol<br>2.3 MCP gateways and allowlisting<br>2.7 The supply-chain review workflow<br>2.8 Signing and packaging<br>2.10 Hosted-agent framework dependencies</p>                                                                  | Deployment Strategies, Inference Security, and GRC: integration allowlists, package integrity, dependency review, and AI bills of materials. Evidence includes approved integration inventories, review records, signatures, and dependency records. |
| 3. Runtime, sandboxing & autonomy        | <p>3.1 Sandbox and isolation models<br>3.2 Approval policies and least-privilege autonomy<br>3.3 Network egress control<br>3.4 Internet access and browser automation<br>3.8 File and filesystem access controls<br>3.9 Central hosted-agent runtime hardening</p>                                                        | Deployment Strategies and Inference Security: sandboxing, egress, external functions, file access, and hosted-runtime boundaries. Evidence includes sandbox policy, egress rules, tool restrictions, and runtime configuration.                      |
| 4. Data protection                       | <p>4.1 DLP for GenAI<br>4.2 Data classification for AI prompts and outputs<br>4.3 Data residency and regional inference<br>4.4 Retention and Zero Data Retention<br>4.5 Training opt-out and data usage<br>4.6 Cross-app data flow and live artifacts<br>4.7 Secrets and credential hygiene in prompts and tools</p>      | Data Protection: classification, DLP, hosting, retention, provider training use, data flows, and secrets. Evidence includes data rules, provider settings, flow diagrams, and secrets scans.                                                         |
| 5. Threats & adversarial testing         | <p>5.1 Prompt injection: the connective risk<br>5.2 Data exfiltration via tools and connectors<br>5.3 Supply chain attacks and notable CVEs<br>5.4 Agent-specific threats: tool poisoning and confused deputy<br>5.5 Red-teaming AI systems<br>5.6 Incident response for AI systems<br>5.7 Threat modeling AI systems</p> | Inference Security, Monitoring, and GRC: injection, leakage, supply-chain and agent threats, testing, incident response, and threat modeling. Evidence includes threat models, test reports, detections, and incident records.                       |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.2 OpenTelemetry for AI runtime<br>6.4 Analytics and usage APIs<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p>                                                                     | Monitoring and GRC: audit coverage, runtime telemetry, API-usage monitoring, SIEM detections, evidence paths, and review. Evidence includes log samples, alerts, detection rules, and review records.                                                |
| 7. Rollout & operations                  | <p>7.1 Roll out by risk: the phased plan<br>7.2 Pilot design and success metrics<br>7.3 The security team checklist<br>7.4 The vendor-neutral control matrix</p>                                                                                                                                                          | Deployment Strategies and GRC: risk-based rollout, pilots, readiness checks, and control documentation. Evidence includes inventory, risk decisions, gate approvals, exceptions, and review minutes.                                                 |

## Further reading

The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page.

* [SANS Critical AI Security Guidelines repository](https://github.com/sans-community/ai-guidelines). The repository still identified v1.1 as current when checked on July 14, 2026, even though its README lists an older planned date for the next publication.
* [SANS Critical AI Security Guidelines v1.1](https://github.com/sans-community/ai-guidelines/blob/current-version/SANS_Critical_AI_Security_Guidelines_v1.1.md)
* Related control sources: [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework), [NIST CSF 2.0](https://www.nist.gov/cyberframework), [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/), and [MITRE ATLAS](https://atlas.mitre.org/).

## Related handbook guidance

* [Governance & Frameworks](/reference/governance-and-frameworks.md)
* [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md)
* [G.1 Map your controls to NIST AI RMF and CSF 2.0](/reference/governance-and-frameworks/g.1-map-your-controls-to-nist-ai-rmf-and-csf-2.0.md)
* [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems.md)
* [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/reference/governance-and-frameworks/g.5-sans-critical-ai-security-guidelines-mapping.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.