Back to skill

Security audit

The Agent Interoperability Bridge: Connecting GreenHelix Agents to x402, ACP, A2A, MCP, Visa TAP, Google AP2/UCP, PayPal Agent Ready, and OpenAI ACP Ecosystems

Security checks for vulnerabilities and agentic risk

Overview

This non-executing guide is coherent, but its production-labeled payment and webhook examples could lead to insecure financial integrations if followed as-is.

Treat this as reference material only. Do not deploy the examples directly for real payments or public endpoints without adding strong request authentication, provider webhook signature verification, replay protection, authorization checks, explicit user payment approval, scoped credentials, webhook destination allowlisting, private-network egress blocking, and event-data minimization.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:543
Finding
Unauthenticated ACP Webhook Permits Forged Payment and Fulfillment Operations<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 543-575 **Vulnerability Type**: Unauthenticated webhook and missing payment-event verification **Risk Level**: High ### Vulnerable Code ```python # Webhook handler for incoming ACP purchase events @app.route("/webhooks/acp", methods=["POST"]) def acp_webhook(): event = request.json event_type = event.get("type") if event_type == "checkout.initiated": result = acp_bridge.handle_acp_purchase(event.get("intent")) return jsonify(result) elif event_type == "payment.completed": # Stripe has confirmed payment -- now fulfill via GreenHelix intent_id = event["intent"]["id"] payment_id = event["intent"]["greenhelix_payment_id"] # Execute your GreenHelix-backed service service_result = client.execute("search_services", { "service_id": event["intent"]["metadata"]["greenhelix_service_id"], }) fulfillment = acp_bridge.handle_acp_fulfillment( acp_intent_id=intent_id, greenhelix_payment_id=payment_id, result=service_result, ) return jsonify(fulfillment) return jsonify({"status": "ignored"}), 200 ``` The downstream purchase operation creates GreenHelix payment state from fields supplied by the webhook: ```python payment_intent = self.client.execute("create_payment_intent", { "payer_agent_id": buyer_agent_id, "payee_agent_id": self.agent_id, "amount": amount_usd, "description": ( f"ACP checkout for service {greenhelix_service_id}. " f"ACP intent: {acp_intent.get('id', 'unknown')}" ), "metadata": json.dumps({ "protocol": "acp", "acp_intent_id": acp_intent.get("id"), "stripe_payment_intent": acp_intent.get("stripe_pi_id"), }), }) ``` ### Technical Analysis The webhook handler parses and trusts the request body without authenticating its origin. It does not verify a Stripe or ACP w ...[truncated 2621 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Verify the webhook signature against the raw HTTP request body before JSON parsing. Use the official provider SDK and `stripe_webhook_secret`; do not implement ad hoc signature comparison. 2. Enforce a strict timestamp tolerance to prevent replay of old signed messages. 3. Persist processed provider event IDs and reject duplicates atomically. 4. Retrieve the referenced payment intent from Stripe or ACP and require an authoritative successful or settled state before fulfillment. 5. Confirm that the verified merchant, currency, amount, service ID, and payment-intent ownership match locally stored order data. 6. Never trust `greenhelix_payment_id`, payer identity, amount, or service identifiers supplied solely in the webhook body. 7. Apply strict JSON schema validation and safely reject absent or malformed fields. 8. Separate checkout creation from fulfillment and use a server-generated correlation identifier. 9. Restrict the GreenHelix credential used by the webhook service to only the tools and agent records required for this integration. 10. Add rate limiting, request-size limits, structured security logging, and alerts for failed signatures and repeated event IDs. 11. Return an authentication failure before performing any API or service operation when validation fails. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:2400
Finding
Unrestricted Webhook Destinations Enable SSRF and Sensitive Event Exfiltration<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 2400-2649 **Vulnerability Type**: Server-Side Request Forgery and sensitive event disclosure **Risk Level**: High ### Vulnerable Code Webhook registration accepts and persists an arbitrary URL without validating its scheme, hostname, resolved IP address, or registrant authorization: ```python def register_external_webhook(self, protocol: str, url: str, events: list) -> dict: """Register a webhook for forwarding events to an external protocol. Events matching the specified types will be translated and forwarded to this URL. """ if protocol not in self._webhook_registry: self._webhook_registry[protocol] = [] registration = { "url": url, "events": events, "protocol": protocol, "registered_at": time.time(), } self._webhook_registry[protocol].append(registration) # Also register in GreenHelix for persistence self.client.execute("register_webhook", { "agent_id": self.agent_id, "url": url, "events": json.dumps(events), }) return { "status": "registered", "protocol": protocol, "url": url, "events": events, } ``` The stored URL is subsequently used as the destination of a server-side request: ```python def forward_event(self, source_protocol: str, event: dict, target_protocols: list = None) -> list: """Translate and forward an event to all registered webhooks. If target_protocols is specified, only forwards to those protocols. Otherwise, forwards to all protocols with registered webhooks. """ results = [] protocols_to_notify = target_protocols or list(self._webhook_registry.keys()) for protocol in protocols_to_notify: webhooks = self._webhook_registry.get(protocol, []) translated = self.translate_event(source_protocol, event, protocol) for we ...[truncated 4580 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Limit webhook registration to authenticated administrators or explicitly authorized tenant principals. 2. Enforce an allowlist of approved partner domains and exact HTTPS destination patterns. 3. Permit only `https` URLs on standard approved ports; reject embedded credentials, malformed hosts, fragments, and unexpected schemes. 4. Resolve the hostname before every delivery and reject loopback, private, link-local, multicast, unspecified, carrier-grade NAT, and reserved IPv4 and IPv6 ranges. 5. Protect against DNS rebinding by connecting only to the validated resolved address while preserving correct TLS hostname verification. 6. Disable redirects. If redirects are required, independently validate every redirect destination before following it. 7. Apply egress firewall rules so the bridge process cannot reach metadata services, management interfaces, or unrelated internal networks. 8. Remove wildcard subscriptions for sensitive event classes and require explicit least-privilege event selections. 9. Redact or tokenize authorization codes, payer IDs, task contents, transaction IDs, and other sensitive fields unless a destination has a demonstrated need to receive them. 10. Require destination ownership verification, such as a challenge-response handshake, before activating a webhook. 11. Sign outbound webhook payloads with a per-destination secret and rotate those secrets regularly. 12. Add registration approval, expiration, revocation, delivery audit logs, rate limits, and alerts for unusual destinations or subscription breadth. 13. Store webhook configurations by tenant and enforce tenant isolation during registration and forwarding. 14. Avoid returning detailed network exceptions to untrusted callers, because they can improve internal service enumeration. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (17)

External Transmission

Medium
Category
Data Exfiltration
Content
The 2026 agent protocol landscape has expanded from four major protocols to nine or more. The original four -- x402, ACP, A2A, and MCP -- have matured significantly into their v2 generations. x402 v2 is now backed by the x402 Foundation (Coinbase, Cloudflare, Stripe, AWS, and Microsoft) and has processed over 100 million payments. A2A v2 adds streaming-first task execution and enhanced Agent Card schemas. MCP 1.5+ introduces Streamable HTTP transport, resource subscriptions, and structured tool annotations. Meanwhile, five new heavyweight entrants have arrived: Visa's Transaction Authorization Protocol (TAP), Google's Agent Payments Protocol v2 (AP2) and Universal Commerce Protocol (UCP), PayPal's Agent Ready platform, and OpenAI's Agentic Commerce Protocol (OpenAI ACP). Each brings a different philosophy, a different merchant base, and a different set of integration requirements.

Every bridge class in this guide runs against the GreenHelix API at `https://api.greenhelix.net/v1`. Every code example is production-ready. By the end, your GreenHelix agents will accept x402 v2 micropayments, process ACP checkout flows, respond to A2A v2 task requests, expose services as MCP 1.5+ tools, authorize payments through Visa TAP, process Google AP2 payments and UCP task orchestration, integrate with PayPal's Agent Ready merchant network, and accept OpenAI ACP commerce flows -- without abandoning the escrow, identity, and trust infrastructure you have already built.

---
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
The 2026 agent protocol landscape has expanded from four major protocols to nine or more. The original four -- x402, ACP, A2A, and MCP -- have matured significantly into their v2 generations. x402 v2 is now backed by the x402 Foundation (Coinbase, Cloudflare, Stripe, AWS, and Microsoft) and has processed over 100 million payments. A2A v2 adds streaming-first task execution and enhanced Agent Card schemas. MCP 1.5+ introduces Streamable HTTP transport, resource subscriptions, and structured tool annotations. Meanwhile, five new heavyweight entrants have arrived: Visa's Transaction Authorization Protocol (TAP), Google's Agent Payments Protocol v2 (AP2) and Universal Commerce Protocol (UCP), PayPal's Agent Ready platform, and OpenAI's Agentic Commerce Protocol (OpenAI ACP). Each brings a different philosophy, a different merchant base, and a different set of integration requirements.

Every bridge class in this guide runs against the GreenHelix API at `https://api.greenhelix.net/v1`. Every code example is production-ready. By the end, your GreenHelix agents will accept x402 v2 micropayments, process ACP checkout flows, respond to A2A v2 task requests, expose services as MCP 1.5+ tools, authorize payments through Visa TAP, process Google AP2 payments and UCP task orchestration, integrate with PayPal's Agent Ready merchant network, and accept OpenAI ACP commerce flows -- without abandoning the escrow, identity, and trust infrastructure you have already built.

---
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
The 2026 agent protocol landscape has expanded from four major protocols to nine or more. The original four -- x402, ACP, A2A, and MCP -- have matured significantly into their v2 generations. x402 v2 is now backed by the x402 Foundation (Coinbase, Cloudflare, Stripe, AWS, and Microsoft) and has processed over 100 million payments. A2A v2 adds streaming-first task execution and enhanced Agent Card schemas. MCP 1.5+ introduces Streamable HTTP transport, resource subscriptions, and structured tool annotations. Meanwhile, five new heavyweight entrants have arrived: Visa's Transaction Authorization Protocol (TAP), Google's Agent Payments Protocol v2 (AP2) and Universal Commerce Protocol (UCP), PayPal's Agent Ready platform, and OpenAI's Agentic Commerce Protocol (OpenAI ACP). Each brings a different philosophy, a different merchant base, and a different set of integration requirements.

Every bridge class in this guide runs against the GreenHelix API at `https://api.greenhelix.net/v1`. Every code example is production-ready. By the end, your GreenHelix agents will accept x402 v2 micropayments, process ACP checkout flows, respond to A2A v2 task requests, expose services as MCP 1.5+ tools, authorize payments through Visa TAP, process Google AP2 payments and UCP task orchestration, integrate with PayPal's Agent Ready merchant network, and accept OpenAI ACP commerce flows -- without abandoning the escrow, identity, and trust infrastructure you have already built.

---
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
The 2026 agent protocol landscape has expanded from four major protocols to nine or more. The original four -- x402, ACP, A2A, and MCP -- have matured significantly into their v2 generations. x402 v2 is now backed by the x402 Foundation (Coinbase, Cloudflare, Stripe, AWS, and Microsoft) and has processed over 100 million payments. A2A v2 adds streaming-first task execution and enhanced Agent Card schemas. MCP 1.5+ introduces Streamable HTTP transport, resource subscriptions, and structured tool annotations. Meanwhile, five new heavyweight entrants have arrived: Visa's Transaction Authorization Protocol (TAP), Google's Agent Payments Protocol v2 (AP2) and Universal Commerce Protocol (UCP), PayPal's Agent Ready platform, and OpenAI's Agentic Commerce Protocol (OpenAI ACP). Each brings a different philosophy, a different merchant base, and a different set of integration requirements.

Every bridge class in this guide runs against the GreenHelix API at `https://api.greenhelix.net/v1`. Every code example is production-ready. By the end, your GreenHelix agents will accept x402 v2 micropayments, process ACP checkout flows, respond to A2A v2 task requests, expose services as MCP 1.5+ tools, authorize payments through Visa TAP, process Google AP2 payments and UCP task orchestration, integrate with PayPal's Agent Ready merchant network, and accept OpenAI ACP commerce flows -- without abandoning the escrow, identity, and trust infrastructure you have already built.

---
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
The 2026 agent protocol landscape has expanded from four major protocols to nine or more. The original four -- x402, ACP, A2A, and MCP -- have matured significantly into their v2 generations. x402 v2 is now backed by the x402 Foundation (Coinbase, Cloudflare, Stripe, AWS, and Microsoft) and has processed over 100 million payments. A2A v2 adds streaming-first task execution and enhanced Agent Card schemas. MCP 1.5+ introduces Streamable HTTP transport, resource subscriptions, and structured tool annotations. Meanwhile, five new heavyweight entrants have arrived: Visa's Transaction Authorization Protocol (TAP), Google's Agent Payments Protocol v2 (AP2) and Universal Commerce Protocol (UCP), PayPal's Agent Ready platform, and OpenAI's Agentic Commerce Protocol (OpenAI ACP). Each brings a different philosophy, a different merchant base, and a different set of integration requirements.

Every bridge class in this guide runs against the GreenHelix API at `https://api.greenhelix.net/v1`. Every code example is production-ready. By the end, your GreenHelix agents will accept x402 v2 micropayments, process ACP checkout flows, respond to A2A v2 task requests, expose services as MCP 1.5+ tools, authorize payments through Visa TAP, process Google AP2 payments and UCP task orchestration, integrate with PayPal's Agent Ready merchant network, and accept OpenAI ACP commerce flows -- without abandoning the escrow, identity, and trust infrastructure you have already built.

---
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
raise ValueError("Payment proof missing required fields")

        # Verify with the facilitator that the payment settled
        verify_resp = requests.post(
            f"{self.facilitator_url}/verify",
            json={
                "tx_hash": tx_hash,
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The guide states that simpler MCP clients may ignore the payment field and that payment can settle 'in the background,' which normalizes charging behavior without explicit user confirmation. In an agent-tool ecosystem, this can lead to unintended or opaque charges, especially when callers do not understand that tool use may incur real payment obligations.

External Transmission

Medium
Category
Data Exfiltration
Content
}

        # Submit to acquiring bank
        auth_response = requests.post(
            f"{self.acquiring_bank_endpoint}/authorize",
            json=auth_request,
            cert=self.tap_certificate_path,
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
Checks token format, expiry, and whether the token is on the
        network's revocation list.
        """
        validation_resp = requests.post(
            f"{self.acquiring_bank_endpoint}/validate-token",
            json={"token": tap_token},
            cert=self.tap_certificate_path,
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
},
        }

        bt_response = requests.post(
            self._bt_base_url,
            json={"query": mutation, "variables": variables},
            auth=(self.braintree_api_key, self.braintree_api_secret),
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
},
        }

        bt_response = requests.post(
            self._bt_base_url,
            json={"query": mutation, "variables": variables},
            auth=(self.braintree_api_key, self.braintree_api_secret),
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
def __init__(self, client: GreenHelixClient, agent_id: str,
                 openai_acp_api_key: str,
                 openai_acp_base_url: str = "https://api.openai.com/v1/acp"):
        self.client = client
        self.agent_id = agent_id
        self.openai_acp_api_key = openai_acp_api_key
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
continue

                try:
                    resp = requests.post(
                        webhook["url"],
                        json=translated,
                        timeout=10,
Confidence
78% confidence
Finding
The EventBridge forwards translated events to arbitrary registered webhook URLs using requests.post, creating server-side outbound requests based on stored URL input. Without strict allowlisting and validation, this can enable SSRF, internal network access, or sensitive event exfiltration to attacker-controlled endpoints.

Intent-Code Divergence

Medium
Confidence
96% confidence
Finding
The ACP webhook example processes incoming events directly from request JSON without verifying the Stripe webhook signature, even though the guide later says signature verification is required. An attacker could forge checkout or payment-completed events and trigger fulfillment logic or internal state changes without a legitimate Stripe-confirmed payment.

Intent-Code Divergence

Medium
Confidence
91% confidence
Finding
The A2A task endpoint example accepts unauthenticated POST requests and immediately translates them into service and payment-intent actions, despite the guide stating that push/webhook notifications should be authenticated. This allows unauthorized callers to submit fake tasks, consume resources, and potentially create bogus payment or event records.

Intent-Code Divergence

Medium
Confidence
96% confidence
Finding
The MCP endpoint executes tools based only on a JSON-RPC request plus an optional X-AGENT-ID header, while the guide claims paid tools should use OAuth 2.1 and balance checks. An attacker can spoof caller identity, invoke paid or state-changing tools, and cause unauthorized actions or charges because there is no real authentication, authorization, or payment enforcement in the example.

Intent-Code Divergence

Low
Confidence
79% confidence
Finding
L2766 instructs implementers to validate Braintree webhook signatures before processing settlement events. The surrounding PayPal bridge examples include payment processing and token validation logic but omit any signature-validation step for incoming webhooks, creating a contradiction between the guide's security instructions and its implementation examples.

Static analysis

No suspicious patterns detected.