Webhook Token Security (Zero‑Exposure Edition)
Secure webhook token management using MGC Blackbox. Supports DingTalk, WeCom, Feishu, Telegram, Slack and more. Store webhook tokens locally in encrypted form, retrieve at runtime …
zkeviny
@zkeviny
Install
$ openclaw skills install @zkeviny/token-safe-webhook-senderOverview
Webhook Token Security is a documentation skill that teaches how to manage webhook tokens securely using MGC Blackbox. Supports multiple platforms including DingTalk, WeCom (Enterprise WeChat), Feishu (Lark), Telegram, and Slack. It enables AI agents to send notifications without ever exposing webhook tokens to the AI model.
This skill contains no executable code and is safe for automatic approval.
What This Skill Enables
After reading this documentation, an AI agent will understand how to:
- Store webhook tokens (DingTalk, WeCom, Feishu, Telegram, Slack, etc.) securely in MGC Blackbox
- Retrieve tokens at runtime without AI seeing plaintext
- Send notifications through local scripts (Mode A) or via
mgc_run(Mode B, full zero-exposure) - Pass message content to scripts via the
ext02parameter - Handle platform-specific differences
- Rotate tokens without code changes
Prerequisites
- Install MGC Blackbox:
pip install mgc-blackbox(recommended 1.4.9+) - Start MGC service:
mgc(WebUI: http://127.0.0.1:57218, API: http://127.0.0.1:57219) - Use MCP tools (
mgc_save,mgc_run,mgc_list,mgc_open_webui,mgc_seal) for token & script management
Important:
mgc_getreturns plaintext and is for human/debug use only — it breaks zero-exposure. Prefermgc_runfor AI-driven sending.
Sandbox mode (Trae Work / Workbuddy): After installing MGC, open the WebUI to view and install the main MGC skill documentation. Run
mgc --statusto check status and sandbox mode.
Supported Platforms
| Platform | Token Type | Storage Format | API Endpoint |
|---|---|---|---|
| DingTalk | access_token + secret | JSON | https://oapi.dingtalk.com/robot/send |
| WeCom | webhook key | Plain text | https://qyapi.weixin.qq.com/cgi-bin/webhook/send |
| Feishu | webhook_url | Plain text | Custom webhook URL |
| Telegram | bot_token | Plain text | https://api.telegram.org/bot{token}/sendMessage |
| Slack | webhook_url / bot_token | JSON | Incoming Webhook or Web API |
Platform-Specific Storage
DingTalk
Requires both access_token and secret for signature verification.
{
"access_token": "your_access_token",
"secret": "your_secret",
"webhook": "https://oapi.dingtalk.com/robot/send?access_token=xxx"
}
Storage key: info_type=config, info_owner=dingtalk_myapp
WeCom (Enterprise WeChat)
Requires only the webhook key from the custom robot configuration.
{
"webhook_key": "your_webhook_key",
"webhook_url": "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx"
}
Storage key: info_type=config, info_owner=wecom_myapp
Feishu (Lark)
Requires the webhook URL from the custom bot configuration.
{
"webhook_url": "https://open.feishu.cn/open-apis/bot/v2/hook/xxx"
}
Storage key: info_type=config, info_owner=feishu_myapp
Telegram
Requires bot_token and optionally chat_id.
{
"bot_token": "your_bot_token",
"chat_id": "your_chat_id"
}
Storage key: info_type=config, info_owner=telegram_mybot
Slack
Can use either incoming webhook URL or bot token.
{
"webhook_url": "https://hooks.slack.com/services/xxx",
"bot_token": "xoxb-xxx",
"channel": "#my-channel"
}
Storage key: info_type=config, info_owner=slack_myapp
Storing Webhook Tokens
Step 1: Prepare Token File
Create a JSON file containing your webhook token details (see Platform-Specific Storage above).
Step 2: Store in MGC
Important: Tokens should be stored by humans via WebUI to avoid AI directly handling sensitive values. AI may call
mgc_open_webuito open the page for the user.
Recommended: WebUI (for human operators)
- Open: http://127.0.0.1:57218
- Navigate to Save page
- Enter info_type:
config, info_owner:your_webhook_name - Enter token content
- Click Save
Alternative: MCP (for AI agents, when user-authorized)
- Store token:
mgc_save(info_type="config", info_owner="...", content=...) - List stored tokens (no plaintext):
mgc_list(info_type="config")
Two Execution Modes
Mode A: Local Script + MGC-stored Config (token zero-exposure)
Script runs locally and reads the token from MGC via HTTP API at runtime. The token never appears in code, but the script source is visible to whoever runs it.
- User stores token via WebUI (
info_type=config) - Local script reads token from MGC API at runtime
- Script formats message and sends HTTP POST
- Returns non-sensitive result only
Suitable for: one-off or debug tasks where you control the host.
Mode B: Script in MGC + mgc_run (full zero-exposure) — recommended
Script is stored (and optionally sealed) inside MGC. AI calls mgc_run to execute; MGC returns only the execution result. AI never sees the token, the script source, or stdout.
- Store token:
mgc_save(info_type="config", info_owner="dingtalk_myapp", content=...) - Store sending script:
mgc_save(info_type="script", info_owner="webhook_send_dingtalk_v1", ext01="python", content=...) - (Optional) Seal script:
mgc_seal(info_owner="webhook_send_dingtalk_v1")— sealed scripts can only run inside MGC, cannot be decrypted - AI executes:
mgc_run(info_owner="webhook_send_dingtalk_v1", ext02=json.dumps({"message": "deploy ok"})) - MGC returns execution result only
Suitable for: production, multi-agent collaboration, any case where AI must not touch the token.
Note:
mgc_runreturns only the execution result, not script stdout. For sending tasks, have the script return a status JSON as the result; if detailed output is needed, write to a file and return the path.
ext02 Parameter (passing message content)
ext02 carries runtime params to the script. It MUST be a JSON string (use json.dumps()). Some MCP clients mis-serialize dict values and return HTTP 422.
import json
ext02 = json.dumps({"title": "Alert", "message": "Deploy succeeded"})
result = mgc_run(info_owner="webhook_send_dingtalk_v1", ext02=ext02)
The script reads ext02 from its input, fetches the token from MGC internally, and sends. Token and script source stay inside MGC.
MGC Blackbox API Reference
Service Endpoint
- Base URL: http://127.0.0.1:57219
- Token File: ~/.mgc/database/mgc_black_box/.mgc_token
- Token: String token read from token file, required for all API calls
Get Token API
Endpoint: /api/mgc/sensitive/get Method: POST Headers:
- X-MGC-Token: (string token read from token file)
- Content-Type: application/json
Body fields:
- info_type: "config"
- info_owner: your chosen identifier
Response fields:
- code: status code
- data.content: JSON string containing stored token
Save Token API
Endpoint: /api/mgc/sensitive/save Method: POST Headers: same as above
Body fields:
- info_type: "config"
- info_owner: your identifier
- content: JSON string of token
Run Script API (mgc_run, since 1.4.7)
Endpoint: /api/mgc/sensitive/run Method: POST Headers: same as above
Body fields:
- info_type: "script"
- info_owner: script name
- ext02: JSON string of runtime params
Response: execution result only (non-blocking since 1.4.5, may return PID immediately). mgc_get action=run is retained for backward compatibility.
Security Best Practices
- Never embed tokens in code
- Use MGC for token storage
- Retrieve tokens at runtime only
- Never log or print tokens
- Rotate tokens regularly
- Use separate tokens per platform/per bot
- Limit webhook permissions (send-only where possible)
Use Cases
- Deployment notifications
- CI/CD pipeline alerts
- System monitoring alerts
- Team collaboration bots
- Automated workflow triggers
Learn More About MGC Blackbox
Want to learn more about MGC Blackbox?
- Visit: https://github.com/zkeviny/MGC-Blackbox
- Report issues: https://github.com/zkeviny/MGC-Blackbox/issues
- Contact: mirgincipher@outlook.com
License
MIT
Top skills in this category
Google Meet
@hith3shGoogle Meet API integration with managed OAuth. Create meeting spaces, inspect conference records, retrieve recordings and transcripts, and manage meeting pa...
Gmail OAuth Setup
@kai-jarSet up Gmail API access via gog CLI with manual OAuth flow. Use when setting up Gmail integration, renewing expired OAuth tokens, or troubleshooting Gmail authentication on headless servers.
API Gateway
@byungkyuCall third-party APIs through the Maton gateway, which injects the credential for an app the user has already connected. Use this skill when the user names a connected app and a concrete action in it - read a mailbox, query a CRM, file an issue, update a spreadsheet, etc.
gmail
@byungkyuGmail API integration with managed OAuth. Read, send, and manage emails, threads, labels, and drafts. Use this skill when users want to interact with Gmail. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Calls run through the `maton` CLI with OAuth login, or over raw HTTP with a Maton API key where the CLI cannot be installed. Every call is authenticated as the user's connection and reaches only what that connection's authorization allows, which the provider enforces on every request; the endpoints documented here are the ones this skill uses, and any other endpoint of this app needs the user to ask for it by name. Default to read and list calls, and confirm every write or new connection with the user. This file also documents the three constructs that turn a Gmail connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a Gmail action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with Gmail examples; they add no Gmail capability - Gmail is itself an event source, so its own events are in `references/google-mail/triggers.md`, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).
1password
@steipeteSet up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.