AI Security Due Diligence Before You Ship an Agent
AI security due diligence before shipping an agent: a pre-launch checklist across the model, tools, memory, identity, and compliance — with go/no-go criteria.
AI security due diligence is the disciplined review you run before an agent reaches production users — the point at which a security failure stops being an internal bug and starts being an incident with real-world consequences. Once an agent has credentials, tools, and live traffic, the cost of a missed vulnerability multiplies: an over-privileged token that leaked in staging is a note in a backlog; the same token exploited in production is a breach notification. Due diligence is how you find those problems while they are still cheap to fix.
This post is a practical pre-launch checklist. It walks through what to verify across every layer of an agent before you ship, gives concrete go/no-go criteria, and frames the decision honestly: shipping an agent is a risk decision, and due diligence is what lets you make it deliberately rather than by accident. It draws on the agent attack surface map, the MAESTRO threat model, and the OWASP agentic risk set covered in our testing guide.
What Due Diligence Is — and Is Not
Security due diligence for an agent is a structured verification that the controls you believe are in place actually are, and that the residual risk is understood and accepted by someone with the authority to accept it. It is not a single scan, not a compliance checkbox, and not a substitute for ongoing security operations.
Two failure modes bracket it. The first is shipping with no diligence at all — trusting that because the agent “works” it is safe, which conflates functional correctness with security. The second is treating a one-time review as permanent assurance, forgetting that agents change: a new tool, a model update, or a new data source silently reopens risks the review closed. Due diligence is a gate at launch and a repeated gate at every material change, feeding into a standing MLSecOps practice.
The Pre-Launch Checklist
Work through each layer. For every item, the standard is evidence, not assertion — “we tested it and here is the result,” not “it should be fine.”
Model and Prompt
- System prompt does not leak. Attempt extraction; confirm the agent will not reveal its instructions or guardrails.
- Injection resistance tested. Run direct and indirect prompt injection suites, including encoded, multi-language, and Unicode-obfuscated variants. Confirm injections that land are contained by outer controls.
- Model version pinned. The exact model and version in production is recorded, and you have a process to re-test on provider updates.
- Instructions and data separated. Untrusted content is marked as data via structured roles, not concatenated into instructions.
Tools and Actions
- Tool inventory complete. Every tool, API, and MCP server the agent can call is enumerated — no undocumented capabilities.
- Manifests verified. Tool manifests are signed or hashed, pinned at approval, and re-verified on load to defeat rug pulls and tool poisoning.
- Parameters constrained. Tool-call arguments are validated against schemas and allowed values; no path for shell metacharacters or unexpected recipients.
- Dangerous chains gated. State-changing or exfiltrating tool sequences require human confirmation.
Memory and Data
- Retrieval treated as data. Documents from RAG and memory are processed as data, not instructions; RAG poisoning tests pass.
- Data-handling compliant. Sensitive data flows meet DPDP Act, GDPR, or applicable obligations; no PII in logs or outputs it should not be in.
- Memory scoped and validated. Persistent memory is scoped per user/session and validated before use.
Identity and Privilege
- Least privilege enforced. Every credential and tool permission is the minimum required. No standing broad access.
- Short-lived credentials. Tokens are scoped and time-limited, ideally just-in-time provisioned; no long-lived static keys.
- No credential exposure. Keys, tokens, and secrets appear in no log, error message, tool output, or agent response.
- Blast radius mapped. For a successful compromise at any layer, you know exactly what it can reach — and it is acceptably small.
Multi-Agent and Human Interface
- Inter-agent comms authenticated. If agents talk to each other, messages are authenticated and replay-protected.
- High-impact actions mediated. State-changing actions surface the real action to a human, with distinct treatment to counter approval fatigue.
- Kill switch tested. An emergency halt exists and stops all agents within a defined SLA, with no orphaned processes.
Observability and Compliance
- Logging sufficient to investigate. Tool calls, provenance, and decisions are logged enough to reconstruct an incident.
- Anomaly detection live. Deviations from a behavioural baseline — unusual tool sequences, unexpected recipients — are alertable.
- Framework mapping done. Controls map to NIST AI RMF and, where relevant, the EU AI Act, with audit-ready evidence. See our NIST AI RMF testing guide.
Go / No-Go Criteria
A checklist without a decision rule invites rationalising away the awkward findings. Set the bar before you test.
No-go (do not ship) if any of these hold:
- A prompt injection can reach a state-changing tool or sensitive data without human confirmation.
- Any tool runs with credentials broader than its function requires and the blast radius reaches sensitive systems.
- Credentials appear in any output or log channel.
- Code execution is possible without a sandbox that blocks host, network, and secret access.
- There is no way to halt the agent in an emergency.
Conditional-go (ship with compensating controls and a fix deadline) for medium-severity findings where a monitoring or mediation control caps the impact and remediation is scheduled.
Go when critical and high findings are remediated, residual risk is documented, and an accountable owner has explicitly accepted it. That acceptance — named, dated, and recorded — is the artefact that makes shipping a deliberate risk decision rather than a hope.
Who Owns the Decision
Due diligence produces evidence; someone must own the risk. In practice that is a security lead or engineering owner with the authority to say no, and a governance process that records the decision. The most dangerous pattern is a review that surfaces real findings which then dissolve under launch pressure with no one accountable for the trade-off. Naming an owner and recording their acceptance is what turns due diligence from theatre into governance — and what protects the organisation if a finding you accepted later becomes an incident.
For teams without in-house AI security depth, an independent assessment before launch provides both the evidence and an outside perspective that internal pressure cannot easily override.
FAQ
What is AI security due diligence? It is a structured pre-launch review verifying that an agent’s security controls actually work across the model, prompt, tools, memory, identity, multi-agent, and compliance layers — and that any residual risk is understood and formally accepted. It is a gate at launch and again at every material change, not a one-time checkbox.
When should I run security due diligence on an agent? Before the agent reaches production users, and again whenever it changes materially — a new tool integration, a model version update, a new data source, or a change to its permissions. Each of these can silently reopen risks a prior review closed, so due diligence is a recurring gate feeding an ongoing security practice.
What are the top go/no-go criteria before shipping an agent? Do not ship if a prompt injection can reach a state-changing tool or sensitive data without human confirmation, if any tool has credentials broader than its function with a sensitive blast radius, if credentials leak into any output or log, if code execution lacks a strict sandbox, or if there is no emergency kill switch. Ship only when critical and high findings are fixed and an accountable owner has recorded acceptance of the residual risk.
Can we do due diligence in-house or do we need an assessment? Teams with genuine AI security expertise can run internal due diligence using a structured checklist and red-team tooling. Many teams lack that depth, and an independent assessment adds both specialist coverage and an outside perspective that resists internal launch pressure. Even mature teams benefit from independent validation before high-risk launches.
Ship With Confidence, Not Hope
Shipping an agent is a risk decision. Due diligence is how you make it deliberately. We run pre-launch assessments that work this checklist end to end — model, tools, memory, identity, multi-agent, and compliance — and deliver an audit-ready report with clear go/no-go findings mapped to OWASP and NIST AI RMF.
Want to review your launch plan first? Book a 30-minute call, email security@aivyuh.com, or see our enterprise engagement models.
Related reading: