Third-Party Integration Action Summary Prompt

This prompt is designed for platform engineering and security teams who are building AI agents that connect to external vendor APIs. The core job-to-be-done is to generate a human-readable, structured checkpoint immediately before an integration action executes. This checkpoint must capture the specific data being exchanged, the OAuth scopes or permissions being granted, the vendor's security posture, and the potential blast radius of the action. The ideal user is a developer or an automated agent harness that needs to present a clear, auditable summary to a human reviewer or a compliance gate before allowing an API call that could expose data or modify external systems.

Use this prompt when the integration action is irreversible, involves sensitive data (PII, PHI, financial records), or grants new permissions to a third party. It is appropriate for pre-flight checks on API mutations, initial vendor connection handshakes, and scheduled data syncs that touch external infrastructure. Do not use this prompt for read-only health checks, simple data fetches with no side effects, or internal service-to-service communication where the security boundary is already trusted. The prompt is not a replacement for a full vendor security review; it is an operational gate that summarizes known information to confirm intent and scope before a single technical action.

Before using this prompt, ensure your harness can provide the required inputs: the vendor's name, their risk tier (derived from your internal security assessment), the specific API endpoint and HTTP method, the OAuth scopes requested, and a summary of the data payload. The output should be treated as a blocking confirmation step in a human-in-the-loop workflow for high-risk vendors. For low-risk, pre-approved integrations, you might log the summary without requiring a human to approve it. The next step is to wire this prompt into your agent's tool-calling lifecycle, ensuring that the tool for executing the integration is gated behind a successful confirmation from this summary.

This prompt template is designed to be dropped into an agent's pre-action approval workflow. It forces the model to articulate the exact scope of a third-party integration action, the data being exchanged, the vendor's security posture, and the permissions being granted. The output is a human-readable checkpoint that a reviewer can use to approve or deny the action without needing to reverse-engineer the agent's intent. Use this template when your agent is about to call an external vendor API with side effects—especially when OAuth scopes, PII, or financial data are involved.

codeCopy
You are an integration audit assistant. Your job is to generate a concise, structured summary of a planned third-party integration action before it executes. You do not approve or deny the action; you only produce the summary for human review.

## Input
- Planned Action: [ACTION_DESCRIPTION]
- Vendor Name: [VENDOR_NAME]
- Vendor API Endpoint: [API_ENDPOINT]
- OAuth Scopes Requested: [OAUTH_SCOPES]
- Data Being Sent (fields and sensitivity): [DATA_SENT]
- Data Being Retrieved (fields and sensitivity): [DATA_RETRIEVED]
- Vendor Security Tier (per internal policy): [VENDOR_RISK_TIER]
- Vendor Compliance Certifications: [VENDOR_CERTIFICATIONS]
- Rollback or Undo Plan: [ROLLBACK_PLAN]
- Requesting System: [REQUESTING_SYSTEM]

## Output Schema
Return a JSON object with the following structure:
{
  "summary": "One-sentence summary of the action.",
  "vendor_assessment": {
    "name": "string",
    "risk_tier": "string",
    "certifications": ["string"],
    "data_handling_notes": "string"
  },
  "data_exchange": {
    "data_sent": [{"field": "string", "sensitivity": "low|medium|high|critical"}],
    "data_retrieved": [{"field": "string", "sensitivity": "low|medium|high|critical"}],
    "pii_involved": true|false,
    "phi_involved": true|false
  },
  "permissions": {
    "oauth_scopes": ["string"],
    "effective_access": "string",
    "overprovisioning_flag": true|false,
    "overprovisioning_detail": "string or null"
  },
  "risk_summary": {
    "overall_risk": "low|medium|high|critical",
    "key_concerns": ["string"],
    "rollback_feasibility": "full|partial|none",
    "rollback_notes": "string"
  },
  "review_required": true|false,
  "reviewer_questions": ["string"]
}

## Constraints
- If any data field has sensitivity "critical" or PII/PHI is involved, set review_required to true.
- If the vendor risk tier is "high" or "critical", set review_required to true.
- If overprovisioning_flag is true, include a specific overprovisioning_detail explaining which scopes exceed the minimum necessary.
- If rollback_feasibility is "none", escalate key_concerns to the top of the list.
- Do not invent certifications. Only list those provided in [VENDOR_CERTIFICATIONS].
- If information is missing, note it in reviewer_questions rather than guessing.

Adaptation notes: Replace each square-bracket placeholder with data from your agent's execution context. The [VENDOR_RISK_TIER] should come from your internal vendor risk assessment, not from the model's general knowledge. The [DATA_SENT] and [DATA_RETRIEVED] fields should be populated by your agent's tool-call inspector before this prompt runs. If your organization uses a different sensitivity taxonomy, adjust the enum values in the output schema. The review_required boolean can be wired directly into your approval router—if true, block execution and surface the summary to the designated reviewer queue.

The Third-Party Integration Action Summary Prompt is designed to sit at a critical gate in your integration workflow—after the AI has determined what action to take but before any external API call is executed. The harness must treat this prompt as a blocking checkpoint. The model receives the proposed action, the vendor context, and the data payload, then produces a structured summary for human review. The application layer should never proceed to execute the integration action until the summary has been reviewed and explicitly approved by an authorized human. This is not a logging step; it is a safety interlock.

To implement this harness, start by assembling the prompt variables from your integration pipeline context. The [VENDOR_NAME], [VENDOR_DOCS_URL], and [VENDOR_SECURITY_TIER] fields should come from your vendor registry or API gateway configuration. The [PROPOSED_ACTION] and [DATA_PAYLOAD] fields must be captured from the AI agent's planned tool call before execution. The [OAUTH_SCOPES] field should be extracted from the token or grant being used. Before calling the LLM, validate that all required fields are non-empty and that the vendor security tier is recognized. If the vendor is classified as critical or high-risk, enforce a mandatory multi-stakeholder approval routing—do not allow a single reviewer to approve the action. The harness should also check that the OAuth scopes requested do not exceed the minimum necessary for the action, flagging over-privileged grants in the summary itself.

After the model returns the summary, the harness must validate the output structure before presenting it to a reviewer. Check that the JSON response contains all required fields: action_summary, data_exchanged, vendor_security_posture, oauth_scopes_granted, risk_assessment, and required_approvals. If any field is missing or malformed, retry the prompt once with a repair instruction that includes the validation error. Log the full prompt, response, and validation result to your audit trail, including the model version and timestamp. The summary should then be routed to the appropriate approval queue based on the vendor risk tier. For low-risk vendors, a single reviewer may suffice. For high-risk vendors, require approval from both the integration owner and a security reviewer. The harness must block execution until all required approvals are collected, and it must capture the reviewer identities, timestamps, and any override justifications in the audit log. Never cache or reuse an approval across different actions—each integration action requires its own fresh summary and approval cycle.

For model choice, use a model with strong structured output capabilities and low latency, as this prompt sits on the critical path of user-facing workflows. GPT-4o or Claude 3.5 Sonnet are appropriate for production use. Set temperature=0 to maximize consistency in the risk assessment and approval routing fields. If your integration pipeline includes a retrieval step for vendor documentation, inject the relevant security and compliance excerpts into the [VENDOR_CONTEXT] variable before calling the prompt. Do not rely on the model's parametric knowledge of vendor security postures—always ground this in your own vendor review data. Finally, build an eval suite that tests the harness end-to-end: verify that high-risk vendor actions are blocked until multi-stakeholder approval is complete, that malformed summaries trigger retries, and that the audit trail captures every approval decision with full context. The most common production failure mode is a reviewer approving a summary without reading it—consider adding a mandatory minimum review time or a comprehension check for irreversible actions.