Enterprise Customer Security Reviews for Integration Features

Enterprise security reviews for AI integration features probe concerns that standard SaaS questionnaires were never built to handle. Model behavior, data flows, execution-layer access, and AI-specific attack surfaces each demand their own line of questioning. Teams that treat the AI review as a longer version of the usual checklist stall at the first wave of follow-ups. Knowing which layer a question belongs to is what lets you answer it usefully.

Why the traditional SaaS security questionnaire breaks down for AI integrations

Traditional software security rests on assumptions that stop holding once AI enters the stack. You can separate instructions from data. Artifacts sit inert until you run them. Privilege gets granted deliberately. Coalition for Secure AI walked through each of these at RSAC 2026 and showed where every one collapsed.

The examples were not subtle. A coding assistant committed a supply chain attack via a README prompt injection, poisoning dependencies and pushing to a repository. A model file executed a reverse shell the moment it loaded. An agent integration handed over access to more than 700 Salesforce environments for an extended period without tripping a single alert. None of these were caught by the controls most organizations rely on. The gap is structural, not a matter of filling in a few extra rows.

Enterprise buyers learned this the hard way. Since 2025 they have added AI-specific categories to their questionnaires: data handling, model security, output safety, AI supply chain, and data privacy. Major new AI features like new model integrations, new data sources, or new output types now require a focused AI-specific review before production deployment, on top of the baseline SaaS questionnaire. The old checklist was built for software that sits still. AI moves.

How data flow questions probe what happens to customer data before, during, and after inference

When a prompt or completion makes a hop, enterprise security reviewers treat it as a potential exposure event. They expect you to trace that path with precision, not describe it in general terms. You'll be asked whether customer data is used in model training and whether it can influence outputs for other customers. You'll need to explain how training data is segregated from inference data and where inference actually runs.

The questions keep coming: Does customer data leave your infrastructure for model processing? Are prompts and completions logged, and who can see those logs? What happens to customer data after the contract ends? For multi-model or adversarial-pipeline architectures, the data flow is not one hop. It's a chain: a draft agent, a critique agent, a compliance agent, and possibly an external model API. Each transition is a boundary the reviewer will want documented.

The supply chain question is live in this layer too. Reviewers ask which third-party model providers sit in the stack, whether that's OpenAI, Anthropic, or open-source models. They want to know how each provider's security posture is assessed and what happens if one gets compromised. Proprietary corpora passed to commercial APIs carry specific risk. Coalition for Secure AI guidance treats model dependencies as an extension of the software bill of materials concept. Data non-retention agreements with upstream providers are the minimum control you can expect.

What passes review here is specific and evidenced. Named providers, documented data residency, an explicit retention policy, and confirmation of whether prompts and completions get logged and by whom. "We follow best practices" fails. A named policy with a dated audit reference passes.

What reviewers mean when they ask about model security — and why prompt injection is the center of that question

Prompt injection, not jailbreaking or hallucination, is the primary attack vector reviewers probe when they ask about model security. It's the mechanism that turns a data input into an instruction crossing a trust boundary. The Kilo Code vulnerability, tracked as CVE-2025-11445, is the clearest documented case. An attacker embedded malicious instructions in a README file. The AI assistant ingested it during normal repository analysis, treated the injected prompt as a legitimate task, modified its own configuration to allow previously blocked git commands, and committed poisoned dependency changes to the repository. The attack vector was a markdown file, not malware.

Coalition for Secure AI established the core principle in response: agent permission boundaries cannot be modified through natural language instructions. That directly closes the Kilo Code pattern and is now the baseline standard reviewers reference. The pattern keeps showing up because it's universal. Researchers found 30 vulnerabilities across every major AI IDE they tested, with confirmed exploits in Cursor, AWS Kiro, and OpenAI Codex CLI.

Reviewers will ask what guardrails exist against jailbreaking, how system prompt exposure is prevented, and what stops the model from leaking training data. These are distinct from prompt injection but share the same remediation principle: the model's behavior must be bounded by the harness around it, not by the model itself. The model doesn't need to be replaced to change the security posture. The harness controls whether boundaries hold. So the review is really about the harness architecture, not which model sits underneath.

The execution layer: why tool invocations and agent permissions are what enterprise security teams actually audit

Enterprise security teams have done solid work controlling which AI tools employees can access. But that work leaves the execution layer open, and in production AI systems that's where attacks happen. When an AI agent acts, it does so through a tool invocation. It calls an API, writes to a database, triggers a workflow, or pushes instructions to a connected system. Most enterprises have no policy enforcement at this layer. Tool invocations are trusted by default.

AGAT Software's 2026 analysis describes the structural vulnerability. Prompt injection attacks don't need to breach the perimeter. They only need to manipulate an agent into using a tool it already has access to, through text embedded in a document, email, or API response. Agents inherit whatever access the user who launched them had, which often means everything. When multiple agents share credentials, attribution becomes impossible. The SIEM sees a series of failed transactions but cannot identify which agent started a cascade or where it was compromised.

Reviewers now expect four things at this layer. Continuous agent discovery means a live inventory of every agent operating in the environment, including homegrown automations, browser extensions, SaaS-based agents, and MCP server connections. Least-privilege scoping means every agent operates with the minimum permissions needed for its task, since overprivileged agents convert a single prompt injection into full lateral movement. Behavioral monitoring means runtime visibility into what agents are doing, because agents drift and an approved agent can be manipulated after the fact. And an AI agent gateway intercepts every tool invocation request before execution, evaluates it against policy, and approves or blocks it. AGAT's framework describes that as the shift from reactive log review to proactive enforcement.

Cisco AI Defense expanded in February 2026 to add runtime protections against tool abuse and supply-chain scanning and governance at the MCP layer, covering AI BOM and MCP Catalog. Its presence signals that execution-layer governance is now core enterprise security infrastructure, not a specialist concern. Organizations that treat agents as first-class security principals have a much cleaner picture of what's happening in their environment. They can attribute actions, scope blast radius, and isolate a compromised agent without taking down workflows.

How watermarking and model fingerprinting requirements have entered the security review

Regulatory mandates have made AI output watermarking a compliance expectation that enterprise security reviewers now ask about directly. The technical method matters as much as the policy. It's lexical, not metadata. Some AI companies now embed a signature in the words the model chooses, baked into token selection at inference time rather than added to the text afterward. That means it survives copy-paste and format conversion in ways metadata tags do not.

Model fingerprinting is a parallel and harder problem. A paradigm presented at ICLR 2026 proposes fingerprinting via semantically conditioned watermarks. Entire semantic domains serve as fingerprint queries. Any query in French triggers a fingerprint signal, for example. The model embeds a statistical signal whose strength grows with token count, yielding robustness against perturbation.

The strongest objection reviewers raise is that detection tools are probabilistic and defeatable. OpenAI discontinued its standalone AI writing detector in 2023 due to low accuracy. The PAN 2026 Voight-Kampff task was designed to develop methods for reliable and robust detection of generative AI, including in the presence of adversarial text modifications and obfuscated authorship scenarios. Enterprises relying on third-party detection rather than cryptographic watermarks embedded at inference time are working with signals that can be defeated.

What passes review in this area is a clear statement of which watermarking method is used, whether it's inference-time or post-hoc, which regulatory regimes it satisfies, and how the vendor will respond if a detection API becomes available to enterprise customers rather than only regulators. For multi-model writing pipelines, the question gets more complex. If output passes through multiple models before delivery, which model's watermark survives the chain? Reviewers will ask, and they expect a documented answer.

What the AI supply chain section of a security review actually covers

Enterprise reviewers treat the AI supply chain as attack surface that is the vendor's responsibility to assess, not the buyer's to accept on faith. That includes model providers, model files, skill registries, and MCP servers. The skill registry problem has reached marketplace scale. A registry grew to more than 10,700 entries in a matter of months. When researchers audited the ecosystem broadly, they found exposed credentials in a significant share of skills reviewed and outright malware in 76 confirmed payloads. A separate coordinated campaign called ClawHavoc distributed over 341 malicious skills. Traditional security missed this because there is no code bug to find. The tool worked as designed. The injection vector was a markdown file no SAST tool treats as executable.

Serialization formats are a live concern too. Formats like pickle execute code the moment a model file is loaded, before any inference happens. Reviewers will ask how model files are validated before loading, not just after deployment. Coalition for Secure AI guidance recommends gating the ML pipeline on signature verification and verifying model attestations at every consumption phase. CoSAI has identified an AI-specific SBOM covering model provenance as a current gap, not yet an established recommendation. These are now the baseline controls a prepared vendor should be able to demonstrate.

Routing AI-generated content through the same SAST and review pipeline used for third-party code is the recommended pattern. The analogy is deliberate: an AI-generated output has the same trust level as third-party code until it passes the same gates. For writing systems specifically, the supply chain question extends to voice corpus provenance. Reviewers may ask where training data for brand-specific fine-tuning originates, how it's validated, and whether it flows to a commercial API under a data non-retention agreement. Corpus ingestion is a supply chain event, not just a configuration step. This section is often where reviews stall the longest, because vendors have clear answers for their own code and no documented process for their dependencies.

What enterprise reviewers expect as evidence — and what "we follow best practices" costs you

Enterprise security reviewers distinguish between claims and evidence. For AI integrations the evidentiary bar has risen to include AI-specific penetration testing, documented remediation, and runtime controls, not just compliance certifications. The questionnaire arrives after the product demo impresses the buying team and before legal sends the contract. It's the gate between interest and revenue. "We follow best practices" is the answer that stalls the deal.

What enterprise buyers expect for penetration testing is a recent report from an independent tester who attempted to exploit the application, not a scanner report. Scanner reports list potential vulnerabilities with CVSS scores. Pentest reports include exploitation evidence: screenshots, request/response pairs, and proof-of-concept demonstrations showing the tester actually exploited the vulnerability. For AI companies specifically, the pentest must cover AI-specific vectors: prompt injection, data leakage, excessive agency, and model manipulation. A web application pentest that doesn't cover these is not sufficient, and a prepared reviewer will ask whether the test scope included them.

The answer that passes is specific, dated, scoped, with remediation documented. "We conducted AI-specific penetration testing in March, testing for prompt injection, data leakage, and excessive agency. Findings were remediated and retested. Report available under NDA." Runtime controls that reviewers now expect to see demonstrated, not just described, include agent discovery with a continuous inventory, behavioral monitoring, execution-layer policy enforcement through a gateway or equivalent, and least-privilege scoping with documented per-agent permission boundaries. Coalition for Secure AI's core principle that agent permission boundaries cannot be modified through natural language instructions is now a reference standard. Reviewers familiar with CoSAI's published guidance will ask whether your architecture satisfies it. For writing infrastructure vendors, the same evidentiary standard applies to the writing pipeline: documented data flows, a named list of model providers, a stated watermarking method, corpus ingestion controls, and a pentest that covered the output layer, not just the application layer.