Security audit

Google Calendar

Security checks for vulnerabilities and agentic risk

Overview

This skill is a disclosed Google Calendar integration through Maton, with meaningful cautions around credentials, writes, and automation.

Before installing, treat Maton like any other calendar-connected client: verify you trust the package source, prefer OAuth over long-lived API keys, grant only the Google Calendar scopes needed, confirm every write or automation, and review/delete any hosted functions, triggers, or destinations when finished.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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

Findings (2)

T08 · Insecure Dependencies

Warning

Location: SKILL.md:34
Finding: Third-Party Executables Installed Without Artifact Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:34-41`, `SKILL.md:1153`, and `SKILL.md:1170` **Vulnerability Type**: Supply-chain exposure from unverified third-party packages **Risk Level**: Medium ### Vulnerable Code ```bash npm install -g @maton/cli@0.3.1 ``` ```bash brew install maton-ai/cli/maton brew pin maton ``` ```bash pip install 'maton-ai==0.3.1' ``` ```bash npm install @maton/sdk@0.3.1 ``` ### Technical Analysis The Skill directs users to install the Maton CLI and SDK from NPM, PyPI, and a third-party Homebrew tap. Although package versions are pinned, no cryptographic checksum, signature, lockfile, or independently verifiable artifact identity is provided. Version pinning limits unexpected upgrades but does not protect against: - Compromise of a package publisher account. - Replacement of an artifact associated with a published version. - Compromise of the package registry or Homebrew tap. - Malicious installation lifecycle scripts. - A discrepancy between the reviewed source and the distributed package. The global NPM installation is especially sensitive because package-controlled installation logic executes with the privileges of the user running the command. The installed CLI is subsequently trusted with OAuth authentication, operating-system credential-store access, Google Calendar data, and Maton API operations. No evidence was found that the named packages are currently malicious. The vulnerability is the absence of artifact verification before executing security-sensitive third-party software. ### Attack Path 1. An attacker compromises the package publisher, package registry, release pipeline, or Homebrew tap. 2. The attacker distributes a malicious artifact under the documented package name and version or modifies the installation metadata. 3. A user follows the Skill instructions and installs the package. 4. Package installation or later CLI execution runs attacker-controlled code with the user's local privilege ...[truncated 1023 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Publish cryptographic SHA-256 checksums and signed release manifests for every reviewed CLI and SDK artifact. 2. Verify downloaded artifacts or package signatures before installation. 3. Link the reviewed source revision to the exact distributed package version and document reproducible-build procedures. 4. Prefer a local, isolated installation over a global NPM installation where global access is unnecessary. 5. For Python deployments, provide a requirements file with hash pinning and require `pip install --require-hashes`. 6. For JavaScript deployments, provide and verify a lockfile and disable lifecycle scripts where they are unnecessary. 7. Document whether each package uses installation scripts and why those scripts are required. 8. Pin the Homebrew formula to a verified commit or bottle checksum rather than relying only on `brew pin`, which prevents upgrades but does not independently authenticate the initial artifact. 9. Recommend installation in a sandbox or minimally privileged environment before the package is entrusted with production credentials. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: SKILL.md:181
Finding: Hosted Functions Receive Account-Wide Maton Authority Instead of Connection-Scoped Credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:181-205` and `SKILL.md:531-535` **Vulnerability Type**: Excessive runtime privilege and insufficient capability isolation **Risk Level**: Medium ### Vulnerable Code ```markdown > **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. Do not route trigger events into a function > unless the user asked for hosted automation in those terms. > > **Before any deploy or invocation, give the user a least-privilege summary and get approval on it:** > the hand ...[truncated 3671 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace account-wide runtime credentials with short-lived, per-function capability tokens. 2. Require every deployment to declare an explicit allowlist of connection IDs accessible to the function. 3. Allow operation-level restrictions, such as read-only Google Calendar event listing, instead of granting general API access. 4. Enforce the declared application, connection, endpoint, HTTP method, and provider scope on the server side. 5. Deny access to undeclared connections even when the deploying account owns them. 6. Display the effective capability manifest during creation, update, deployment, and trigger attachment, and require explicit approval when it changes. 7. Preserve `DENY_ALL` as the default network policy and prevent trigger deployment if the function's actual policy differs from the approved policy. 8. Use short credential lifetimes and bind credentials to the function ID, immutable code version, deployment identity, and trigger where applicable. 9. Record and expose per-connection audit logs so unexpected cross-application access can be detected. 10. Until technical scoping is implemented, require a dedicated Maton account containing only the exact connection needed by each hosted function; this should be treated as a temporary mitigation rather than a complete fix. ]]>

SkillSpector

Vulnerability Patterns

Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.