Security audit

Percept Meetings

Security checks for vulnerabilities and agentic risk

Overview

The skill is purpose-aligned for meeting search, but it handles highly sensitive meeting data with broad activation, weak privacy guidance, and unsafe setup patterns.

Review before installing. Only use this skill for meetings and accounts you are authorized to access, run Percept in an isolated environment, pin and verify the dependency, restrict database access, obtain participant consent for recording or ambient capture, scope searches/imports narrowly, and avoid URL query-string webhook tokens where possible.

A.I.G

Vulnerability Patterns

Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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

Findings (2)

T08 · Insecure Dependencies

Error

Location: SKILL.md:17
Finding: Unpinned Third-Party Package and Repository Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 17-18 **Vulnerability Type**: Unverified and mutable third-party dependency installation **Risk Level**: High ### Vulnerable Code ```bash pip install getpercept # or: git clone https://github.com/GetPercept/percept cd percept && pip install -e . ``` ### Technical Analysis The installation instructions execute third-party code without pinning an audited package version or repository commit. They also provide no package hash verification, signature validation, lockfile, or release provenance check. Both installation methods resolve mutable upstream content: - `pip install getpercept` installs whichever package release the package index currently selects. - `git clone https://github.com/GetPercept/percept` retrieves the repository's current default branch. - `pip install -e .` can execute packaging and build logic obtained from that mutable repository. Python package installation may run attacker-controlled build backends or installation logic. Consequently, a compromise of the package index account, source repository, maintainer credentials, build pipeline, or dependency resolution process could turn these documented commands into arbitrary code execution. No malicious upstream package behavior is established by the reviewed files; the vulnerability is the lack of dependency pinning and integrity controls. ### Attack Path 1. An attacker compromises the `getpercept` package publisher, source repository, maintainer account, or upstream release process. 2. The attacker publishes a malicious package release or modifies the repository's default branch. 3. A user follows the Quick Start instructions and runs one of the unpinned installation methods. 4. `pip` retrieves and processes the attacker-controlled package or build configuration. 5. Malicious installation logic executes with the privileges of the user performing the installation. 6. The payload may access meeting transcripts, the ...[truncated 841 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `getpercept` to a specific, reviewed version rather than installing the latest available release. 2. Use a lockfile or requirements file containing cryptographic hashes, and install with hash enforcement such as `pip install --require-hashes`. 3. If installing from Git, pin an audited full commit hash instead of cloning and installing the mutable default branch. 4. Verify release signatures, attestations, or trusted publisher provenance where supported. 5. Review the package's build configuration and transitive dependencies before approving upgrades. 6. Install the dependency in an isolated virtual environment or container with minimal filesystem and credential access. 7. Define a controlled update process that reviews and tests each new dependency version before deployment. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: SKILL.md:34
Finding: Webhook Authentication Secret Exposed in URL Query Parameter<![CDATA[ ## Vulnerability Details **File Locations**: `SKILL.md`, line 34; `references/omi-setup.md`, lines 14-18 **Vulnerability Type**: Sensitive authentication token placed in a URL query string **Risk Level**: Medium ### Vulnerable Code From `SKILL.md`: ```bash percept serve --port 8900 # Configure Omi webhook → https://your-host:8900/webhook/transcript?token=YOUR_TOKEN ``` From `references/omi-setup.md`: ```markdown 4. **Configure webhook** in Omi app: - Settings → Developer → Webhook URL - URL: `https://your-host/webhook/transcript?token=YOUR_TOKEN` - Set `PERCEPT_WEBHOOK_SECRET` to match your token ``` ### Technical Analysis The documentation instructs users to place the webhook authentication secret in the request URL. Query strings are commonly captured by infrastructure that processes requests, including: - Reverse-proxy and web-server access logs. - Load balancer, CDN, and API gateway logs. - Monitoring, observability, and tracing systems. - Client-side history and diagnostic records. - Support bundles and copied URLs. TLS protects a URL while it is in transit, but it does not prevent endpoints and intermediary infrastructure from recording the query string after termination. Anyone with access to such records may recover the reusable webhook token. This instruction also conflicts with the security statement in `references/omi-setup.md`, line 31, which says that a bearer token is required. A bearer token should conventionally be sent through the `Authorization` header rather than embedded in a URL. ### Attack Path 1. A user configures the Omi webhook using the documented URL containing `?token=YOUR_TOKEN`. 2. Omi sends transcript requests to that URL. 3. A reverse proxy, application server, monitoring platform, or other infrastructure component records the full request URL. 4. An attacker or unauthorized operator with access to those logs obtains the webhook token. 5. The attacker sends crafted requests to the transcript webhook ...[truncated 1057 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the token from the webhook URL and transmit it exclusively through an `Authorization: Bearer <token>` header. 2. If the Omi client cannot set authorization headers, use a signed-request mechanism with a timestamp, nonce, and HMAC rather than a reusable URL token. 3. Configure web servers, proxies, gateways, monitoring tools, and tracing systems to redact authentication material. 4. Rotate any webhook tokens that may already have appeared in URLs or logs. 5. Use separate, high-entropy secrets for each deployment and environment. 6. Enforce token expiration or periodic rotation where supported. 7. Add replay protection, request-size limits, rate limiting, and strict transcript payload validation. 8. Update all documentation so that the stated bearer-token requirement matches the actual setup procedure. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Missing User Warnings

High

Confidence: 95% confidence
Finding: The skill documentation explains how to ingest data from Zoom, Granola local caches, and Omi webhooks, but does not clearly warn users that it accesses potentially sensitive transcripts, speaker identities, local meeting caches, and action items. In this context, the omission is risky because users may enable the skill without understanding the privacy implications, retention in SQLite, or the possibility of exposing confidential business discussions through agent workflows.

Vague Triggers

Medium

Confidence: 96% confidence
Finding: The skill metadata advertises very broad trigger phrases such as generic references to meetings, follow-ups, scheduling based on discussions, and 'what did [person] say,' which can cause the skill to activate in many ordinary conversations. Because this skill imports and searches highly sensitive meeting transcripts, over-broad routing increases the chance that private transcript data is accessed or surfaced when the user did not explicitly intend to invoke this capability.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The documentation promotes ambient audio capture, possible cloud transcription, webhook transmission, and storage/searchability of meeting content without warning about consent, legal compliance, retention, or sensitive-data exposure. In a meeting-context skill, this is especially risky because captured content may include confidential business discussions, personal data, or regulated information, and users may infer the setup is safe to deploy broadly as written.