> 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/start-here/what-is-ai-security.md).

# What is AI Security?

A plain-language scope for AI security in this handbook: helping security practitioners roll out AI tools, agents, connectors, and data access safely across the business.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
This handbook is about securely rolling out AI to the enterprise. It is written for security practitioners who need to help the business use AI tools, agents, connectors, and data safely.
{% endhint %}

## Scope of this handbook

AI security, in this handbook, means the controls and operating practices needed when employees and business teams use AI at work.

The goal is practical: help a security practitioner decide which AI products can be used, by whom, with what data, through which tools, under what approvals, and with what evidence left behind.

That includes workforce chat, coding agents, browser and desktop agents, hosted agents, API applications, low-code agent builders, connectors, MCP servers, plugins, skills, hooks, local files, generated artifacts, scheduled tasks, and downstream SaaS actions.

It does not mean a general guide to building foundation models, training models, or red-teaming your own model architecture. Those disciplines matter, but they are not the main problem this handbook is solving.

## In scope and out of scope

| Area                  | In scope for this handbook                                                                                           | Out of scope for this handbook                                                                                   |
| --------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Enterprise AI rollout | How to approve, configure, monitor, and govern AI tools used by employees and teams.                                 | Broad AI strategy, productivity coaching, or vendor marketing comparisons.                                       |
| Workforce AI tools    | ChatGPT Work, ChatGPT Codex, Claude Cowork, Claude Code, Claude Tag, connectors, apps, and agent workflows.          | Consumer-only guidance with no enterprise controls or evidence path.                                             |
| Data protection       | What data can enter AI tools, where it can go, how it is retained, and how to prove controls work.                   | General privacy theory without a deployment decision attached.                                                   |
| Runtime control       | Sandboxes, browser and desktop access, filesystem boundaries, approvals, egress, autonomy, and scheduled work.       | Low-level model internals or accelerator security.                                                               |
| Extensibility         | MCP servers, plugins, skills, hooks, connectors, agent builders, and other ways users extend AI systems.             | Generic software supply-chain guidance that never touches AI execution paths.                                    |
| Threats and testing   | Prompt injection, tool poisoning, exfiltration, confused-deputy paths, and abuse-case testing of deployed workflows. | Red-teaming a frontier model itself, model eval research, or adversarial ML research as a standalone discipline. |
| Evidence              | Audit logs, OTel, endpoint telemetry, source-system logs, SIEM routing, and investigation paths.                     | Logging theory that cannot answer what a user or agent actually did.                                             |

## The practitioner question

A security team should be able to answer this before expanding access:

> Can this group use this AI capability for this business workflow without exposing unacceptable data, granting uncontrolled action authority, or losing the evidence needed to investigate what happened?

If the answer is not clear, narrow the rollout. Reduce the data class, remove write actions, disable high-risk connectors, tighten sandboxing, require approvals, or run a smaller pilot until the evidence is good enough.

## Why AI security is different from SaaS security

Traditional SaaS security starts with accounts, roles, app permissions, and logs. Those controls still matter. AI adds new paths through prompts, retrieved context, model outputs, tool calls, generated files, browser sessions, local code execution, MCP servers, scheduled tasks, and agent actions.

A normal SaaS review might ask whether a user can access a file. An AI security review also asks whether an agent can read that file, summarize it into another system, call a tool with its contents, write a derived artifact, publish a link, or continue the task later without the user watching.

That is why the handbook focuses on the full chain:

* **Identity:** who is using the product, and which human or non-human identity is taking the action.
* **Data:** what the AI can read, retrieve, store, transform, and share.
* **Tools:** which connectors, MCP servers, apps, plugins, skills, hooks, and APIs can be called.
* **Runtime:** where the work runs, what it can execute, which files it can touch, and where network traffic can go.
* **Authority:** what requires approval, what can happen automatically, and what can be reversed.
* **Evidence:** which records prove what happened, and where the gaps are.

## How to assess a workflow

Assess the workflow, not only the product name. One business task can start in chat, move into a desktop app, touch local files, call a connector, launch a hosted task, and write to a SaaS system.

Use this order:

1. **Name the business workflow.** Example: employee research, sales account prep, code changes, finance analysis, support drafting, contract review, or incident triage.
2. **Map the surface.** Identify whether it uses workforce chat, a coding agent, browser or desktop control, hosted agents, API applications, or low-code builders.
3. **Classify the data.** Record whether the workflow can touch public, internal, confidential, regulated, customer, employee, source code, or secrets data.
4. **List the actions.** Separate read-only work from writes, sends, publishes, deletes, purchases, production changes, and unattended tasks.
5. **Review extensions.** Inventory connectors, MCP servers, plugins, skills, hooks, apps, tools, memory, and knowledge sources.
6. **Set the boundary.** Configure identity, roles, sandboxing, egress, approvals, DLP, retention, and connector scope for the actual risk.
7. **Prove the evidence.** Run a canary test and confirm the activity appears in provider logs, OTel where available, endpoint logs, source-system logs, and the SIEM path.

## Where to start

For a new enterprise rollout, start with a small set of business use cases and a controlled user group. Do not enable every AI capability at once.

A crisp starting baseline is:

* Managed identity and lifecycle controls for every approved AI product.
* Separate groups for normal users, builders, admins, coding-agent users, connector exceptions, and high-risk pilots.
* Approved data classes by product and workflow.
* Default-deny or tightly scoped connector and MCP access.
* Sandbox and approval controls for local code, file, browser, desktop, and agent execution.
* A retention and training-data decision before sensitive data is allowed.
* OTel, audit, endpoint, and source-system evidence tested before expansion.
* An incident path that can revoke users, tasks, connectors, agent identities, credentials, and published artifacts.

The useful output is not a policy document alone. It is a working control plan with owners, settings, tests, exceptions, evidence, and a review date.

## How this handbook is organized

* **Identity & Access:** managed sign-in, provisioning, roles, tenant restrictions, agent identities, credentials, and approval authority.
* **Supply Chain & Extensibility:** connectors, MCP servers, plugins, skills, hooks, tools, dependencies, and agent-builder inputs.
* **Runtime, Sandbox & Autonomy:** isolation, filesystem access, browser and desktop control, egress, approvals, scheduled tasks, and hosted execution.
* **Data Protection & Residency:** data classes, DLP, retention, training use, derived data, cross-app flows, secrets, and residency.
* **Threats & Adversarial:** prompt injection, exfiltration, tool poisoning, supply-chain attacks, abuse-case testing, threat modeling, and incident response for deployed workflows.
* **Observability, Audit & Evidence:** audit gaps, compliance APIs, OpenTelemetry, SIEM routing, usage analytics, investigations, and control review.
* **Rollout & Operations:** pilots, readiness gates, security checklists, vendor-neutral control mapping, exceptions, and ongoing governance.

## Frequently asked questions

### Is this handbook for model builders?

Not primarily. Model builders may find useful control ideas here, especially around tools, data, telemetry, and incident response. The core audience is the security team responsible for enterprise use of AI tools and agents.

### Does this cover AI red teaming?

Only where testing supports a deployed enterprise workflow. The handbook covers prompt-injection tests, exfiltration tests, abuse cases, and control validation for products employees use. It does not try to be a full guide to red-teaming a foundation model.

### What is the first question a practitioner should ask?

Ask what the AI can access and what it can do. If the workflow can reach sensitive data or take meaningful action, raise the control posture before expanding access.

### What does a good rollout decision look like?

A good decision names the approved users, allowed data, enabled tools, action limits, required approvals, evidence sources, owner, review date, and rollback path. If any of those are missing, the rollout is still a pilot.

## Related handbook guidance

* [AI Security Handbook](/ai-security-handbook.md)
* [How to Use This Handbook](/start-here/how-to-use-this-handbook.md)
* [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md)
* [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan.md)
* [Glossary](/start-here/glossary.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/start-here/what-is-ai-security.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.