Vercel AI Gateway

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 10:55 AM UTC
• Version: 1.2.4

Overview

This skill is a coherent Vercel AI Gateway integration that clearly discloses authentication, costs, data flow, and optional automation risks.

Install only if you are comfortable using Maton as the authenticated gateway to Vercel AI Gateway. Prefer OAuth, avoid raw API keys, confirm any inference that could spend money, and use a dedicated Maton account or minimal connections before deploying functions or triggers.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:33
• Finding: Third-Party CLI Installation Lacks Artifact Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 33–43 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium ### Vulnerable Code ```bash ### NPM npm install -g @maton/cli@0.3.1 ``` ```bash ### Homebrew brew install maton-ai/cli/maton brew pin maton ``` The document also recommends installing the corresponding SDK packages: ```bash pip install 'maton-ai==0.3.1' ``` ```bash npm install @maton/sdk@0.3.1 ``` ### Technical Analysis The dependency versions are pinned, which reduces unintended version drift, but the installation process does not verify package signatures, cryptographic checksums, provenance attestations, or a trusted lockfile. The Homebrew installation additionally relies on a vendor-controlled custom tap, while the npm command installs the CLI globally. Version pinning alone does not guarantee artifact integrity. If a package registry account, release pipeline, package artifact, or Homebrew tap is compromised, an attacker could replace the pinned release with malicious content under the same version or manipulate the formula to retrieve a malicious artifact. Package installation may execute installation or lifecycle scripts. A globally installed CLI subsequently operates with access to the invoking user's environment, filesystem, credential stores, and authenticated Maton session. The Skill therefore relies heavily on the security of external package-distribution infrastructure without independently validating the installed code. ### Attack Path 1. An attacker compromises the npm/PyPI publisher account, release pipeline, package artifact, or the `maton-ai/cli` Homebrew tap. 2. The attacker publishes or substitutes malicious content for the documented package version or modifies the Homebrew formula. 3. A user follows the Skill instructions and runs the installation command. 4. Package installation or lifecycle logic executes under the user's local account. 5. The malicious package accesses fi ...[truncated 1111 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Publish SHA-256 or stronger cryptographic hashes for every supported CLI and SDK artifact. 2. Verify hashes or signatures before installation and document the expected signer identity. 3. Provide signed release provenance, such as Sigstore attestations or equivalent supply-chain metadata. 4. Prefer official, independently verifiable package sources and clearly document package ownership. 5. Avoid global npm installation where feasible; use a project-local, locked dependency or a verified standalone binary. 6. Disable package lifecycle scripts during installation when they are not required, for example by using npm's script-control options after confirming compatibility. 7. Use lockfiles with integrity metadata for SDK dependencies. 8. Pin Homebrew formula revisions or bottles by verified digest rather than relying only on `brew pin`, which prevents upgrades but does not authenticate the initially installed artifact. 9. Run the CLI in a constrained environment with access only to files and credentials needed for the current task. 10. Document an incident-response procedure for revoking Maton sessions and connected-provider credentials if package integrity is questioned. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:186
• Finding: Hosted Functions Receive an Account-Wide Maton Execution Identity<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 186–211 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Code ```text Execution identity. A function runs as the Maton account that deployed it — the same identity as the `maton` CLI session that performed the deploy, no more and no less. It receives that identity as a runtime-injected `MATON_API_KEY`: the key is placed in the sandbox's environment only while the function runs, is never stored in the package or the code, is never set through `function env`, and only the authenticated account owner can create, deploy, or update a function. Functions are `PRIVATE` unless the user chooses otherwise. Outbound network access is a platform-enforced setting, not a handler decision: with `--network-policy DENY_ALL` the sandbox cannot open any outbound connection regardless of what the code does, and that is the policy every example here uses. Opening the network is the exception, made per function, only when the user has named the hosts the code must reach and approved it. Invoking a function is an authenticated call: the URL alone grants nothing, and a request without a Maton `Authorization` header is rejected with `401` before the handler runs — which is why `maton api` is the documented way to call one. Functions are not part of the default workflow. A routine task — read a mailbox, update a record, run a query — is a `maton api` call and nothing more. Reach for a function only when the user asks for hosted code by name, and treat `create`, `update`, `deploy`, and each invocation as separate actions that each need the user's approval. Before any deploy or invocation, give the user a least-privilege summary and get approval on it: the handler, the connections the deploying account holds (`maton connection list`), which is exactly what the function will be able to reach, and the network policy. Prefer an account whose connection ...[truncated 3532 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace the account-wide runtime key with a short-lived, per-function capability token. 2. Bind each function token to an explicit allowlist of: - Connection IDs. - Application names. - Endpoint paths. - HTTP methods. - Invocation sources. 3. Use read-only scopes for catalog, pricing, credit, and usage operations. 4. Require separate narrowly scoped authorization for inference operations because they incur cost and transmit prompt data. 5. Prevent a function token from listing or discovering connections outside its declared allowlist. 6. Enforce token expiration and automatic revocation when the function or associated trigger is deleted. 7. Log every connection, endpoint, and method accessed by a function, and make those logs visible to the account owner. 8. Add deployment-time policy validation that rejects handlers requesting undeclared connections or operations. 9. Until technical scoping is available, require a dedicated Maton account containing only the Vercel AI Gateway connection needed by the function. 10. Continue using `--network-policy DENY_ALL`, private function visibility, explicit deployment approval, and prompt deletion of temporary functions, but treat these as defense-in-depth rather than substitutes for scoped credentials. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.