Enterprise AI Security: What a Security Review Must Check

Enterprise AI security comes down to one question most reviews skip: does the AI show each person only what they could already open in the source tool? Check that first, then data retention, SSO and SCIM, audit logs, approvals on write actions, and the MCP connections that give AI agents reach into your systems.

The reason permissions come first is simple. An AI assistant connected to Slack, Google Drive, a CRM and Jira can find, quote and summarize in seconds what used to take someone an afternoon of digging. If access in those tools is wrong, or the AI ignores it, nobody files a ticket. The answer just contains something it should not. This guide covers what to ask an AI vendor, what a good answer looks like, and how to test the answers in a pilot.

What is enterprise AI security?

Enterprise AI security is the set of controls that keep a company's data, identities and systems safe when employees and agents use AI tools on company data. In practice it splits into two jobs:

1. Securing the AI you buy or build: what data it can reach, whose access it uses, what it stores, what it can change, and who can see what it did.
2. Defending against attackers who use AI: faster phishing, automated reconnaissance, AI-written malware.

This post covers the first job, because it is the one a buyer controls during a vendor review.

The numbers say most companies are behind on it. IBM's 2025 Cost of a Data Breach Report found that 13% of organizations reported breaches of AI models or applications, and that 97% of those lacked proper AI access controls (IBM, July 2025). The 2026 edition put the share reporting a breach that targeted AI models or applications above 20%, with the most common causes in the systems around the model: compromised APIs, applications or plug-ins (27%) and cloud misconfigurations affecting AI workloads (27%) (IBM, July 2026).

Three public frameworks give a review its vocabulary:

• NIST AI Risk Management Framework (AI RMF 1.0, January 2023) organizes AI risk work into four functions: govern, map, measure and manage (NIST AI 100-1). The Generative AI Profile, NIST AI 600-1 (July 2024), applies it to generative AI (NIST AI 600-1).
• OWASP Top 10 for LLM Applications 2025 lists prompt injection (LLM01), sensitive information disclosure (LLM02) and excessive agency (LLM06) among the top risks (OWASP).
• OWASP Top 10 for Agentic Applications for 2026, published December 2025, covers agents that plan and act across workflows (OWASP GenAI).

Why are permissions the biggest enterprise AI security risk?

Because AI does not need new access to cause a leak. It only needs the access people already have, plus the ability to search all of it at once.

Most companies have years of over-broad sharing: folders shared with "anyone at the company", channels nobody cleaned up, CRM records every rep can view. Before AI, that content was technically reachable and practically buried. Varonis, which sells data security software, analyzed 1,000 real IT environments and reported that 99% of organizations have exposed sensitive data that can easily be surfaced by AI (Varonis, 2025).

Microsoft is direct about this for Copilot. It says Copilot "only surfaces organizational data to which individual users have at least view permissions" (Microsoft Learn), and it publishes a separate blueprint to remediate oversharing before rollout (Microsoft Learn). Both statements are true at once. Respecting permissions is necessary, and it does not fix permissions that were wrong to begin with.

So a review has two permission questions, not one:

1. Does the AI enforce each source's permissions for the specific person asking, on every request?
2. Are the source permissions themselves right? That one is your job, and an AI rollout is a good reason to audit them.

Does enterprise AI respect permissions?

Most products say yes. How they do it differs, and the difference decides what you should test. There are two common designs, and many products mix them.

Neither design is permission-aware by default. What matters is whether the check runs for the specific person on every request, and whether it covers what the AI derives: summaries, extracted facts, memories, and output from agents that run unattended. Reviews miss derived data most often. If an AI turns a private Slack channel into a "project status" fact, that fact needs the channel's access rules.

What should an enterprise AI security review check?

Ask for the evidence behind each answer, not a yes. This is the checklist I would bring to any AI vendor, with what a good answer looks like.

The enterprise AI buyer's checklist covers the commercial questions that sit alongside these, and how to choose enterprise AI covers fit and rollout. For privacy regulation specifically (GDPR and similar), see data privacy compliance for enterprise AI.

How do you test permission-aware AI in a pilot?

A questionnaire tells you the design. A test tells you whether it holds.

1. Pick two test users with different access, say a manager and someone outside their team.
2. Plant canaries that carry a made-up phrase ("Project Bluefin closes March 3"): a Google Doc shared only with user A, a private Slack channel and a DM that include A but not B, and a CRM record B cannot view.
3. As user B, ask questions that would surface each canary, directly and indirectly ("what is closing in March?"). Nothing should appear, including titles or hints that the content exists.
4. As user A, confirm the same questions find the canaries, so you know the content was connected.
5. Remove A's access to the doc and time how long until A's answers stop using it.
6. As A, build a scheduled agent that summarizes the private channel and posts where B can read it. Check what B receives.
7. As B, ask the AI to edit the record B cannot edit. It should fail or wait for approval.
8. Find every step above in the audit log.

Most teams skip step 6, and it is where a sound design can still leak through configuration. An agent that runs with its owner's access and posts to a shared channel shows that channel whatever the owner can see.

What are the MCP and AI agent risks?

The Model Context Protocol (MCP) is how AI clients such as Claude, ChatGPT and Cursor connect to tools and data. Each MCP server an agent can call widens what the agent can read and do, so MCP is now part of enterprise AI security whether or not your vendor uses the term.

Two risks matter most in a review:

Prompt injection through connected content. An email, ticket or web page can carry instructions the model follows. The MCP security guide covers the attack paths and the mitigations that work.

Excessive agency. OWASP names three root causes: excessive functionality, excessive permissions and excessive autonomy. One of its listed mitigations is to "require user approval" for high-impact actions (OWASP LLM06:2025). In a review, ask for the list of write tools an agent can call, and which ones run without a person clicking approve.

Memory MCP servers deserve their own question. A memory MCP exposes stored facts about your company to any connected client, so it needs the same per-user scoping as the source tools. The comparison of MCP memory servers shows which ones are built for one developer and which for a whole company. Good vendors document this precisely: Glean says its MCP server enforces "the same ACLs, group memberships, and sharing rules as the Glean UI and APIs" (Glean docs). The Glean MCP guide walks through how that server works. Hold every vendor, Coworker included, to that level of detail.

Why does a context layer raise the stakes?

The most useful enterprise AI products combine data across tools. A context layer sits between your systems and your models and gives every AI tool the same picture of the company. A context graph links the entities in that picture: the deal, the account, the Slack thread about it, the Jira ticket blocking it.

That is exactly what makes them a security question. A single fact can be built from several sources with different access rules. "The renewal is at risk because the integration bug is still open" might combine a CRM field, a private channel and an engineering ticket. Someone who can see only one of those three should not get the combined fact.

When you review an AI memory layer, ask three things:

1. How does a derived fact inherit permissions from the sources it was built from?
2. What happens to the fact when access to one source is revoked?
3. Can you trace any fact back to its source documents?

If a vendor cannot answer the first question, the convenience of cross-tool answers comes with a quiet leak path.

Where do certifications and subprocessors fit?

Certifications show that a vendor runs its own controls well. They do not tell you what the AI does with the access you grant it. A SOC 2 Type II report covers controls such as access reviews, change management and incident response over a period of time. The guide to enterprise AI platforms with SOC 2 covers what the report includes and what it leaves out. ISO 27001 covers an information security management system, and ISO 42001 is the management-system standard written for AI. HIPAA matters if health data will flow through the tool.

Subprocessors are the part of the enterprise AI stack buyers check least. Every model provider that sees your prompts and context is a subprocessor. Products that route work across several models, often for AI cost optimization, can list more model providers than single-model tools. That is fine if the list is published and each provider's terms meet yours. It is a problem if you find out after signing. For a broader view of vendors that lead with data security, see the roundup of AI tools for enterprises with secure data.

How does Coworker handle enterprise AI security?

Coworker is an enterprise AI platform built on organizational memory, called OM2, which Coworker describes as a permission-aware knowledge graph across 50+ connectors. OM2 is an index with copied permissions, so the questions above about sync lag and derived data apply to it directly. This is what I could confirm in Coworker's code and published materials as of October 2026, including the gaps.

The agents row matters most. An owner-run agent that posts to a shared channel can show people what only the owner can open, so decide who may build agents that post outside a DM.

OM2 is also reachable from Claude, ChatGPT and other MCP-enabled clients through Coworker MCP.

When is Coworker the wrong choice?

If your review requires ISO 27001, ISO 42001 or HIPAA today, Coworker does not have them. Glean lists all three, plus SOC 2 Type II, on its security page. See Coworker vs Glean for the rest of the comparison.

If you would rather no vendor hold an index of your content, an assistant whose connectors query sources as the user fits better. Claude Enterprise lists SCIM, audit logs, a Compliance API, custom data retention controls and a HIPAA-ready offering on its pricing page. See Coworker vs Claude.

If you want cross-tool answers and agents that act across 50+ connectors with per-user permissions, bring your questionnaire and the canary test to a call. Book a demo.

Frequently asked questions

What is enterprise AI security?

Enterprise AI security is the set of controls that keep company data, identities and systems safe when people and agents use AI on company data. The core checks are per-user permission enforcement, data retention, SSO and SCIM, audit logs, approvals on write actions, MCP connections, subprocessors and certifications.

What is permission-aware AI?

Permission-aware AI only retrieves, summarizes or acts on data the asking person can already open in the source system, checked on every request. That includes summaries, extracted facts, memories and the output of agents that run unattended.

Does enterprise AI respect permissions?

Most enterprise AI tools say they do, using either live queries signed in as the user or an index that copies each item's access rules. Neither is safe by default. Test it with planted documents and two users with different access, and check how fast a revoked permission takes effect.

Does indexing company data into an AI tool break permissions?

Not by itself. An index can store each item's access rules and filter per user at query time. The risks are sync lag after access changes and derived data, such as a summary built from a private channel, that does not inherit the source's rules.

Whose permissions does an AI agent use?

It varies by vendor, so ask. In Coworker, scheduled and triggered agents run with their owner's access, and an agent @-mentioned in Slack runs as the person who mentioned it.

What are the biggest AI agent security risks?

OWASP lists prompt injection, sensitive information disclosure and excessive agency among the top risks for LLM applications. For agents, the practical controls are least-privilege tool access, per-user permissions and human approval for high-impact write actions.

Is Coworker ISO 27001 or HIPAA certified?

No. Coworker has SOC 2 Type II, GDPR and CASA Tier 2. If you need ISO 27001 or HIPAA today, Glean lists both.

Related reading

• Organizational memory (OM2)
• What is a context layer?
• What is a context graph?
• MCP security: the risks, and what mitigates them
• Enterprise AI platforms with SOC 2 compliance
• The enterprise AI buyer's checklist
• The best MCP memory servers, compared
• Glean MCP vs Coworker MCP
• Coworker vs Glean
• Coworker vs Claude