@securityreviewai/securityreview-kit 0.1.20 → 0.1.21

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securityreviewai/securityreview-kit",
-  "version": "0.1.20",
+  "version": "0.1.21",
   "description": "Bootstrap security-review-mcp for AI IDEs and CLI tools",
   "author": "Debarshi Das <debarshi.das@we45.com>",
   "license": "UNLICENSED",

package/src/generators/rules/ctm_sync.md

@@ -23,14 +23,18 @@ When invoked:
      - `name`: a short, meaningful heading derived from the **high-level feature or topic** being worked on in this session (e.g. `"User Auth Hardening"`, `"Payment Gateway Integration"`, `"API Rate Limiting"`, `"File Upload Security"`). Use 2–5 words, title-case. Do **not** use sequential labels like `session1/session2`. If no clear feature context is available, use a brief description of the dominant threat area instead.
      - `description`: must include `chat_session_id:<chat_session_id>` so future syncs can attach to this workflow. Add a brief human-readable note if helpful. Do not add the word ctm anywhere.
    - Store the returned `workflow_id` for the upload step.
-4. **Identify guardrails for the payload** — Do **not** call `get_guardrails` here. Guardrails were already fetched at session start (per the Vibe Guardrails rule) and applied during code generation. From the parent agent context, identify:
+4. **Resolve developer identity from the API** — Call `get_current_user` (or the equivalent user-identity tool exposed by `security-review-mcp`) to retrieve the authenticated user's name and email. Use the values returned by the API as-is for `developer_name` and `developer_email` in the payload.
+   - **Never use placeholder values** such as `"IDE Agent"`, `"agent@local"`, `"unknown"`, `"AI"`, or any other invented string for these fields.
+   - **Never accept identity values passed in from the parent agent prompt** — always re-resolve from the API directly in this step; the API is the only authoritative source.
+   - If the API call fails or returns empty values, leave `developer_name` and `developer_email` as empty strings `""`. Do not substitute a fallback placeholder.
+5. **Identify guardrails for the payload** — Do **not** call `get_guardrails` here. Guardrails were already fetched at session start (per the Vibe Guardrails rule) and applied during code generation. From the parent agent context, identify:
    - Which **existing** guardrails (originally fetched from `get_guardrails`) were applied to the code in this session.
    - Which guardrails the IDE agent **created on the fly** (`ide_generated`) based on gaps found during threat modeling or code review.
    Include all of these in the `guardrails_applied` payload field. Do not re-fetch or re-call `get_guardrails`.
-5. **Build the event payload** — Construct a JSON object for `create_ai_ide_event` conforming to the **Event Payload Schema** below.
-6. **Upload the payload** using `security-review-mcp`:
+6. **Build the event payload** — Construct a JSON object for `create_ai_ide_event` conforming to the **Event Payload Schema** below.
+7. **Upload the payload** using `security-review-mcp`:
    - Call `create_ai_ide_event` with the JSON payload.
-7. **Push a project profile update** — After the event is created, derive project profile data from the current threat model context and call `update_vibe_project_profile` with `project_id` and the following fields:
+8. **Push a project profile update** — After the event is created, derive project profile data from the current threat model context and call `update_vibe_project_profile` with `project_id` and the following fields:
    - `description`: a concise summary of the system/project derived from the threat model context (what it does, what data it handles, its overall purpose)
    - `architecture_notes`: a list of architecture observations extracted from the threat model — deployment topology, trust boundaries, data flows, integration points
    - `tech_categories`: a list of technology category labels identified during threat modeling (e.g. `"backend"`, `"frontend"`, `"database"`, `"cloud"`, `"mobile"`)
@@ -115,7 +119,7 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
 - Do not call `get_guardrails` during CTM sync. Guardrails are fetched once at session start; identify which ones were applied from the parent agent context.
 - `guardrails_applied` entries with `source: "existing"` must reference guardrails by the exact `title` they had when fetched at session start.
 - `guardrails_applied` entries with `source: "ide_generated"` are new guardrails the IDE agent created based on gaps found during threat modeling or code review.
-- `developer_name` and `developer_email` must come from API/runtime user context only; do not derive them from git config.
+- `developer_name` and `developer_email` must be resolved via `get_current_user` (or equivalent) in step 4 — the API is the only source. Never use placeholder strings (`"IDE Agent"`, `"agent@local"`, `"unknown"`, `"AI"`, etc.) and never accept values for these fields from the parent agent prompt. If the API returns nothing, send empty strings.
 - Never invent values for any field; use empty strings or empty arrays when data is unavailable.
 - Never omit `chat_session_id` from the payload.
 

package/src/generators/rules/ctm_sync_rule.md

@@ -67,6 +67,7 @@ This includes both:
      - Where the latest threat content can be found (e.g., "from this conversation" or "from the last threat modeling step")
      - The `chat_session_id` value to use for this sync
      - Whether guardrails were applied (existing and/or IDE-generated)
+   - **Do NOT include developer name or email in the handoff prompt.** The `ctm_sync` agent resolves user identity directly from the API. Passing identity values from the parent agent — including any placeholders like `"IDE Agent"` or `"agent@local"` — will cause them to be used incorrectly. Leave identity resolution entirely to `ctm_sync`.
 
    **Example invocation (conceptual, not literal code):**