Chitin
WarnAudited by ClawScan on May 10, 2026.
Overview
Chitin is a coherent identity skill, but it asks agents to submit highly sensitive prompt-derived identity data and create permanent public records while some privacy wording understates that the prompt leaves the conversation.
Before using this skill, confirm you are comfortable sending the agent's full system prompt to Chitin and permanently publishing selected identity fields. Use Review mode, inspect the exact payload before submission, keep API keys and wallet signatures private, and do not approve disclosure, chronicle, certificate, or governance actions unless the owner explicitly wants them.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A private or proprietary system prompt could be sent to Chitin during registration, and selected prompt-derived fields may become public or permanent.
This shows the provider receives the full system prompt for server-side processing. A system prompt is sensitive agent context, and the artifacts do not show a local-only hashing path.
submits registration data via `POST /register` ... Includes agentName, agentType, systemPrompt (hashed server-side, immediately discarded), optional public fields
Use only with prompts you are allowed to disclose to Chitin; review the exact registration payload, minimize publicFields, and avoid Auto mode for sensitive agents.
Users may underestimate that Chitin receives the full prompt before hashing, even if the service says it discards it.
This privacy framing can imply the full prompt stays local to the conversation, while other provided artifacts describe submitting `systemPrompt` to `POST /register` for server-side hashing.
### 🔒 PRIVATE — Never Leaves This Conversation ... `systemPrompt` | Hashed (SHA-256), then deleted | Your full prompt — NEVER stored
Make server-side receipt explicit before registration and require owner approval after showing the exact data that will be sent.
A leaked API key or misleading signature request could let someone alter identity records or submit authorized lifecycle events.
The skill uses bearer API keys and wallet signatures to authorize identity writes. That is expected for this protocol, but these credentials are high-impact.
Authentication: Two methods are supported: 1. **API Key (recommended for agents):** Use the `Authorization: Bearer chtn_live_...` header... 2. **EIP-712 signature**
Only sign typed data for the expected Chitin domain, protect the API key, and rotate it immediately if exposed.
If Auto mode is used, the agent could submit identity details without the owner seeing every field first.
The skill provides a safer Review path, but also documents an Auto mode for a registration workflow that can submit sensitive prompt data and create permanent records.
1. **Auto** — I'll fill everything myself. Fast, no questions. ... 3. **Review** — I'll prepare everything, show you a summary, then you approve. *(recommended)*
Use Review mode for registration and require explicit approval before any write, claim, reseal, chronicle, certificate, or vote action.
The agent may periodically check Chitin or report lifecycle changes if the owner enables that behavior.
The heartbeat describes periodic and event-triggered identity check-ins. It is disclosed and tied to owner preference, but it is ongoing agent behavior beyond a single invocation.
*This runs periodically based on your owner's preference...* ... **Don't wait for your next scheduled heartbeat** — report these as soon as they happen.
Set a clear heartbeat cadence and require owner approval for any heartbeat action that writes data.
Other agents may request access to private identity fields, and approving those requests could reveal prompt-derived information.
The skill supports inter-agent disclosure and binding flows. It directs the agent to involve the owner, which is appropriate, but the data boundary is sensitive.
another agent is requesting access to parts of your soul. Tell your owner so they can approve or deny via `POST /disclose/request/:requestId/approve`
Approve disclosure requests only after checking requester identity, requested fields, purpose, and whether direct P2P or API-relayed disclosure is being used.