Security audit
Security checks for vulnerabilities and agentic risk
This Didit admin skill is not malicious, but it needs review because it handles identity-verification records, credentials, billing, and destructive account actions with weak safeguards.
Install only if you are comfortable giving the agent access to a Didit administrative API key and identity-verification data. Avoid running the helper scripts in shared terminals or CI logs, do not paste full API responses into chats, confirm any delete/status/billing/webhook action manually, and prefer scoped keys plus redacted output.
scripts/setup_account.py:68Authentication secrets are exposed through process arguments and standard output
scripts/create_session.py:102Complete identity-verification decisions are written to standard output without redaction
SKILL.md:855Dependency installation instructions use an unpinned package version
The description substantially overstates the code's capabilities. The supplied code only interacts with session-related endpoints under the Didit verification API: POST /session/ to create sessions, GET /session/{id}/decision/ to retrieve a decision, and GET /sessions/ to list sessions. It does not implement any of the many other declared administrative areas such as accounts, API keys, workflows, questionnaires, users, billing, blocklists, or webhooks. The primary purpose is therefore much narrower than declared, making the description inaccurate.
The code chunk is narrowly scoped to workflow CRUD operations and minor workflow configuration fields such as label, AML, liveness, and face match. The declared description substantially overstates functionality by describing a comprehensive Didit platform administration skill spanning many categories and 45+ endpoints. While workflows are part of the declared description, the supplied code does not implement the vast majority of the claimed capabilities. This is a description-to-behavior mismatch due to materially overstating the skill's actual behavior and primary scope.
The description substantially overstates the code's functionality. The supplied script only supports three authentication/account-bootstrap actions against Didit's auth API: register, verify-email, and login. While account creation is covered, nearly all other declared capabilities—platform management, sessions, workflows, questionnaires, users, billing, blocklists, webhooks, and signature handling—are absent. This is a material description-to-behavior mismatch because the declared primary purpose is a comprehensive platform administration skill, while the actual code is limited to initial account setup/login.
A workflow delete endpoint is exposed without any documented safety constraints, confirmation pattern, or scoped authorization guidance. In a broad-activation admin skill, an attacker or accidental invocation could remove production workflows and disrupt all future verification operations.
DELETE /v3/workflows/{settings_uuid}/
Response: 204 No Content. Existing sessions are not affected.
The session deletion endpoint permanently removes associated data, yet the skill presents it as a normal operation without strict safeguards. Given that sessions can contain sensitive KYC evidence and decision history, misuse could destroy regulated records, erase fraud evidence, or cause severe compliance and support impact.
DELETE /v3/session/{sessionId}/delete/
Response: 204 No Content. Permanently deletes all associated data.
Questionnaire deletion is a mutating administrative action that can remove active form configurations relied on by workflows. Without confirmation and access scoping, a prompt injection or mistaken request could break onboarding flows or erase business logic.
DELETE /v3/questionnaires/{questionnaire_uuid}/
Response: 204 No Content.
The verification flow prints the returned API key directly to stdout, which can expose a long-lived secret in terminal scrollback, shell logging, CI logs, screen recordings, or shared sessions. In a platform-administration skill, this is especially dangerous because the API key likely grants broad account access across verification, billing, users, and webhook management.
On successful login, the script prints the entire JSON response, which may include an access token even though the message only references its expiration. Emitting bearer tokens to stdout can leak credentials through terminal history, process capture, logs, or CI output, enabling unauthorized access to the Didit account and administrative APIs.
elif args.command == "login":
result = login(args.email, args.password)
print(json.dumps(result, indent=2))
print(f"\n--- Login successful. Access token expires in {result.get('expires_in', '?')}s ---")
if __name__ == "__main__":
The skill documents capabilities that rely on environment access, network access, and likely MCP/tooling, but it does not declare any explicit allowed-tools or permission scope. In an agent environment, that omission can let the skill be invoked with broader runtime authority than users or reviewers expect, especially because it performs account creation, credential retrieval, billing, webhook management, and destructive deletions.
The activation language is extremely broad, including phrases like 'handle any platform administration,' which could cause the skill to trigger for loosely related admin/support requests. In this context that is risky because the skill exposes powerful actions such as API key handling, billing top-ups, webhook reconfiguration, manual approval/decline, and destructive deletion.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests
# 1. Register (any email, no business email required)
requests.post("https://apx.didit.me/auth/v2/programmatic/register/",
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests
# 1. Register (any email, no business email required)
requests.post("https://apx.didit.me/auth/v2/programmatic/register/",
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests
# 1. Register (any email, no business email required)
requests.post("https://apx.didit.me/auth/v2/programmatic/register/",
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests
# 1. Register (any email, no business email required)
requests.post("https://apx.didit.me/auth/v2/programmatic/register/",
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests
# 1. Register (any email, no business email required)
requests.post("https://apx.didit.me/auth/v2/programmatic/register/",
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests
# 1. Register (any email, no business email required)
requests.post("https://apx.didit.me/auth/v2/programmatic/register/",
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests
# 1. Register (any email, no business email required)
requests.post("https://apx.didit.me/auth/v2/programmatic/register/",
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
json={"email": "you@gmail.com", "password": "MyStr0ng!Pass"})
# 2. Check email for 6-char OTP, then verify → get api_key
resp = requests.post("https://apx.didit.me/auth/v2/programmatic/verify-email/",
json={"email": "you@gmail.com", "code": "A3K9F2"})
api_key = resp.json()["application"]["api_key"]
headers = {"x-api-key": api_key, "Content-Type": "application/json"}
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
headers = {"x-api-key": api_key, "Content-Type": "application/json"}
# 3. Create a KYC workflow
wf = requests.post("https://verification.didit.me/v3/workflows/",
headers=headers,
json={"workflow_label": "My KYC", "workflow_type": "kyc",
"is_liveness_enabled": True, "is_face_match_enabled": True}).json()
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"is_liveness_enabled": True, "is_face_match_enabled": True}).json()
# 4. Create a session → send user to the URL
session = requests.post("https://verification.didit.me/v3/session/",
headers=headers,
json={"workflow_id": wf["uuid"], "vendor_data": "user-123"}).json()
print(f"Send user to: {session['url']}")
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Response (201): Workflow object with uuid.
wf = requests.post("https://verification.didit.me/v3/workflows/",
headers={"x-api-key": API_KEY, "Content-Type": "application/json"},
json={"workflow_label": "KYC + AML", "workflow_type": "kyc",
"is_liveness_enabled": True, "is_face_match_enabled": True,
The markdown describes permanent session deletion and bulk deletion, including a delete_all option, without strong user-facing warnings, confirmation gates, or safety preconditions. Because this platform handles identity-verification records, accidental or induced deletion can cause irreversible loss of compliance-relevant data and operational disruption.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
| options | array | Conditional | Required for multiple_choice/checkbox |
requests.post("https://verification.didit.me/v3/questionnaires/",
headers=headers,
json={
"title": "Employment Details",
The user deletion operation allows batch deletion and delete_all semantics without clearly emphasizing irreversibility and downstream consequences. In an identity-verification context this can erase user-linked records, disrupt onboarding/review workflows, and create compliance, support, and auditability issues.
This code builds a payload containing potentially sensitive values such as vendor_data, callback, language, and metadata, then sends it via requests.post to an external service. Although the module docstring describes the command usage, it does not clearly warn that these fields will be transmitted off-system, which meets the missing-disclosure criterion for network calls carrying user or system data.