Third-Party Integration Enablement Approval Prompt

This prompt is designed for security, procurement, and platform engineering teams who need to generate a structured, auditable approval request before enabling a third-party integration. The core job-to-be-done is to move from an informal integration request to a formal, risk-assessed approval package that can be reviewed by a human decision-maker. The prompt takes raw details about a vendor and the requested access and produces a standardized document covering vendor identity, requested OAuth scopes or API permissions, a data flow summary, compliance certifications, and data residency implications. It is not a general vendor risk assessment tool; it is specifically for the 'last mile' enablement decision where an API key, webhook, or OAuth client is about to be activated.

The ideal user is an engineer or security analyst who has already gathered the necessary vendor details but needs to package them into a consistent, non-negotiable format for an approver. The prompt requires specific inputs to be effective: the vendor's legal name, the exact scopes or permissions being requested, a description of the data that will flow to and from the vendor, the vendor's relevant compliance certifications (like SOC 2 or ISO 27001), and the required data residency regions. Without this context, the model will generate a vague, unactionable request. The output is not the approval itself; it is a structured brief that makes the approval decision faster and more consistent by ensuring no critical security or compliance questions are missed.

Do not use this prompt for low-risk, pre-approved integrations where a lightweight automated check is sufficient. It is over-engineered for connecting a linter to a repository. Use it when the integration involves access to production data, PII, financial records, or critical infrastructure. The prompt's value is in enforcing a rigorous checklist before a potentially dangerous connection is established. After generating the approval request, the next step is to route it to the designated human approver through a review queue or ticketing system. Never use the model's output to auto-approve the integration; the entire purpose of this workflow is to insert a mandatory human judgment gate before an irreversible action.

This prompt template is designed to be wired into a security or procurement review workflow. It takes structured inputs about a vendor integration request and produces a standardized approval payload that a human reviewer can act on. The template uses square-bracket placeholders for all dynamic fields, making it straightforward to populate from an internal API, a form submission, or a prior classification step. The output is a JSON object that can be rendered in a review UI, posted to an approval queue, or logged as an audit record.

textCopy
You are an integration security reviewer. Your task is to produce a structured third-party integration enablement approval request. Use only the information provided in the input fields. Do not invent vendor details, certifications, or data flows.

INPUT:
- Vendor Name: [VENDOR_NAME]
- Vendor Website: [VENDOR_WEBSITE]
- Integration Type: [INTEGRATION_TYPE] (OAuth, Webhook, API Key, other)
- Requested Scopes/Permissions: [REQUESTED_SCOPES]
- Data Flow Description: [DATA_FLOW_DESCRIPTION]
- Data Classification: [DATA_CLASSIFICATION] (Public, Internal, Confidential, Restricted)
- Data Residency Requirements: [DATA_RESIDENCY_REQUIREMENTS]
- Compliance Certifications Provided: [COMPLIANCE_CERTIFICATIONS]
- Data Processing Agreement (DPA) Status: [DPA_STATUS] (Signed, Pending, Not Applicable)
- Requesting Team: [REQUESTING_TEAM]
- Business Justification: [BUSINESS_JUSTIFICATION]
- Proposed Enablement Date: [PROPOSED_DATE]

CONSTRAINTS:
- Flag any missing DPA when data classification is Confidential or Restricted.
- Flag any over-scoped permissions relative to the stated business justification.
- Flag any missing data residency specification when data classification is Restricted.
- Do not approve or deny. Only produce the structured request.

OUTPUT_SCHEMA:
{
  "approval_request_id": "string",
  "vendor": {
    "name": "string",
    "website": "string",
    "integration_type": "string"
  },
  "requested_scopes": ["string"],
  "scope_assessment": {
    "over_scoped": true,
    "over_scoped_rationale": "string or null"
  },
  "data_flow_summary": "string",
  "data_classification": "string",
  "data_residency": {
    "specified": true,
    "details": "string or null",
    "missing_for_restricted": true
  },
  "compliance": {
    "certifications_provided": ["string"],
    "dpa_status": "string",
    "dpa_missing_for_confidential_or_restricted": true
  },
  "business_context": {
    "requesting_team": "string",
    "justification": "string",
    "proposed_date": "string"
  },
  "risk_flags": [
    {
      "flag": "string",
      "severity": "high or medium or low",
      "detail": "string"
    }
  ],
  "reviewer_questions": ["string"],
  "generated_at": "ISO8601 timestamp"
}

Generate the approval request.

To adapt this template, replace each bracketed placeholder with data from your integration request intake form or API payload. The OUTPUT_SCHEMA is designed to be machine-readable: parse the JSON response and render the risk_flags and reviewer_questions prominently in your review UI. If your organization uses a specific risk taxonomy, add a [RISK_TAXONOMY] placeholder and map the severity field to your internal levels. For high-risk integrations where data classification is Restricted, route the output to a multi-stakeholder approval queue before any enablement action is taken. Always log the full generated payload as an audit record before a human reviewer modifies or approves it.

This prompt is designed to sit behind a human-in-the-loop approval gate, not as a standalone chatbot. The application layer should collect the required inputs—vendor identity, requested OAuth scopes, data flow description, compliance certifications, and data residency requirements—from the integration request form or API gateway metadata. These inputs are then injected into the prompt's placeholders. The model's job is to structure the evidence, flag missing critical information (like a DPA reference or over-scoped permissions), and produce a standardized approval request payload. The application should never execute the integration enablement until the returned payload has been reviewed and explicitly approved by an authorized human.

Wire the prompt into a secure internal service that has access to your vendor management database and API gateway configuration. Before calling the LLM, the service should fetch the vendor's existing records, current OAuth scope definitions, and data classification tags to populate the [CONTEXT] block. After receiving the model's output, validate the JSON structure against a strict schema that requires fields like vendor_identity, requested_scopes, data_flow_summary, compliance_certifications, data_residency_impact, and missing_items. If the output fails schema validation, retry once with a repair prompt that includes the validation errors. Log every approval request, the model's raw output, the validation result, and the final human decision (approved, denied, or sent back for clarification) to an append-only audit table. For high-risk integrations involving PII or financial data, require approval from both a security lead and a procurement owner before the integration is enabled.

Model choice matters here. Use a model with strong structured output capabilities and low hallucination rates on compliance language. Set temperature to 0 or near-zero to maximize factual consistency. Do not allow the model to make assertions about certifications or data residency that are not present in the provided context. If the prompt flags missing_items, the application should block the approval workflow and return the request to the submitter with the specific gaps highlighted. Never let the system auto-approve an integration, even if the model's output looks complete. The prompt is a preparation and risk-surfacing tool, not a decision engine.