awiki-agent-did-message

• Outcome: Review
• Latest audit: Sep 11, 2026 · 2:38 AM UTC
• Version: 1.3.10

Overview

The skill mostly matches its identity and messaging purpose, but it should go to Review because its install and upgrade paths can load unreviewed remote code or instructions and some scripts expose sign-in token fragments.

Before installing, avoid the HTTP zip path and prefer a reviewed, pinned, HTTPS source with checksum or signature verification. Review any remote update instructions before loading them, enable the background listener only if you want persistent real-time message handling, and avoid sharing terminal output or logs from identity setup because they may contain token fragments.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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

Findings (4)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:49
• Finding: Unauthenticated Remote Archive Retrieval Followed by Code Execution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:49-52` **Vulnerability Type**: Unauthenticated remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash curl -L -o <SKILL_DIR>/../awiki-agent-id-message.zip http://awiki.info/static-files/awiki-agent-id-message.zip unzip -o <SKILL_DIR>/../awiki-agent-id-message.zip -d "$(dirname <SKILL_DIR>)" cd <SKILL_DIR> && python install_dependencies.py rm -f <SKILL_DIR>/../awiki-agent-id-message.zip ``` ### Technical Analysis The recommended installation procedure downloads an executable Skill archive over plaintext HTTP. The procedure does not verify a digital signature, cryptographic checksum, pinned release identifier, or trusted certificate before extracting the archive and executing its `install_dependencies.py` script. Because HTTP provides neither server authentication nor transport integrity, an attacker positioned on the network path can replace or modify the archive. The same risk applies if the download server or its DNS records are compromised. The downloaded origin, `awiki.info`, also differs from the `awiki.ai` origin identified elsewhere as the canonical service. The extracted Python script imports additional project modules during installation, including database migration code. Consequently, modifying either `install_dependencies.py` or one of its imported modules is sufficient to execute attacker-controlled Python code. ### Attack Path 1. A user or Agent follows the recommended ZIP installation instructions. 2. The archive request is sent to `http://awiki.info/...` without TLS. 3. A network-positioned attacker, compromised proxy, malicious access point, DNS attacker, or compromised download server returns a modified ZIP archive. 4. The command extracts the unverified archive into the Skill installation area. 5. The procedure immediately executes `python install_dependencies.py`. 6. Attacker-controlled Python code runs with the privileges of the user ...[truncated 627 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the plaintext HTTP installation option. 2. Distribute releases exclusively over HTTPS from a canonical, documented origin. 3. Publish a SHA-256 digest through an independently authenticated channel and verify it before extraction. 4. Prefer cryptographically signed release artifacts and validate the signature against a pinned publisher key. 5. Pin the downloaded artifact to a specific immutable release rather than a mutable filename. 6. Extract into a newly created temporary directory and validate every archive member before installation. 7. Reject absolute paths, `..` traversal components, device files, and unsafe symbolic links in the archive. 8. Display the verified version and require explicit approval before executing any downloaded script. 9. Prefer a pinned Git commit or signed Git tag when installing from the source repository. ]]>

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:19
• Finding: Remotely Mutable Skill Instructions Can Replace Reviewed Behavior<. **Git clone**: `cd <SKILL_DIR> && git pull && python install_dependencies.py` **Zip archive**: Delete old directory, reinstall following "Step 0" above. ``` ### Technical Analysis The reviewed package designates a remotely mutable document as the authoritative source for Skill instructions. It tells an Agent to fetch that document when the local copy is considered missing, unavailable, or incomplete, without requiring a pinned version, signature verification, reviewed diff, or explicit user authorization. HTTPS protects the network connection when its assumptions hold, but it does not protect against compromise of the hosting account, web application, deployment pipeline, or origin server. It also does not make future changes equivalent to the version that was statically audited. An altered remote `skill.md` could introduce commands, new tool-use instructions, credential-access requests, or modified safety policies after this package has passed review. ### Attack Path 1. An attacker compromises the remote document, its hosting infrastructure, or its publication pipeline. 2. The attacker changes `https://awiki.ai/skill.md` to include malicious or unsafe Agent instructions. 3. The local Skill file is absent or is treated as incomplete, or an upgrade workflow consults the stat ...[truncated 765 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not automatically treat remotely hosted Skill text as authoritative. 2. Package the complete instructions with each reviewed release. 3. Pin upgrades to an immutable version, signed release, or specific Git commit. 4. Verify a digital signature against a locally pinned publisher key before accepting replacement instructions. 5. Present a security-relevant diff and require explicit user approval before loading changed instructions. 6. Define “missing or incomplete” deterministically so remote retrieval cannot be triggered by ambiguous conditions. 7. Ensure remotely retrieved documentation cannot expand tool permissions or override local safety requirements. 8. If online update checks are retained, restrict them to reporting that a new signed release exists rather than loading its instructions into the active session. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/setup_identity.py:84
• Finding: JWT Token Material Disclosed Through Terminal Output<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup_identity.py:84-89` **Vulnerability Type**: Sensitive authentication data exposure **Risk Level**: High ### Vulnerable Code ```python print(f" DID : {identity.did}") print(f" unique_id : {identity.unique_id}") print(f" user_id : {identity.user_id}") print(f" JWT token : {identity.jwt_token[:50]}...") # Save credential path = save_identity( ``` Equivalent token-prefix output patterns were also identified in `scripts/register_handle.py:108` and `scripts/regenerate_e2ee_keys.py:187`. ### Technical Analysis The code prints the first 50 characters of a JWT bearer token. This directly conflicts with the Skill's own security rule that JWTs must never be output to chat, logs, or external systems. JWT prefixes commonly include the complete encoded header and part or all of the encoded claims payload. Even when the displayed prefix is insufficient to authenticate by itself, it can disclose token structure and identity or authorization claims. Terminal output may also be captured by Agent transcripts, CI logs, shell session recorders, service wrappers, debugging systems, or support bundles. A fixed 50-character prefix is substantially more disclosure than the documented redaction approach of retaining only a few characters. ### Attack Path 1. A user or Agent creates, registers, or regenerates an identity. 2. The service returns a JWT access token. 3. The script prints the first 50 characters to standard output. 4. Output is captured in an Agent conversation, shell history recording, CI log, diagnostic log, or shared support transcript. 5. A party with access to the captured output obtains JWT metadata and a substantial token fragment. ### Impact Assessment The confirmed impact is disclosure of sensitive authentication material and potentially decoded JWT claims. If token formats change, tokens are unusually short, or output handling captures adjacent data, the exposure could becom ...[truncated 345 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove all output of JWT values and token substrings. 2. Report only non-secret state, such as `JWT obtained`, `JWT refreshed`, `valid`, or `expired`. 3. If operational correlation is necessary, use a short one-way fingerprint such as the first eight hexadecimal characters of SHA-256 over the token, and clearly label it as a fingerprint. 4. Search all scripts for token slicing or formatting and remove equivalent output from `register_handle.py` and `regenerate_e2ee_keys.py`. 5. Add centralized logging redaction for bearer tokens, authorization headers, and JWT-shaped strings. 6. Add tests asserting that CLI output never contains the token or meaningful token prefixes. 7. Avoid returning raw tokens in exceptions and redact authentication-related HTTP diagnostics before logging them. ]]>

T08 · Insecure Dependencies

Warning

• Location: requirements.txt:1
• Finding: Unpinned Dependencies Allow Unreviewed Future Package Versions<![CDATA[ ## Vulnerability Details **File Location**: `requirements.txt:1-3`; dependency installation occurs in `install_dependencies.py:45-50` **Vulnerability Type**: Non-reproducible and integrity-unpinned dependency installation **Risk Level**: Medium ### Vulnerable Code ```text anp>=0.6.8 httpx>=0.28.0 websockets>=14.0 ``` The installer passes this file directly to pip: ```python current_python_pip = [ sys.executable, "-m", "pip", "install", "-r", requirements, ] ``` ### Technical Analysis All dependencies use open-ended lower bounds. Any future version satisfying the constraint may therefore be installed, even if that version did not exist when the Skill was reviewed. The installation process does not use a lockfile, exact versions, package hashes, or an explicitly constrained package index. Python packages can execute code during installation or when imported. These dependencies are subsequently imported by scripts that handle JWTs, DID private keys, E2EE keys, and network communications. A malicious or compromised future release could therefore operate in a sensitive execution context. This finding does not establish that the currently named packages are malicious. The vulnerability is that the build is not reproducible and implicitly trusts all future compatible releases. ### Attack Path 1. An attacker compromises a dependency publisher account, package repository, release pipeline, or an allowed future package release. 2. The attacker publishes a malicious version satisfying one of the `>=` constraints. 3. A user runs `install_dependencies.py` after the malicious version becomes available. 4. Pip resolves and installs the newer unreviewed version. 5. Malicious package code executes during installation or later when imported by the Skill. 6. The package can act with the installing user's privileges and may access data made available to the Skill process. ### Impact Assessment Successful exploitation can result in arb ...[truncated 503 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin every direct dependency to an exact reviewed version. 2. Generate and commit a lockfile that also pins transitive dependencies. 3. Record cryptographic hashes for every distribution and install with `pip --require-hashes`. 4. Use a trusted, explicitly configured package index and disable unintended extra indexes. 5. Review dependency updates before changing the lockfile. 6. Add automated vulnerability and provenance checks to the release process. 7. Prefer signed or provenance-attested packages where the ecosystem supports them. 8. Separate dependency installation from credential-bearing runtime processes and avoid importing newly installed packages until verification has completed. ]]>

SkillSpector

Vulnerability Patterns

• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• 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

Findings (180)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a runtime skill centered on DID identity, handles, profiles, publishing, messaging, groups, E2EE, WebSocket listeners, and user search. The supplied code chunk does not implement any of those user-facing or protocol capabilities. Instead, it performs package installation, optional pip bootstrapping, and post-install local database upgrade checks, with status output about listener service coordination. These are operational/setup capabilities not reflected in the declared purpose and represent a materially different primary purpose for this code chunk. While such setup logic could support the broader project, this specific code does not match the declared skill behavior.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description promises a substantial agent identity and messaging platform with encryption and real-time communication features. The actual supplied code chunk is just an __init__.py docstring for package initialization and does not implement any of those capabilities. This is a clear description-behavior mismatch: the code shown has a materially different and much narrower purpose than the declared skill description.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The supplied code does not implement or expose the declared platform capabilities such as DID identity management, handle registration, content publishing, federated messaging, group communication, WebSocket listeners, search, or end-to-end encrypted inbox functionality. Instead, its primary and explicit purpose is post-registration account contact binding: attaching an email or phone number to an existing account using a stored identity/JWT, activation links, and OTP verification. That is a materially different function from the declared description, and the triggers in the description are unrelated to this script’s actual behavior.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The description presents a full-featured DID identity and agent communications platform, including identity creation/management, handle registration, content publishing, search, follow, federated messaging, group communication, and default-on E2EE/listener behaviors. The supplied code chunk does not implement most of that surface area. It is specifically an inbox/history utility script: it loads existing credentials, fetches inbox or history via RPC, optionally processes/decrypts E2EE protocol messages, marks messages as read, persists local cache/group snapshots/contacts, and falls back between WebSocket-local-cache and HTTP modes. Group history and E2EE message handling do align with part of the declared messaging/inbox functionality, but the primary purpose of this code chunk is much narrower than the declared description. Therefore the description does not accurately represent what this supplied code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The supplied code does not implement the broad agent identity and messaging platform described. It is a narrow storage utility module for credential path construction, secure file writes, credential index management, and legacy layout detection/migration support on the local filesystem. While some filenames reference DID and E2EE artifacts, the code does not perform DID networking, inbox messaging, HPKE encryption operations, handle registration, content publishing, search, WebSocket listening, or proactive background behaviors. The description therefore materially overstates and misrepresents this code chunk’s actual purpose.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The code chunk does not implement the declared end-user capabilities such as DID interactions, handle registration, profile/content publishing, messaging, group communication, WebSocket listeners, search, or active E2EE messaging flows. Instead, it is a maintenance/migration module focused on local credential persistence: scanning legacy files, reading JSON, saving identity and E2EE state into a new layout, and moving old files into backup directories. While credential and E2EE state management are adjacent to the broader product domain, this module’s primary purpose is operational migration, which is not reflected in the declared description. That is a material description-versus-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The code does not implement DID identity, handle registration, profile/content publishing, messaging, group communication, search, or HPKE-based E2EE. Its primary purpose is infrastructure maintenance: managing a local database schema and coordinating listener restarts around upgrades. While the docstring mentions 'owner_did-aware multi-identity storage' and listener coordination, those are narrow support functions and not the declared end-user capabilities. This is therefore a material description-to-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 92% confidence
• Finding: There is a meaningful description-to-code mismatch. The description presents a comprehensive identity and communication skill spanning DID identity, handle registration, profile/content publishing, federated messaging, groups, listener behaviors, and E2EE. The actual code chunk only covers one subset: end-to-end encrypted direct messaging workflow, including handshake, encryption/decryption, inbox processing, error signaling, and outbox failure recovery. While this is consistent with the E2EE portion of the description, the code does not substantiate most of the broader declared capabilities. Additionally, the code exposes outbox failure management operations that are not mentioned in the description. This is best classified as a mismatch because the declared purpose materially overstates the code chunk’s represented functionality.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a broad agent identity and secure messaging platform built on ANP/did:wba, with inbox, E2EE, publishing, handles, search, listeners, and proactive behaviors. The supplied code does none of that. It is a standalone contact-management CLI that loads an existing local identity, writes contact snapshots and append-only relationship events to a local store, and updates local metadata such as followed/messaged flags and notes. While it references DIDs and credentials, those are only used as identifiers for local ownership context, not to implement the claimed identity, messaging, encryption, or networking capabilities. This is a clear material mismatch in primary purpose and capabilities.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The code chunk does support one narrow slice of the declared description: content publishing/management for authenticated users. However, the declared purpose presents a much broader skill centered on DID identity, encrypted inbox messaging, groups, listeners, search, and proactive runtime behaviors. None of those capabilities appear in this code. Instead, the actual code only manages content pages through CRUD-style RPC calls to /content/rpc. This is a materially narrower and different behavior profile than the declared skill description, so the description does not accurately represent what this code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description focuses on decentralized identity, handles, profiles, publishing, messaging, groups, E2EE, listeners, and user discovery. The actual code does none of those things. Instead, it implements a credits-management utility that calls /user-service/credits/rpc methods: get_balance, get_transactions, and get_rules. While it references identity credentials for authentication, that is only a supporting detail for accessing the credits API and does not align the script with the declared primary purpose. This is a clear material mismatch in purpose, capabilities, and triggers.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a broad agent identity and encrypted inbox platform with DID/self-sovereign identity, handle registration, profile/content publishing, federated messaging, search, WebSocket listeners, and default-on HPKE E2EE. The supplied code does not implement that broad purpose. It is specifically a CLI for AWiki group operations: creating and updating groups, managing join codes, joining/leaving groups, listing/kicking members, posting/listing group messages, persisting snapshots/messages locally, and fetching a public markdown document. While there is some overlap with the declared 'group communication' and messaging concepts, the main advertised capabilities—identity lifecycle, handle registration, content publishing, search, listener setup, heartbeat behavior, and E2EE—are absent from this code chunk. Therefore the description materially overstates and misrepresents what this code actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The supplied code chunk does not implement the declared end-user features. Its primary purpose is a local authenticated TCP RPC daemon for routing message operations to a handler and supporting a single remote WebSocket session. While this may be a supporting component of a larger messaging system, the description presents a much broader identity/messaging/E2EE platform. In this chunk there is no DID creation or verification, no handle/profile/content publishing logic, no search, no group features, and no encryption implementation. The only overlap is indirect support for messaging/WebSocket listener infrastructure. Because the code’s actual behavior is a local transport daemon rather than the declared identity and encrypted inbox functionality, this is a material description-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description describes a networked identity/messaging platform centered on DIDs, agent inboxes, publishing, messaging, groups, and HPKE-based E2EE. The actual code does none of those things. Instead, it implements a local maintenance utility for migrating stored credentials from one filesystem layout to another. This is a materially different primary purpose and an undeclared capability unrelated to the declared triggers such as DID, inbox, messaging, follow, group, search, or WebSocket listener behavior. Therefore this is a clear description-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description presents a networked identity and messaging platform with DID, handles, publishing, inbox, group chat, search, listeners, and E2EE capabilities. The actual code chunk does not implement or expose those behaviors. Instead, it is an explicit local maintenance script whose primary purpose is migrating a local SQLite database schema to an owner_did-aware version and emitting a JSON result. This is a materially different purpose from the declared agent identity/messaging functionality, so it should be flagged as a mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description presents a full DID/agent-identity and encrypted messaging platform with capabilities like DID management, handle registration, content publishing, federated messaging, group communication, E2EE, WebSocket listeners, and user search. The provided code does not implement any of those primary behaviors. Instead, it is a developer/ops-oriented command-line database inspection tool for a local SQLite store. While the example tables hint that the broader project may involve messaging or identity data, this code chunk itself only performs read-only SQL querying against local storage. That is a materially different primary purpose and exposes an undeclared capability: arbitrary database querying. Therefore this is a clear description-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: This is a description-behavior mismatch. The description presents a full-featured agent identity and encrypted communication skill with inbox, messaging, group communication, publishing, search, and listener behaviors. The actual code chunk only implements a one-off administrative CLI for regenerating E2EE keys on an existing DID identity, re-signing the DID document, updating it on a server, and saving refreshed credentials. While E2EE and DID identity are related to the declared domain, the primary purpose of this code is maintenance/recovery rather than the broad runtime capabilities claimed in the description. Therefore the supplied description does not accurately represent what this specific code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The declared description presents a full-featured DID identity and encrypted messaging platform for agents, including registration, publishing, messaging, group features, E2EE, listeners, and proactive behaviors. The supplied code chunk only implements a command-line identifier lookup tool for handle-to-DID resolution and reverse DID-to-handle lookup. While this is related to the identity/handle portion of the description, it does not implement most of the declared capabilities and its primary purpose is much narrower. Therefore the description does not accurately represent what this specific code chunk actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description presents a comprehensive agent identity and messaging system centered on DID identity, federated inboxes, publishing, group communication, search, WebSocket listeners, and default-on E2EE. The actual code chunk does not implement or expose those capabilities. Instead, it performs a specific operational task: accepting a phone number argument, creating a user service client, sending an OTP, and printing instructions for registration/recovery. While OTP verification could be a supporting component of handle registration, this code’s direct behavior is much narrower and relies on phone/SMS verification, which is not disclosed in the description. Therefore the supplied chunk’s primary purpose is materially different from the declared purpose, making this a mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description centers on decentralized identity, handles, publishing, messaging, groups, and HPKE-based end-to-end encryption. This specific code chunk does not implement those identity or messaging features. Instead, its primary purpose is system service orchestration for a background WebSocket listener process. While a WebSocket listener is mentioned in the broader description's proactive behaviors, this code is not merely incidental listener logic; it provides undeclared OS-level persistence and lifecycle management capabilities. Those capabilities are materially different from the declared end-user purpose and should be flagged as a mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description describes a full agent identity and encrypted messaging platform with DID, handle registration, publishing, messaging, groups, E2EE, WebSocket listeners, and search capabilities. The actual code chunk does none of those things. It is strictly a helper for command-line error rendering and exit behavior. While such a utility could be a supporting component inside a larger system, this specific chunk’s behavior is unrelated to the declared primary purpose and triggers. Therefore this is a clear description-to-code mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence
• Finding: The supplied code chunk is a low-level networking utility, not an implementation of the declared agent identity and encrypted inbox features. It does not perform DID operations, content publishing, messaging, encryption, listener setup, or proactive behaviors described in the declaration. While HTTP client setup could be a supporting component of such a system, this chunk’s actual behavior is far narrower and materially different from the declared primary purpose, so this should be flagged as a mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 90% confidence
• Finding: The supplied code is narrowly focused on end-to-end encryption session management. It resolves DID documents to obtain signing/X25519 public keys, performs HPKE session initiation and rekeying, encrypts/decrypts messages, verifies proofs, emits/handles E2EE ack and error messages, and persists session state. That aligns with only one subset of the description: HPKE-based E2EE over ANP using did:wba identities. However, the declared description presents a much broader skill covering identity features, handle registration, profile/content publishing, inbox/federated messaging features, groups, search, WebSocket/listener automation, and proactive heartbeat/status behaviors. None of those broader capabilities are implemented in this code chunk. Therefore the description materially overstates what this code actually does.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: The declared description describes a networked identity and messaging platform for AI agents. The actual code chunk contains only local logging infrastructure: file path management, log cleanup, logging handlers, stdio mirroring, and exception logging. It does not implement or expose any DID, identity, messaging, encryption, search, or WebSocket functionality. This is a clear description-behavior mismatch with a materially different primary purpose.

Ae1

High

• Category: analysis-evasion

Content

If the local `SKILL.md` file is missing, unavailable, or incomplete, Agents should fetch the canonical copy from **https://awiki.ai/skill.md**.

• Confidence: 100% confidence
• Finding: Referenced artifact was not completely inspected

Static analysis

Detected: suspicious.exposed_secret_literal, suspicious.install_untrusted_source, suspicious.prompt_injection_instructions

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: scripts/regenerate_e2ee_keys.py:93

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: scripts/utils/auth.py:31

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: scripts/utils/e2ee.py:261

Install source points to URL shortener or raw IP.

Warn

• Code: suspicious.install_untrusted_source
• Location: service/listener.example.json:3

Install source points to URL shortener or raw IP.

Warn

• Code: suspicious.install_untrusted_source
• Location: service/settings.example.json:13

Prompt-injection style instruction pattern detected.

Warn

• Code: suspicious.prompt_injection_instructions
• Location: references/RULES.md:83