Bitrix24 Skill
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is a disclosed Bitrix24 integration skill with real account-write capabilities, so it looks purpose-aligned but should be used with least-privilege credentials and review before writes.
Install only if you intend to let an agent work with your Bitrix24 account. Use a test portal first, grant minimal scopes, keep tokens out of chats, enable plan-only or explicit review for writes, avoid `--allow-unlisted` unless necessary, and protect any audit/DLQ files created by the offline worker.
Findings (5)
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.
If used with real credentials, the agent can make meaningful changes inside the connected Bitrix24 account.
The default method pack permits broad Bitrix24 method families, including CRM, task, and event operations. This is expected for the skill, but those APIs can create, update, or delete business records.
"core": ("batch", "user.*", "department.*", "crm.*", "tasks.task.*", "task.*", "event.*")Use least-privilege Bitrix24 scopes, prefer plan-only/two-phase execution for writes, review parameters before confirming, and avoid broad or unlisted methods unless needed.
Anyone or any agent process with these secrets may be able to act within the connected Bitrix24 permissions.
The skill expects OAuth or webhook credentials for real API calls. This is purpose-aligned, but these secrets delegate Bitrix24 account authority.
export B24_ACCESS_TOKEN="your_access_token" export B24_REFRESH_TOKEN="your_refresh_token" export B24_CLIENT_ID="your_client_id" export B24_CLIENT_SECRET="your_client_secret"
Store secrets outside chat transcripts, use a secret manager or protected environment variables, grant only required scopes, and rotate/revoke credentials when no longer needed.
CRM, chat, task, or event details could remain on disk in retry/DLQ files after failures.
Failed or exhausted offline events are written to a DLQ record with the full event payload. Event payloads may include business data and auth-related fields, so the local DLQ should be treated as sensitive.
"payload": event_item,
Keep DLQ/state files in a restricted location, set retention/cleanup rules, and scrub auth or sensitive fields before long-term storage.
A bad event-processing configuration could cause events to be cleared or routed to DLQ, affecting later automation.
The worker can acknowledge and clear offline events after processing or DLQ handling. This is appropriate for event reliability, but incorrect processing can affect downstream event replay.
- clears only successfully processed (or DLQ'ed) records,
Test the worker on a non-production portal, run with `--once` first, monitor DLQ/error counts, and only clear events after durable processing.
Users have less external provenance to rely on when deciding whether to trust the helper scripts.
The registry does not provide an upstream source or homepage, while the skill includes runnable helper scripts. No malicious behavior is shown, but provenance is limited.
Source: unknown Homepage: none No install spec — this is an instruction-only skill. Code file presence: 2 code file(s)
Review the included scripts before use, pin the skill version, and prefer installing from a trusted or auditable source.