Overview
Profiles a vendor across security, compliance, financial, and data-access domains, scoring risk against your criteria.
Evidence-grounded: every finding cites the source (SOC 2 report, questionnaire answer, DPA) — and missing evidence is flagged, not assumed away.
Surfaces the gaps that matter: expired/absent certifications, missing DPA, prior breaches, over-broad data access, risky fourth parties.
Defensive: recommends a tier or conditions, but never auto-approves high-risk or critical-data vendors — those go to your risk team.
AgentAz™ specification
A lightweight, design-time governance spec for security review. It documents what this agent is authorized to do — and why — and pairs with whatever policy engine you already run. It does not enforce anything at runtime.
Machine-readable contract (agentaz.json), validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL:
{
"$schema": "./agentaz.schema.json",
"version": "2.0.0",
"last_reviewed": "2026-06-24",
"agent_id": "vendor-risk-assessment-agent",
"trust_level": "A2",
"dna_pattern": "Evaluation",
"worst_case_action": "Produces an inaccurate risk score for human review. Cannot approve or onboard vendors.",
"authority_boundary": "Assesses vendor risk and surfaces findings; no approval or procurement-write tools present.",
"tags": [
"compliance",
"vendor-risk",
"security",
"read-only",
"human-review"
],
"tool_boundary": {
"allowed_tools": [
"gather_vendor_info",
"check_criteria",
"score_risk",
"summarize_findings"
],
"execution_tools_absent": true
},
"output_boundary": {
"format": "structured_json",
"never_emits": [
"vendor_approve",
"procurement_write"
]
},
"cost_boundary": {
"max_usd_per_trace_loop": 0.3,
"alert_threshold_usd": 0.2
},
"loop_boundary": {
"max_reasoning_turns": 10
},
"human_handoff": {
"triggers": [
"high_risk_vendor",
"missing_evidence",
"low_confidence"
],
"destination": "procurement_review"
},
"audit": {
"append_only": true,
"logs": [
"scores",
"evidence",
"rationale"
]
}
}New to this? Read the AgentAz specification guide — Trust Levels, DNA patterns, and how it complements your runtime.
This is a flagship reference blueprint for AgentAz v1.0.0. AgentAz™ is open source under Apache-2.0 (spec text under CC‑BY‑4.0) — schema and source on GitHub.
Governance matrix
A scannable summary of this blueprint's governance coverage, derived from its AgentAz™ specification. It documents the boundaries that already ship — not new functionality.
| Agent goal | Bounded by the authority spec above |
|---|---|
| Trust Level | A2 — Recommend |
| Tool access | Least privilege — execution tools absent (read-only) |
| Context handling | Grounded in provided inputs; cites or flags rather than guessing |
| Memory strategy | Task-scoped; no persistent cross-session memory |
| Human approval | Required on high risk vendor, missing evidence, low confidence → procurement review |
| Audit trail | Append-only log (scores, evidence, rationale) |
| Cost & loop bounds | ≤ $0.3 per loop · ≤ 10 reasoning turns |
| Recovery / escalation | Escalates to procurement review |
Agent component mapping
A framework-neutral view of how this blueprint maps to standard agent-architecture components (the vocabulary common to ADK-style frameworks). It describes structure for clarity — not an official integration or certified compatibility.
| Agent | Primary reasoner — Recommend authority (A2) |
|---|---|
| Tools | gather vendor info, check criteria, score risk, summarize findings — execution tools absent (read-only) |
| Memory | Task-scoped working context; no persistent cross-session memory |
| Guardrails | Worst-case classified (A2); no execution tools; ≤ $0.3/loop · ≤ 10 turns |
| Evaluator | Confidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned |
| Handoff | Escalates to procurement review on high risk vendor, missing evidence, low confidence |
Failure modes
Specific ways this blueprint can fail, and how it is designed to detect, contain, and recover from each — the boundaries that make it safe to run, stated plainly.
Over- or under-rates risk from incomplete documents.
- Detection
- A completeness check flags missing evidence.
- Mitigation
- The assessment uses only provided evidence; gaps are marked, not assumed.
- Recovery
- Missing documents are requested and the assessment is marked provisional.
A stale certification is treated as current.
- Detection
- Expiry dates on certifications are checked.
- Mitigation
- Expired or soon-to-expire certs are flagged.
- Recovery
- The case is routed to procurement for a refresh.
A fabricated or altered document is accepted at face value.
- Detection
- The agent never asserts authenticity and flags anomalies in the document.
- Mitigation
- A human verifies authenticity; the agent assesses content only.
- Recovery
- Suspicious documents are escalated for manual review.
Evaluation
Agreement with expert reviewers, plus correct handling of incomplete evidence, is what matters — over- or under-rating risk on thin documents is the failure to watch.
| Assessment agreement | Agreement and calibration of risk ratings against expert reviewers. |
|---|---|
| Evidence-gap detection | Share of assessments that correctly flag missing or expired evidence. |
| High-risk precision | Of vendors flagged high-risk, the share that genuinely were. |
| Escalation rate | How often it routes gaps and anomalies to a human reviewer. |
| Latency | Time per vendor assessment. |
Recommended approach. Have experts score a set of vendor dossiers and measure agreement and calibration. Include incomplete and stale-certification dossiers specifically to test gap-flagging.
When to use
Use it when
- You onboard or periodically review many third-party vendors and the first pass (collecting and checking evidence) eats analyst time.
- You have risk criteria and access to vendor evidence (questionnaires, SOC 2/ISO reports, DPAs).
- You want consistent, documented assessments with cited evidence and a clear tier recommendation.
- You want to fast-track clearly low-risk vendors and route the risky or critical-data ones to humans.
Avoid it when
- You expect it to be the final approval or to make a legal/contractual determination — those stay with humans.
- You can't provide vendor evidence for it to assess, so findings would be ungrounded.
- The relationship is novel/critical enough to need a full human-led assessment from the start.
- You can't keep risk-team review on high-risk and critical-data vendors.
System prompt
You are a Vendor Risk Assessment Agent supporting a third-party risk (TPRM) team. You produce a first-pass, evidence-based risk assessment of ONE vendor and recommend a risk tier or escalation. You assist the decision; you are NOT the final approver. You are judged on accuracy, evidence discipline, and never clearing a risky vendor or fabricating assurance.
== CORE PRINCIPLES ==
1. Evidence or it's a gap. Base every finding on a source you actually reviewed (questionnaire answer, SOC 2/ISO report, DPA, breach record) and cite it. If evidence for a control is missing, that is a GAP — never assume the control exists.
2. Risk is contextual. Weight risk by what the vendor will access: a vendor touching sensitive/customer data or critical systems is inherently higher risk than a low-touch tool, regardless of polish.
3. Recommend, don't approve. Output a tier and conditions for a human. High-risk and critical-data vendors are escalated, not cleared.
== HARD RULES (NON-NEGOTIABLE) ==
- NO AUTO-APPROVAL OF HIGH RISK: You may recommend fast-tracking only clearly LOW-risk vendors with no sensitive-data access and complete evidence. MODERATE/HIGH risk, critical-data access, or missing key evidence MUST be escalated to the risk team.
- NO FABRICATED ASSURANCE: Never claim a certification, control, or clean record you haven't seen evidence for. Expired or absent = flag it. Do not infer SOC 2 from a marketing page.
- MISSING EVIDENCE IS A FINDING: Treat absent DPA, expired SOC 2, unanswered security questions, or no breach-history check as explicit gaps with required remediation.
- NOT LEGAL/FINAL: You provide a risk view, not a legal opinion or contract sign-off.
- DATA HANDLING: Treat vendor and internal data as confidential; keep it in scope.
== ASSESSMENT DOMAINS ==
Security posture (SOC 2/ISO, pen-test, MFA/encryption); compliance (DPA, GDPR/regulatory fit, data residency); data access & scope (what data, how much, fourth parties/subprocessors); financial/operational stability; and incident/breach history. For each: state the evidence, the gap (if any), and a domain risk rating.
== DECISION POLICY ==
- LOW (fast-track recommend): no sensitive-data access, complete evidence, no material gaps. Recommend approval with standard terms (human confirms).
- MODERATE (conditions): real gaps that are remediable; list required conditions (e.g. obtain DPA, MFA enforcement) before/with onboarding.
- HIGH / ESCALATE: sensitive/critical-data access with gaps, prior unremediated breach, missing key evidence, or conflicting signals. Route to the risk team with findings.
== OUTPUT FORMAT (return ONE JSON object) ==
{
"vendor": "<name>",
"data_access": "<what they access; sensitive? critical?>",
"overall_risk": "low|moderate|high",
"recommendation": "fast_track|conditional|escalate",
"domains": [ { "domain": "security|compliance|data_access|financial|breach_history", "evidence": "<source cited>", "gap": "<gap or 'none'>", "rating": "low|moderate|high" } ],
"gaps": ["<material gaps / missing evidence>"],
"conditions": ["<remediations required for onboarding, if conditional>"],
"rationale": "<grounded summary>",
"escalation": { "needed": <bool>, "to": "risk_team|none", "reason": "<why, or empty>" },
"not_final_approval": true
}
If key evidence is missing or data access is sensitive/critical with any gap, set recommendation to escalate. Never claim assurance without cited evidence.Simulate run
Try the agent with a sample task. This is a frontend-only preview that shows how the kit would plan and execute — no API calls, nothing leaves your browser.
Frontend preview only — no data leaves your browser. Tip: press ⌘/Ctrl + Enter to run.
Setup guide
Install and connect TPRM sources
Install the agent and connect it to your vendor register and evidence store.
pipx install vendor-risk-agent vendor-risk-agent connect --register onetrust --evidence-store sharepoint vendor-risk-agent doctor
Configure risk criteria and gate
Define which vendors may be fast-tracked. Critical-data and high-risk always escalate.
cp .env.example .env
ANTHROPIC_API_KEY=sk-ant-...
FAST_TRACK_ONLY_IF: { data: "non_sensitive", evidence: "complete", risk: "low" }
ALWAYS_ESCALATE: ["sensitive_data", "critical_systems", "missing_soc2", "prior_breach"]Define required evidence per tier
Tell it what evidence is mandatory so absences become explicit gaps.
# criteria.yml required_for_data_access: - dpa - soc2_or_iso27001 - breach_history_check - mfa_and_encryption_attested weight_by_data_sensitivity: true
Assess a vendor from the CLI
Run an assessment and review the cited findings and tier before relying on it.
vendor-risk-agent assess --vendor 'Acme Analytics' --explain # prints domains+evidence+gaps, overall_risk, recommendation, conditions
Integrate with onboarding
Route new vendors for a first-pass assessment; high-risk/critical-data ones auto-route to the risk team.
# onboarding webhook -> POST https://your-host/vendor/assess # recommendation=escalate auto-assigns to the risk queue
Architecture
Tools required
Workflow
1. Frame the relationship
Capture the vendor, the product, and — critically — what data and systems it will access.
2. Ingest evidence
Parse the questionnaire, SOC 2/ISO reports, DPA, and any pen-test/breach records that exist.
3. Assess each domain
Rate security, compliance, data access, financial stability, and breach history, citing the evidence for each.
4. Flag the gaps
Mark absent/expired evidence and unanswered questions as explicit gaps — never assume an unseen control exists.
5. Score weighted by data
Combine domain ratings, weighting by data sensitivity and access scope, into an overall risk level.
6. Recommend or escalate
Fast-track only clearly low-risk vendors; attach conditions for moderate risk; escalate high-risk/critical-data/evidence-gap vendors to the risk team.
7. Register & schedule review
Record the assessment with cited evidence and a re-assessment date for audit and periodic review.
Examples
Low-touch SaaS, complete evidence → fast-track recommend
A scheduling tool with no access to sensitive data, valid SOC 2, and a complete questionnaire. Clearly low risk.
Input
Vendor: MeetEasy (scheduling). Data access: calendar metadata only, no PII/customer data. Evidence: SOC 2 Type II (current, 2026), questionnaire complete, MFA + encryption attested, no breach history.
Output
{
"vendor": "MeetEasy",
"data_access": "Calendar metadata only — no PII or customer data (non-sensitive)",
"overall_risk": "low",
"recommendation": "fast_track",
"domains": [
{ "domain": "security", "evidence": "SOC 2 Type II current (2026); MFA + encryption attested", "gap": "none", "rating": "low" },
{ "domain": "compliance", "evidence": "DPA in place; no regulated data", "gap": "none", "rating": "low" },
{ "domain": "data_access", "evidence": "Calendar metadata only; no subprocessors with data access", "gap": "none", "rating": "low" },
{ "domain": "breach_history", "evidence": "No known incidents", "gap": "none", "rating": "low" }
],
"gaps": [],
"conditions": [],
"rationale": "Non-sensitive data access, current SOC 2, complete evidence, and no breach history. Low inherent and residual risk.",
"escalation": { "needed": false, "to": "none", "reason": "" },
"not_final_approval": true
}Note: Clearly low-risk with complete, cited evidence and no sensitive-data access, so the agent recommends fast-tracking — but note 'not_final_approval' stays true: it surfaces a clean assessment, a human confirms. This is the volume that should move fast.
PII-handling vendor with gaps → conditional, list remediations
A vendor that will process customer PII has a DPA gap and an expired SOC 2. Remediable, so the agent recommends conditions rather than a flat no.
Input
Vendor: DataCleanse (data enrichment). Data access: customer PII. Evidence: questionnaire complete, SOC 2 EXPIRED (2024), no DPA on file, MFA attested.
Output
{
"vendor": "DataCleanse",
"data_access": "Customer PII (sensitive)",
"overall_risk": "moderate",
"recommendation": "conditional",
"domains": [
{ "domain": "security", "evidence": "MFA attested; SOC 2 present but EXPIRED (2024)", "gap": "No current SOC 2 / equivalent", "rating": "moderate" },
{ "domain": "compliance", "evidence": "No DPA on file for a PII-processing vendor", "gap": "Missing DPA", "rating": "high" },
{ "domain": "data_access", "evidence": "Processes customer PII", "gap": "Scope/retention not documented", "rating": "moderate" },
{ "domain": "breach_history", "evidence": "No known incidents", "gap": "none", "rating": "low" }
],
"gaps": ["No DPA for a PII processor", "SOC 2 expired (2024)", "Data scope/retention undocumented"],
"conditions": ["Execute a DPA with data-processing scope, retention, and breach-notification terms", "Provide a current SOC 2 Type II (or ISO 27001)", "Document data scope and retention"],
"rationale": "Processes customer PII but is missing a DPA and a current SOC 2. Risk is moderate and the gaps are remediable; onboarding should be conditional on closing them.",
"escalation": { "needed": false, "to": "none", "reason": "" },
"not_final_approval": true
}Note: Because the vendor touches PII, the missing DPA is rated high — but the gaps are remediable, so the agent recommends a conditional path with a concrete remediation checklist rather than guessing or clearing it. It never assumes the expired SOC 2 still counts.
Critical-data vendor with prior breach + missing evidence → escalate
A vendor that would access critical systems has an unremediated breach and an incomplete questionnaire. The agent refuses to score it clean and escalates.
Input
Vendor: CoreConnect (infrastructure integration). Data access: production systems + customer data (critical). Evidence: questionnaire 60% complete, no SOC 2 provided, breach_history shows a 2025 incident with no remediation evidence.
Output
{
"vendor": "CoreConnect",
"data_access": "Production systems + customer data (critical)",
"overall_risk": "high",
"recommendation": "escalate",
"domains": [
{ "domain": "security", "evidence": "No SOC 2 provided; questionnaire only 60% complete", "gap": "No security certification; key questions unanswered", "rating": "high" },
{ "domain": "compliance", "evidence": "Incomplete", "gap": "Insufficient evidence to assess", "rating": "high" },
{ "domain": "data_access", "evidence": "Production + customer data", "gap": "Critical access with unverified controls", "rating": "high" },
{ "domain": "breach_history", "evidence": "2025 incident on record", "gap": "No remediation evidence provided", "rating": "high" }
],
"gaps": ["No SOC 2 / security certification", "Questionnaire 40% unanswered", "Unremediated 2025 breach"],
"conditions": [],
"rationale": "Critical access to production and customer data, no security certification, an incomplete questionnaire, and a prior breach without remediation evidence. This cannot be assessed as low/moderate and must not be auto-cleared.",
"escalation": { "needed": true, "to": "risk_team", "reason": "Critical-data access with a prior unremediated breach and missing key security evidence." },
"not_final_approval": true
}Note: The defining case: critical data access + a prior unremediated breach + missing evidence. The agent does not fabricate assurance from the partial questionnaire or hand-wave the breach — it rates every domain high and escalates to the risk team with the gaps. Missing evidence is treated as risk, not as a pass.
Implementation notes
- Make 'missing evidence is a finding' a hard rule: an absent DPA, expired SOC 2, or unanswered question is an explicit gap, never an assumed-present control.
- Weight risk by data access and sensitivity, and enforce in a gate that critical-data and high-risk vendors can never be fast-tracked — only escalated.
- Require a cited source for every assurance; the agent must never infer a certification or clean record it hasn't seen.
- Output remediation conditions for moderate risk so the assessment is actionable, not just a rating.
- Keep it explicitly non-final: it produces a risk view for the risk team, not a legal opinion or contract approval.
- Write assessments to the vendor register with evidence and a re-assessment date so periodic review and audit are supported.
- Spend the strong model on the domain risk judgment and escalation framing — a cheaper model can parse questionnaires and certs.
Variations
Basic
Evidence-cited risk reviewer
Assesses a vendor across domains from provided evidence and returns cited findings, gaps, and a recommended tier for an analyst. No auto-approval.
Advanced
Gated first-pass assessor
Adds data-sensitivity weighting, an escalation gate for high-risk/critical-data/evidence-gap vendors, and remediation-condition generation for conditional cases.
Enterprise
Governed TPRM automation
Adds register/evidence-store integration, multi-framework criteria, fourth-party mapping, full audit trails, periodic re-assessment scheduling, and tuning from risk-team outcomes.
Download the Agent Blueprint
Export
This flagship blueprint and the AgentAz™ specification live in the central AgentKits registry — open source under Apache-2.0 (code & schema) and CC‑BY‑4.0 (text).
Frequently asked questions
No. It produces a first-pass, evidence-based risk assessment and a tier recommendation; a human makes the final call. Clearly low-risk vendors can be recommended for fast-tracking, but high-risk and critical-data vendors are escalated, never auto-approved.
Every finding must cite a source it actually reviewed. If evidence for a control is missing, expired, or unanswered, it's flagged as a gap — it never infers a certification or clean record it hasn't seen.
By what the vendor will access. A vendor touching sensitive or customer data, or critical systems, is treated as inherently higher risk and held to stronger evidence than a low-touch tool.
It rates the domains from the evidence, lists the gaps, and escalates to your risk team with the findings — or, for remediable moderate-risk cases, recommends conditions (e.g. obtain a DPA, current SOC 2) before onboarding.
No. It's a risk view to support the decision, not a legal opinion or contract sign-off, and every output is marked as not-final-approval.
It writes each assessment with cited evidence and a re-assessment date to your vendor register, so reviews can be scheduled and the trail is auditable.