other
Warning
- Location
- SKILL.md:262
- Finding
- Raw Payload Disclosure Contradicts the Declared Privacy Model## Vulnerability Details **File Location**: `SKILL.md`, lines 14–15 and 262–297 **Vulnerability Type**: Undisclosed Raw Data Disclosure **Risk Level**: Medium ### Vulnerable Code The Skill makes the following global privacy claim: ```text Raw task data never leaves the client — only `0x`+SHA-256 commitments are sent. ``` However, its hosted chat-bridge workflow instructs the agent to transmit raw payloads: ```text 1. POST {APP_BASE_URL}/api/v1/attestations 2. Human opens approve_url in Chrome (passkey) 3. Poll GET {APP_BASE_URL}/api/v1/attestations/{id} or GET {APP_BASE_URL}/api/v1/attestations/{id}/wait 4. status=completed → certificate_url (hosted on trust.sanctifai.com) ``` ```json { "task_type": "GEN", "domain": "GEN", "task_subtype": "Chat approval", "requesting_agent": "Support bot", "taskData": { "summary": "opaque task payload" }, "resultData": { "decision": "approved" } } ``` The instructions later confirm that the raw objects are posted: ```text Retain the exact `taskData` / `resultData` you posted (see Shared rules). The bridge approve client uses the same `sha256Hex` helper as Embedded. ``` ### Technical Analysis The global description states that only SHA-256 commitments leave the client. In contrast, the chat-bridge flow directs the agent to send raw `taskData` and `resultData` to the externally hosted `https://bridge.trust.sanctifai.com` service. Describing a payload as “opaque” does not technically enforce anonymization, data minimization, or secret removal. Although the Skill separately warns users not to include personally identifiable information, an agent may still place confidential business information, transaction details, review content, or sensitive decisions into these objects. This behavior exceeds the minimum data disclosure demonstrated as necessary by the embedded workflow, which computes commitments locally and sends only `task_commitment` and `result_commitment`. The chat bridge therefore expands third- ...[truncated 1995 chars]
- Remediation
- ## Remediation Suggestions 1. Compute the task and result commitments on the client or agent side before contacting the hosted bridge. 2. Change the bridge API to accept only `task_commitment` and `result_commitment` wherever raw data is not essential. 3. If the hosted bridge genuinely requires raw objects, revise the global privacy claim to explicitly distinguish the embedded, extension, and chat-bridge data flows. 4. Obtain explicit user confirmation before transmitting raw task or result content to the external service. 5. Default to metadata-only payloads and enforce strict field allowlists, size limits, and client-side secret and PII detection. 6. Clearly document what the bridge receives, why it requires the data, how long it retains it, who can access it, and which subprocessors receive it. 7. Provide a self-hosted or commitment-only bridge option for sensitive workflows. 8. Add automated tests or documentation checks that prevent future claims that all surfaces transmit only commitments while any surface still accepts raw payloads.