SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillskuroco-security-audit

kuroco-security-audit

Security & auditing

View repository

Updated 10-15 21:10

About this skill

Kuroco Security Settings Check Skill (Admin MCP)

Overview

Admin MCP のRead-only tools onlyto collect Kuroco site settings, and references/checklist.md criteria to summarize findings.

Scope of this skill Out of scope
Review of setting values for items configurable in the admin panel (detection of misconfigurations, excessive permissions, weak policies) Vulnerability scanning / penetration testing (guide users to external services such as VAddy)
Matching setting values against recommended values, assigning risk severity, and presenting remediation policies Modifying settings (not performed by this skill. For modifications, switch to /kuroco-admin-mcp and carry them out with user approval)
Turning items that cannot be obtained via MCP into a "manual check list" Evaluation of the safety of the Kuroco platform itself (→ kuroco-docs about/security.md）

Minimal flow (usually 3–6 tool calls):

  1. Agreement on audit scope (target site, check categories, report format)
  2. Understanding the available read tools
  3. Collecting setting values (read-only, parallelizable)
  4. Judging against the checklist → report

Prerequisite: Connection

For the Admin MCP connection, authentication, and scoped URL specifications, see /kuroco-admin-mcp . In this skill, only the following are observed.

  • /readonly A scoped URL with is recommended. Write tools do not appear in the list, so accidents can be structurally prevented 
    https://{site}.g.kuroco.app/direct/rcms_api/admin_mcp/x/all/readonly
  • Since an audit looks across modules, the scope is often appropriately all ./readonly used together with
  • Even if the connected server has a writable scope (such as/x/all ),only read-only tools are called while this skill is being executed

Procedure

Step 1: Agreement on audit scope

Confirm with the user before execution (do not start based on assumptions):

  1. Target site — If there are multiple connected Admin MCP servers, which one. Whether it is production or staging
  2. Check categories — All categories, or specific categories (e.g., only around public APIs)
  3. Site premises — Appropriate settings differ for a "fully public media site," a "members-only site," or "internal use." Always ask because this is the basis for judgment
  4. Report output destination — Only in chat, or save to a file (obtain the user's explicit consent before saving.Security notesReference)

If you cannot ask the user (non-interactive execution,AskUserQuestion is unavailable, etc.), do not stop the audit. Fill in the following order, and list the filled-in contents at the beginning of the report as "Assumptions (unverified)":

Item How to fill in
Target site whoami の site（site_key / env / each URL).Do not guess
Verification category Read from the request text. If no limiting instructions, all categories
Site assumptions Adopt the description in the request text with the highest priority (e.g., "has members-only content"). If there are no clues,lean the judgment toward "Needs consideration" and clearly state the items whose conclusions change depending on the assumption. Do not guess assumptions and definitively conclude "Action required"
Report output destination Chat output only.Do not save to a file without consent

Step 1.5: whoami to determine the connection context

The first tool to call is whoami。 with no arguments, and in a single call it can fill multiple checklist categories as primary information.

whoami 's return When to use
site（site_id / site_key / env / site_url / api_url / mng_url / edge_url） Detecting mix-ups of the target site. Determining the "target site" in Step 1. Judging front-end and API domain matching (validity of Cookie authentication)
security.ip_restrictions The IP address restriction category is determined here. management(admin screen) / admin_mcp(Admin MCP dedicated list) / files(KurocoFiles allowlist/denylist) each enabled / mode / current_ip_allowed / rules
member.super_flg / member.groups Starting point for inventorying superuser privileges (including whetherthe executor themselvesfalls under this)
permissions.granted / denied / approval_required Privileges of the execution account. Use as evidence for distinguishing what could and could not be obtained
permissions.connection.scope / readonly The nature of the connection used for the audit. Write it in the "Connection used" field of the report
request.client_ip The connection source used for IP restriction judgment

security.ip_restrictions の rules(the settings content itself) is returned only for connections that can update site settings. If it is not returned, report up to enabled as fact, andrules goes to "Manual verification".

Step 2: Understand the available read tools

Check the list of tools already obtained by the MCP client at connection time.Do not use routes other than MCP tools (REST calls via curl, browser operations on the admin screen, shell) — because this bypasses MCP permissions, approvals, and audit logs. Put items that cannot be reached with the visible tools into "Manual verification" in Step 4.

Map each category of the checklist totool names that actually existin the list.

  • Do not guess tool names and call them. The name shown in the list is authoritative
  • For items where no corresponding read tool is found, do not give up right there; in Step 4treat them as manual confirmation items(the checklist lists the location on the admin screen)
  • Because of the specification that read-type tools are excluded from the list for modules with zero records, "no tool exists" does not mean "the setting does not exist"

Step 3: Collecting setting values

  • Use only read-type tools.create / update / delete / bulk_* are never called in this skill
  • For independent reads, multiple tool calls may be issued simultaneously and executed in parallel
  • For list retrieval, limit the count with cnt . If you only want to know the count, make cnt small and look at pageInfo.totalCnt .cnt / columns Some tools do not have this, so check with inputSchema before calling
  • Base your judgment only on theactual field names and actual valuesof the response you were able to obtain. Do not assert that items whose values could not be obtained are "configured" or "not configured"
  • Do not reinterpret the absence of a key in the response as "disabled" or "not configured". When determining a boolean setting, confirm that it isfalse / 0 がexplicitly returned. If the key itself is absent, it could not be obtained (= manual confirmation)
  • A7 (unused API/endpoint) is determined not by setting values but by usage records. api-list → api_uri-list(last 8 days), for a longer window use api_analytics-list（→ checklist の A7 corroboration）
  • When something cannot be obtained for any reason, do not silently drop check items. Whatever the reason — the response is too large to read, the tool is not visible, no value is returned — list the items that could not be confirmed because of it under **"manual confirmation" and write the reason**. Hiding reduced coverage makes the audit results look safer than they actually are

Step 4: Judgment using the checklist

references/checklist.md For each item in, classify it as one of the following:

Judgment Meaning
Action required The setting value was confirmed and there is a problem in light of the site premises asked about in Step 1
Needs consideration The setting value was confirmed, but its appropriateness depends on operational policy (present with supporting information for judgment)
No problem The setting value was confirmed and follows the recommendation
Manual confirmation The setting value could not be obtained from MCP. Guide the user through the confirmation procedure on the admin screen

Use the checklist default as the starting point for severity, andadjust it based on the site premises(Example: On a fully public media site, "API security = none" defaults to HIGH, but if it can be confirmed that the API is dedicated to public data, it may be lowered to "no issue"). If adjusted, write the reason in the report.

Step 5: Report

references/report-format.md Report in the format. At minimum, include the following.

  • Target site, date and time of execution, scope, connection used (/readonly or not)
  • List of findings in order of severity (current value, recommended value, source tool used as evidence, remediation policy)
  • List of items requiring manual confirmation(do not hide what could not be obtained)
  • Explicit statement that no configuration changes were made

Important rules

Rules Explanation
Read-only Do not call write tools during this skill's execution. If a fix request is received, /kuroco-admin-mcp switch to and obtain pre-execution confirmation again
Do not fill in with guesses Configuration values that could not be obtained are "manual confirmation." Do not assume default values and write "no issue"
Judge based on the site's premises Appropriate settings vary by use case. Do not uniformly declare something "dangerous" without asking about the premises
Do not output secrets Tokens, secrets, and passwordsDo not write actual values in the report at all(only existence, count, expiration date, update date and time)
Count limit For list retrieval, specify cnt . Do not dump all records
Cost awareness Do not retrieve the same information redundantly.However, do not omit check items or re-audits for cost reasons—comprehensiveness takes priority
Do not misrepresent comprehensiveness State in the report that the checklist covers known configuration items, and that site-specific implementation risks (pre/post processing, custom functions, batch jobs) are out of scope

Error handling

Connection and authentication issues (400 / 401 / 403 / tool rejection) causes and handling are the same as /kuroco-admin-mcp 's error handling section. Skill-specific handling is as follows.

Symptom Handling
Only some modules' tools are not visible Possible insufficient scope. List the module names needed for the audit and/x/all/readonly propose re-registration with .Leave invisible items as "manual confirmation" and continue the audit
Authentication expires during the audit Stop immediately and report up to which category has been collected. After reauthorization, resume from uncollected categories (do not re-read already collected data = cost reduction)
A specific list is empty due to insufficient permissions It may not be possible to distinguish between "0 records" and "not visible due to permissions." When it cannot be distinguished, do not make a definitive statement; report the facts along with the executing user's permissions
Log-related tools list / pageInfo do not return every key Do not read this as "0 items." A legitimate 0-item result is returned in the form {"list": [], "pageInfo": {...}} .list Treat a response with no key at all as a failure to retrieve, and route it to "manual confirmation"

Security notes

  • Do not display, log, or save to file the actual values of tokens, secrets, or passwords. Even when retrieving a list of static access tokens or auto-login tokens, limit reporting to the count, expiration date, and creation date/time
  • Save report files only after obtaining the user's explicit consent. Security audit results are themselves a list of "where the weaknesses are," and the impact of a leak is significant. If they contain personal information such as member data or IP addresses, present the scope of what will be saved and confirm
  • Keep retrieval of member lists and login histories to the minimum necessary. What is usually needed for a privilege inventory is "user type," "enabled/disabled," and "affiliated group"; there is no need to retrieve personal information columns
    • columns Omitting this returns all columns. Member-related and login-history-related tools return data including names and email addresses. Once retrieved, the fact of retrieval remains even if it is not written in the report, so call it after specifyingcolumns after specifying(Example: member-list then member_id / group_ids / login_ok_flg）
    • columns If you do not know which names can be specified infirst pass one nonexistent name to trigger an error, and obtain valid column names from the returned message. Do not retrieve personal information and then narrow it down; narrow it down first and then retrieve
  • The audit itself is recorded in the administrative operation log. In shared environments, recommend that the user notify the team before conducting it

Anti-patterns

Common pitfalls Problem Recommendation
Fix settings while doing the audit Changes without approval. This also undermines audit independence This skill stops at reporting. Fixes are done in /kuroco-admin-mcp with separate approval
Omit items that could not be obtained Unconfirmed items appear as "no problems," making the audit results look safer than reality Explicitly list them as "manual confirmation"
Judge based on default values False reporting that diverges from the actual settings Base judgments only on actual values that could be obtained
Apply uniform judgments without asking about the site's assumptions Applying membership-site criteria to public media sites produces false positives en masse Confirm the purpose in Step 1 before judging
Paste token values into the report The audit report becomes a leak path Do not write actual values
cnt Retrieve all members without Response bloat / unnecessary collection of personal information cnt limit withpageInfo.totalCnt and check the count with
Concluding "unused API" based only on the name or zero usage This leads to a proposal to disable an API that is in operation (accompanied by deletion of issued tokens). Monthly batches and routes used only during failures do not appear in the window Corroborate with actual usage records, and present it as "needs consideration" along with the length of the window you checked
Concluding with "there are no security issues" This amounts to guaranteeing risks outside the checklist (custom processing / operations) Explicitly state the scope, e.g. "within the scope of this checklist"

Cooperation with other skills

Skills Purpose How to use them differently
/kuroco-admin-mcp Admin MCP connection, authentication, tool discovery, andmodification of settings A prerequisite for this skill. Use this when actually fixing the points raised
/kuroco-api-content API authentication method (Cookie/Token/StaticToken) and CORS design Design decisions on "how it should be fixed"
/kuroco-docs Official documentation for each setting item When attaching the source URL for a point raised
/kuroco-frontend-integration KurocoFront Basic authentication and deployment settings Handling points raised on the frontend side