Shipping AI Agents to Enterprise: The Security Evidence Buyers Ask For

If you are a startup CTO preparing an enterprise rollout — or the diligence process ahead of a round — you will hit a security questionnaire. For conventional software, those questionnaires are a known drill. For agentic software, the questions have changed: buyers are asking how your agent decides what to execute, what it can reach, and what happens when it is manipulated. Claims do not answer those questions. Evidence does.

One framing that helps: enterprise security reviewers are not asking you to prove your agent is “safe” in the abstract. They are asking whether their existing risk model — least privilege, input validation, network segmentation, auditable actions, incident kill switches — has an answer inside your architecture. Most of the work below is mapping agent-specific controls onto language their rubric already understands.

What enterprise reviewers actually ask

Security teams evaluating an AI agent are not checking a list of AI buzzwords. They are translating their existing control framework onto a new kind of component. The recurring questions in reviews and procurement processes cluster into six evidence categories:

1. Dependency and composition evidence

An SBOM for the agent and its model/tool dependencies, plus evidence that known-vulnerable versions are tracked. Agents inherit risk from every MCP server and tool wrapper they integrate; reviewers want the full list, pinned versions, and a process for updates.

2. Static scanning evidence

Proof that security scanning runs continuously — not a one-time screenshot. CI runs, findings history, and the policy that gates merges on critical findings. SARIF reports attached to pull requests are the kind of artifact reviewers recognize and trust.

3. Agent-specific control evidence

This is the section conventional vendors do not have and you will be expected to:

• Tool permissions: an allowlist of tools per agent role, with least-privilege credentials.
• MCP server hardening: TLS, authenticated servers, no secrets in config, egress restrictions to internal and metadata addresses.
• Prompt injection handling: a documented boundary that treats fetched content as untrusted data, plus tests showing injected instructions do not redirect tool calls.
• Command execution controls: argument-array invocation, command allowlists, sandboxed execution environments.

4. Runtime verification evidence

Reviewers increasingly ask what checks each agent output passes before it is acted on. The Correctover Conformance Standard (CCS) frames this as seven verification dimensions — Structure, Schema, Latency, Cost, Identity, Integrity, Security — documented in the framework paper archived at Zenodo (DOI: 10.5281/zenodo.21783723). Showing that outputs are verified against a named, published framework — rather than an ad hoc guardrail — converts a vague question into a concrete answer.

5. Independent assessment

Self-attestation has a credibility ceiling, especially for security claims touching production data. An independent audit report — with enumerated findings, severities, and fixes — is the artifact that lets a reviewer sign off without redoing the assessment. It is also reusable: the same report serves the enterprise customer, the next two customers behind them, and the diligence process in a fundraise.

6. Data-handling evidence

Where credentials live (secrets manager, not config files), what tool calls log and what they redact, network egress boundaries, and a tested kill switch. These map to standard control language but need agent-specific details: reviewers know that an agent with shell-capable tools and ambient cloud credentials is a different risk than a chatbot.

Expect the review to take place twice: once during the security questionnaire, and again when the customer’s own agent deployments expand and they revisit every vendor in the chain. An evidence pack assembled once — scan history, CI configuration, verification logs, framework reference, and audit report — answers both passes with the same artifacts, and it answers them the same way for every prospect, which is also how a small security team survives an enterprise pipeline without custom responses per deal.

Two questions that decide the review

Across enterprise security reviews of agent products, two questions correlate with stalls more than any others. The first is “what can the agent do that it was not told to do?” — answerable only with evidence of tool allowlists, output validation, and adversarial testing, not with architecture adjectives. The second is “what happens when it is manipulated?” — answerable with the prompt-injection boundary design, the runtime verification results, and an independent report showing the injection-to-execution paths were traced and closed. Reviews that have documents attached to both questions move; reviews that answer both with “we use a guardrail” do not. Everything else in the questionnaire is standard vendor diligence that your SOC 2 and pen-test materials already cover.

Building the evidence pack, in order

The useful property of this evidence is that it doubles as your own baseline — you are not producing paperwork, you are putting controls in place and capturing their output:

1. Local scan, now. npx correctover-scan auto-detects MCP config files in the repository and reports credential exposure, transport gaps, SSRF exposure, timeouts, and related findings. Package on npm, source on GitHub.
2. Gate it in CI. Add the correctover-scan GitHub Action with critical findings failing the build and SARIF uploaded to the Security tab. The run history becomes your continuous-scanning evidence.
3. Verify outputs at runtime. The ccs-verifier package (PyPI) applies the CCS dimension checks to agent outputs in your tool-call path. Logged verification results answer the “what happens per request” question.
4. Order an independent audit before the RFP. The Agent Output Audit reviews agent code, MCP configuration, and runtime traces with 116 semantic intent rules grounded in disclosed MCP ecosystem CVEs — covering command injection, SSRF, credential leakage, and prompt injection — and returns a PDF report with concrete fixes within roughly five working days.

The artifact map: question to evidence

When the questionnaire arrives, speed comes from having the artifact before the question. A practical mapping:

• “How do you scan for vulnerabilities?” → link to the CI workflow running the scan action on every pull request, plus a sample SARIF report.
• “What prevents the agent from running arbitrary commands?” → the tool allowlist, the argument-array invocation pattern in code, and the sandbox description.
• “How do you handle prompt injection?” → the untrusted-content boundary design plus adversarial test results from the audit report.
• “How are credentials managed?” → secrets-manager configuration, a config scan showing zero inline secrets, and the process-level environment scoping.
• “What validation runs on outputs?” → the CCS dimension checks in the tool-call path and the framework reference (Zenodo DOI 10.5281/zenodo.21783723).
• “Has this been assessed independently?” → the audit PDF.

Timing it around a raise

Fundraising diligence asks the same questions as enterprise procurement, often via a technical advisor reading your repo. Evidence here compounds: an audit report commissioned before the raise answers the security section of the diligence checklist, becomes sales collateral for enterprise customers afterward, and the CI gates that produced the scanning history are the same gates your engineering team benefits from regardless. The order that minimizes total work is controls first (they generate the artifacts automatically), independent assessment second (it validates the controls), and then reuse the same pack in every review that follows — rather than reconstructing evidence from scratch under deadline, which is how this step tends to stall deals.

Cost of delay

Security review is on the critical path of enterprise sales timelines, and it is the stage where agentic vendors stall: deals do not usually die because the demo failed, they die because the vendor cannot answer “what stops your agent from executing something malicious” with anything more specific than a guardrail description. The evidence pack — scan history, CI gating, a published verification framework, and an independent report — is what moves the review from open-ended questions to attached files. Assemble it before the first questionnaire arrives, and the security review becomes a step your deal passes through rather than a gate it waits at.