Back to skill

Security audit

Mag3nt Pay

Security checks for vulnerabilities and agentic risk

Overview

This is a real-payment skill whose purpose is coherent, but it needs Review because it can spend funds and handles payment credentials/request data with weak scoping and warnings.

Install only if you are comfortable giving the agent access to Mag3nt payment credentials and potential autonomous spending. Use limited-balance cards, avoid forwarding Authorization/Cookie headers or sensitive request bodies, prefer test credentials where possible, and confirm recipient, amount, and merchant domain before any payment or mandate creation.

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
references/ap2-pay.md:38
Finding

Card Secret Token Transmitted in a URL Query String

Content
View full analysis

Vulnerability Details

File Location: references/ap2-pay.md:38
Vulnerability Type: Secret exposure through a URL query parameter
Risk Level: High

Complete Code Snippet:

http
GET https://mag3nt.com/api/ap2/instruments?card_id=<CARD_ID>&card_token=<CARD_TOKEN>

Technical Analysis

The documented AP2 instrument-listing request places card_token, a secret payment credential, directly in the URL query string. Although HTTPS encrypts the request while it is in transit, URLs are commonly recorded by application access logs, reverse proxies, API gateways, observability platforms, browser history, debugging tools, and error-reporting systems.

This unnecessarily broadens access to the card token beyond the payment authentication component. It also contradicts least-privilege handling of secrets because operational systems that legitimately require URL visibility may gain access to a reusable payment credential.

Attack Path

  1. An agent follows the documented AP2 request and inserts its real card ID and card token into the URL.
  2. The complete request URL passes through Mag3nt infrastructure or another intermediary that records request paths and query strings.
  3. An attacker compromises a logging account, monitoring integration, support export, proxy log, or developer workstation with access to the recorded URL.
  4. The attacker extracts the card_token and corresponding card_id.
  5. The attacker attempts card-authenticated Mag3nt operations, including payment or mandate endpoints that accept these credentials.

Exploitation depends on access to a system that records the URL and on the token remaining valid.

Impact Assessment

Disclosure may expose a reusable card credential capable of authenticating payment-related operations. Depending on server-side authorization, card limits, token scope, and mandate controls, an attacker could inspect card information, create payment m ...[truncated 199 chars]

Remediation
View remediation

Remediation Suggestions

  • Remove card_token from the query string.
  • Use an authenticated HTTPS request with the token in an authorization header, such as a narrowly scoped bearer or card-token header.
  • If the API cannot accept authentication headers, change the endpoint to use an HTTPS POST request with the credential in the request body.
  • Configure application servers, proxies, API gateways, monitoring systems, and tracing platforms to redact card tokens and sensitive query parameters.
  • Apply short token lifetimes, narrow operation scopes, card spending limits, and immediate revocation support.
  • Rotate any token that has already been transmitted in URLs and review historical access logs for unintended retention.
  • Update the documentation to warn users never to place reusable payment credentials in URLs.

T09 · Insecure Skill Coding Practices

Warning
Location
references/x402-pay.md:26
Finding

Unrestricted Forwarding of Original Request Data to the Payment Provider

Content
View full analysis

Vulnerability Details

File Location: references/x402-pay.md:26-30
Vulnerability Type: Excessive disclosure of request headers and body data across a trust boundary
Risk Level: Medium

Complete Code Snippet:

markdown
| `url` | string | yes | The 402-protected URL the agent originally called |
| `method` | string | no | HTTP method the agent used (default: `POST`) |
| `body` | object | no | Request body the agent originally sent |
| `headers` | object | no | Additional headers for the probe request |

Pass the same URL, method, and body that triggered the 402. The engine will probe the URL, extract the payment challenge, settle on-chain, and return evidence.

Technical Analysis

The instructions allow the agent to submit the original URL, method, request body, and additional headers to https://mag3nt.com/api/pay so that Mag3nt can reproduce the request and inspect its payment challenge. Forwarding the target URL and limited payment-related context is consistent with the Skill's declared functionality, but forwarding arbitrary bodies and headers without filtering exceeds the minimum information required in many cases.

Original requests may contain bearer tokens, API keys, cookies, session identifiers, personal information, proprietary prompts, confidential documents, or tenant-specific metadata. Sending these fields to the payment provider creates an additional trust boundary and may also cause Mag3nt's server-side probe to replay sensitive credentials against a target URL.

The documentation does not define a header allowlist, prohibit forwarding authentication material, require field-level redaction, or require user approval before transmitting sensitive request content.

Attack Path

  1. The agent sends an authenticated or confidential request to an API.
  2. The API, or an attacker-controlled endpoint presented as that API, responds with an HTTP 402 payment challenge.
  3. Following the Sk ...[truncated 1510 chars]
Remediation
View remediation

Remediation Suggestions

  • Define an explicit allowlist of fields that may be sent to the payment engine.
  • Never forward Authorization, Proxy-Authorization, Cookie, Set-Cookie, API-key headers, client certificates, CSRF tokens, or unrelated session metadata.
  • Default to sending only the URL, HTTP method, and payment-challenge information required for protocol detection.
  • Require explicit user confirmation before transmitting request bodies containing personal, financial, proprietary, or otherwise sensitive information.
  • Redact secret-bearing URL parameters before submission.
  • Where possible, submit the original 402 challenge itself instead of replaying the complete merchant request.
  • Ensure the provider validates outbound probe destinations, blocks private and link-local address ranges, limits redirects, and prevents DNS-rebinding attacks.
  • Apply short retention periods and field-level redaction to provider-side logs, traces, and error reports.
  • Correct the statement in SKILL.md that credentials “never leave the local environment”; clarify that credentials and selected request data are transmitted to the declared Mag3nt API over HTTPS.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (12)

Lp1

High
Category
MCP Least Privilege
Confidence
98% confidence
Finding

The script makes outbound network requests to the Mag3nt API, but the finding indicates network capability is not declared in permissions. Undeclared network access is dangerous because it enables external communication and potential exfiltration of payment-related metadata or credentials without transparent user consent; in a payment skill, this is especially sensitive because it interacts with financial infrastructure.

Content

No source excerpt is available for this finding.

Lp1

High
Category
MCP Least Privilege
Confidence
98% confidence
Finding

The script makes outbound network requests to the Mag3nt API, but the finding indicates network capability is not declared in permissions. Undeclared network access is dangerous because it enables external communication and potential exfiltration of payment-related metadata or credentials without transparent user consent; in a payment skill, this is especially sensitive because it interacts with financial infrastructure.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The activation guidance includes broad natural-language triggers like requests to "pay for", "buy access to", or "unlock" an API, which can overlap with ordinary user requests and cause this high-impact payment skill to activate too eagerly. In a skill that can initiate autonomous spending with stored payment credentials, overbroad triggering increases the risk of unintended payment flows, accidental wallet use, or social-engineering-induced purchases.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The document explicitly describes an autonomous human-not-present payment flow, including creation and use of open mandates, but does not include a clear warning that these actions can trigger real financial transactions. In a payment skill, this omission is security-relevant because downstream agents may treat the instructions as routine API usage and initiate spending without sufficient user confirmation, policy gating, or operator awareness.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The documentation shows authenticated requests using a bearer API key but provides no guidance on secret handling, storage, redaction, or avoiding exposure in logs and examples. In an agent skill context, this increases the chance that downstream implementations will place the key in prompts, traces, code blocks, or other insecure locations, enabling unauthorized access to balances and card data.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The settlement flow instructs the agent to transmit payer_card_id and payer_card_token to an external payment endpoint and can immediately trigger a charge, but it provides no warning or consent boundary around credential use or payment authorization. In an autonomous agent context, this omission increases the risk of silent charges, misuse of stored payment credentials, or payment to attacker-controlled challenges if upstream 402 responses are not sufficiently validated.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

After payment, the skill directs the agent to retry the original request with the paylink code but does not warn that this may resend the full original payload to a third party. If the original body contains personal, regulated, or proprietary data, the agent may disclose it again after incurring payment, compounding both financial and privacy risk.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
60% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · references/paylink-pay.md (reported line 90)May include surrounding context.

typescript
// 1. Call the screening API
const res = await fetch("https://screening.example.com/api/screen", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "John Doe" }),

External Transmission

Medium
Category
Data Exfiltration
Confidence
60% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · references/paylink-pay.md (reported line 118)May include surrounding context.

typescript
// 1. Call the screening API
const res = await fetch("https://screening.example.com/api/screen", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "John Doe" }),

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The setup instructions ask users to place live payment secrets in environment variables and explicitly show credential formats, but they do not warn that these are sensitive financial credentials that can authorize spending if leaked. In a payment skill, normalizing direct handling of API keys and card tokens without clear secret-management and spend-risk guidance increases the chance of accidental exposure, misuse, or unauthorized transactions.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The documentation tells users to pass the same URL, method, body, and optional headers that triggered the 402, but it does not clearly warn that these values are transmitted to Mag3nt for probing and payment settlement. In this skill context, those fields may contain sensitive request payloads, authorization headers, API keys, PII, or proprietary prompts, so the omission can cause unintentional data disclosure to a third-party service and broaden the trust boundary without informed consent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
84% confidence
Finding

The verification example performs a live call to a production payment service and prints card status, balances, funding network, and accepted protocols, yet it provides no warning that this discloses sensitive financial metadata. While the code is only a connectivity test, in this skill context it encourages live validation against real credentials and may leak account information through terminal history, logs, screenshots, or shared environments.

Content

No source excerpt is available for this finding.

Static analysis

Detected: suspicious.env_credential_access

Environment variable access combined with network send.

Critical
Code
suspicious.env_credential_access
Location
scripts/quickstart.mjs:17