MySQL8 CRM Schema Design Expert

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 5:10 AM UTC
• Version: 1.0.0

Overview

This is a documentation-only CRM database design skill that is coherent with its purpose, though production users should carefully review privacy, tenant isolation, and seed-data examples before applying them.

Installers should treat this as a schema-design reference, not production-ready compliance advice. Before using its SQL in a real CRM, add privacy and retention requirements, protect meeting/recording URLs and message identifiers, ensure seed scripts cannot run in production, and strengthen multi-tenant schemas with database-enforced tenant consistency where applicable.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Error

• Location: references/security-and-multitenancy.md:173

Finding

Tenant Isolation Is Not Enforced by Database Foreign Keys

Content

View full analysis

Vulnerability Details

File Location: references/security-and-multitenancy.md, lines 173–175
Vulnerability Type: Cross-tenant referential-integrity weakness
Risk Level: High

markdown

4. **Foreign keys should stay within a tenant.** Add application-level checks to ensure cross-table references share the same `tenant_id`.

Technical Analysis

The shared-database multi-tenancy guidance relies on application-level checks to ensure that related records have the same tenant_id. Independent foreign keys referencing only an entity ID do not enforce this security invariant at the database layer.

For example, if a child table contains both tenant_id and account_id, but its foreign key references only accounts.id, MySQL can accept a child row belonging to tenant A whose account_id identifies an account belonging to tenant B. Application-level validation alone is vulnerable to omitted checks, defective import jobs, administrative scripts, compromised application paths, and direct database writes.

Tenant isolation is a security boundary and should therefore be enforced through composite database constraints rather than treated solely as application validation.

Attack Path

1. An attacker authenticates as a user of tenant A.
2. The attacker discovers or guesses an entity identifier belonging to tenant B, such as an account ID.
3. The attacker submits a create or update request that associates a tenant-A record with the tenant-B identifier.
4. The affected request handler, bulk import, integration, or administrative path omits the application-level tenant consistency check.
5. MySQL accepts the relationship because the foreign key validates only the entity ID and not the corresponding tenant_id.
6. Subsequent joins, reports, activity timelines, updates, or exports may disclose or manipulate data associated with tenant B.

Exploitation requires a write path that accepts a foreign identifier witho ...[truncated 1065 chars]

Remediation

View remediation

Remediation Suggestions

Enforce tenant consistency directly in the database:

1. Add a composite candidate key to every tenant-owned parent table:

   sql

   ALTER TABLE `accounts`
       ADD UNIQUE INDEX `uq_accounts_tenant_id_id` (`tenant_id`, `id`);
   

2. Replace single-column foreign keys with composite foreign keys that include tenant_id:

   sql

   ALTER TABLE `contacts`
       ADD CONSTRAINT `fk_contacts_tenant_account`
       FOREIGN KEY (`tenant_id`, `account_id`)
       REFERENCES `accounts` (`tenant_id`, `id`)
       ON DELETE SET NULL;
   

   If account_id is nullable and ON DELETE SET NULL is required, review whether both columns should be cleared; shared tenant_id generally must not be nulled. An alternative deletion policy or schema arrangement may therefore be necessary.

3. Include tenant_id in every tenant-owned junction table, polymorphic association, unique constraint, and relevant index.

4. Retain application-level authorization checks as defense in depth. Resolve the tenant from trusted authentication context rather than accepting it from request parameters.

5. Ensure background jobs, bulk imports, migrations, integrations, and administrative tools apply the same tenant restrictions.

6. Add negative integration tests proving that inserts and updates containing cross-tenant references are rejected by MySQL.

7. Audit existing data for mismatched tenant relationships before enabling composite constraints, then correct or quarantine inconsistent records.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Memory Poisoning: Persistent Context Injection, Context Window Stuffing, Memory Manipulation
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (5)

Memory Manipulation

High

• Category: Memory Poisoning
• Confidence: 80% confidence

Finding

Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.

Content

Scanner excerpt · SKILL.md (reported line 53)May include surrounding context.

md

4. **Every table gets an audit baseline.** At minimum: `id` (BIGINT UNSIGNED AUTO_INCREMENT), `created_at`, `updated_at`. Most CRM tables also need `created_by` and `updated_by`.

5. **Soft deletes over hard deletes.** CRM data has legal, compliance, and historical reporting value. Use `deleted_at` (TIMESTAMP NULL) rather than DELETE statements.

6. **Use BIGINT UNSIGNED for primary keys.** INT runs out at ~2.1 billion. CRM tables like activities and audit logs grow fast. BIGINT UNSIGNED gives you headroom through 18.4 quintillion.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 97% confidence

Finding

The trigger list is extremely broad and includes generic database-design phrases plus many CRM-adjacent entities, which can cause the skill to activate for requests that are only loosely related to CRM. Over-broad activation can misroute user queries, override a more appropriate skill, and increase the chance that sensitive customer-data design guidance is applied in the wrong context.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The document promotes comprehensive tracking of customer interactions across calls, emails, meetings, notes, tasks, and other touchpoints, but it does not include any guidance on data minimization, lawful basis, retention, access control, or consent-sensitive handling. In a CRM design skill, this omission can lead implementers to build broad surveillance-style data collection that exposes organizations to privacy violations, regulatory noncompliance, and insider misuse.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The examples encourage storage of sensitive communication metadata such as phone numbers, email addresses, attendees, message IDs, recording URLs, meeting URLs, and engagement telemetry without warning about access restrictions or secret-handling. If copied into production designs, these fields can expose personal data, live meeting links, and potentially bearer-style URLs or tracking data to unauthorized users, increasing privacy and account-compromise risk.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The guidance provides a stored procedure and direct INSERT/CALL statements for generating 10,000 records but does not explicitly restrict execution to development or test environments. In a database-design skill, users may copy and run these commands as-is; if executed against production, they could cause data pollution, storage growth, performance degradation, and misleading analytics.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.