security

Introducing Advisory: Automated Security Research That Actually Cites Its Sources

Security guidance with framework citations, not hallucinations. Meet /advisory—a skill that automates research BEFORE asking questions.

Chris Groves

Chris Groves

— 14 min read
Hero image for 2026-02-12-introducing-advisory

The Problem with Generic Security Advice

You ask an AI security tool: "How do I secure my API?"

The response comes back: "Use strong authentication. What technology are you using?"

You reply: "Django REST Framework."

"What version?"

"3.14"

"Have you considered JWT tokens and rate limiting?"

By the time you get specific, actionable advice, you've had five exchanges with a chatbot. And here's the real problem: none of it is cited. There's no framework reference. No CVE context. No evidence that this advice applies to your stack.

This is why generic AI security guidance frustrates practitioners. It lacks structure. It lacks sources. It lacks the informed context that comes from research.

What /advisory Changes

I'm introducing /advisory—a new skill in the Intelligence Adjacent framework that treats security guidance like professional consulting work, not chatbot responses.

Three things make it different:

  1. Automated research BEFORE questioning — It gathers CVE data and best practices before asking follow-up questions
  2. Framework-backed recommendations — Every suggestion maps to NIST CSF, OWASP, or CWE standards
  3. Professional deliverables — Structured reports you can share with teams, not conversation logs

Let me show you how this works.

Mode 1: Quick Security Guidance (/advisory)

Real example from a fintech startup I advised. They're building a payment processing API with Django REST Framework and PostgreSQL. Complication: they're also processing healthcare data (telemedicine payouts) for one customer vertical, which means they need both PCI-DSS 4.0.1 (payment data) AND HIPAA compliance (health data) in the same system.

Their question to me:

User: /advisory We have a Django REST Framework API using PostgreSQL.
We're handling payment card data (PCI-DSS scope) and healthcare data
(HIPAA scope) in the same system. Same customer tenant, both data types.
How do we architect this securely? Where should we start?

Here's what /advisory did with that single input:

Automated Phase 1 Research (30 seconds):

  • Detected: Django REST Framework + PostgreSQL + dual compliance (PCI + HIPAA)
  • NVD API query: Recent CVEs in Django 4.2.x, PostgreSQL 15.x, djangorestframework 3.14.x
  • WebSearch: "PCI-DSS 4.0.1 API requirements 2026", "HIPAA 2026 MFA mandatory", "PostgreSQL multi-tenant architecture PCI HIPAA"
  • Framework research: OWASP ASVS v4.0 (API controls), NIST CSF 2.0 (compliance posture), CIS Controls v8 (multi-tenant isolation)
  • Compliance mapping: PCI-DSS 4.0.1 sections 3, 6, 8; HIPAA Security Rule 164.312 (technical safeguards)

Structured Output with Framework Citations:

CRITICAL FINDINGS (Implement First):

1. ISOLATION ARCHITECTURE: PostgreSQL Row-Level Security (RLS) + Compliance Tagging
   Finding: Dual-compliance multi-tenant system requires isolation at database
   layer. Single application bug = PCI breach AND HIPAA breach simultaneously.

   Standards Mapping:
   - PCI-DSS 4.0.1 Req 3 (Protect Stored Card Data) + Req 6.2 (Secure Development)
   - HIPAA §164.312(a)(2)(ii) (Encryption and Decryption)
   - OWASP ASVS v4.0 4.2 (Access Control Enforcement)

   Implementation:
   ```sql
   CREATE TABLE customer_payments (
     id UUID PRIMARY KEY,
     customer_id UUID NOT NULL,
     compliance_scope TEXT CHECK (compliance_scope IN ('PCI_ONLY', 'HIPAA_ONLY', 'BOTH')),
     amount DECIMAL,
     card_data_encrypted BYTEA -- encrypted separately
   );

   ALTER TABLE customer_payments ENABLE ROW LEVEL SECURITY;
   CREATE POLICY pci_isolation ON customer_payments
     USING (current_setting('app.compliance_context') = compliance_scope::text);

Django middleware sets context before query execution.
Effort: 2 weeks (implementation + testing)

  1. MANDATORY MFA: HIPAA 2026 Final Rule (No Longer Addressable)
    Finding: As of 2026, HIPAA Security Rule requires MFA for all ePHI access.
    This is no longer a "should consider"—it's mandatory.Standards Mapping:For PCI scope: Requirement 8.3 (Multi-Factor Authentication)Implementation:Code example: DRF permission class checks user.profile.mfa_verified
    and request.compliance_scope before allowing ePHI access.
    Effort: 5-7 days
    • HIPAA §164.312(a)(2)(i) (Unique User Identification)
    • NIST SP 800-63-3 (Authentication and Lifecycle Management) - Level 3
    • OWASP ASVS v4.0 2.7 (Multi-Factor Verification)
    • Deploy FIDO2/WebAuthn (primary) per OWASP guidance
    • Fallback: TOTP via djangorestframework-simplejwt
    • Enforce MFA for HIPAA-scoped users, optional for PCI-only users
    • API returns 403 if user accessing HIPAA data without MFA
    • PCI-DSS 4.0.1 Req 3.5 (Protect Stored Card Data with Encryption)
    • HIPAA §164.312(a)(2)(ii) (Encryption and Decryption)
    • NIST SP 800-175B (Guideline for Using NIST Standards)
    • AWS RDS: Enable transparent data encryption (TDE) with customer-managed KMS
    • Key rotation: 90 days per HIPAA audit standards
    • AES-256 minimum
    • Sensitive columns encrypted via application layer BEFORE insert
  2. API AUTHENTICATION FRAMEWORK (Not Generic Token Auth)
    Finding: PCI-DSS 4.0.1 explicitly introduced API requirements for first time.
    Generic token auth isn't compliant—you need API key + mTLS + rate limiting.Standards Mapping:Implementation:Effort: 1 week
    • PCI-DSS 4.0.1 Req 8.2 (API Authentication for ALL API Access)
    • OWASP API Security Top 10 (2023) - API1 Broken Object Level Authorization
    • NIST CSF 2.0 Govern (GV-IM-02 - Establish API Security Requirements)
    • mTLS certificates for server-to-server API calls (payment processing service)
    • JWT tokens for user-to-API calls (with MFA token validation)
    • Rate limiting: 100 req/min per user (prevent automated attacks)
    • Request signing for sensitive operations

ENCRYPTION AT REST: Both Standards Require It (No Exceptions)
Finding: PCI-DSS 4.0.1 Req 3.5 + HIPAA §164.312(a)(2)(ii) both mandate
encryption of stored sensitive data. Your current setup (plaintext in DB)
is non-compliant immediately.Standards Mapping:Implementation:Python + cryptography library for field-level encryption:

from cryptography.fernet import Fernet
class PaymentSerializer(serializers.ModelSerializer):
  def create(self, validated_data):
    cipher = Fernet(settings.ENCRYPTION_KEY)
    validated_data['card_data'] = cipher.encrypt(validated_data['card_data'].encode())
    return super().create(validated_data)

Effort: 3 days (managed RDS service + application-layer wrapping)

COMPLIANCE AUDIT CHECKLIST:

PCI-DSS 4.0.1:

  • Req 3 (Protect Card Data): RLS + encryption at rest ✓
  • Req 6 (Secure Development): Code review + vulnerability scanning ✓
  • Req 8 (User Identification): MFA + API authentication ✓
    Total: 12 critical requirements, this covers top 3

HIPAA §164.312 Technical Safeguards:

  • 164.312(a)(1) (Access Control): RLS + MFA ✓
  • 164.312(a)(2)(i) (Unique User ID): Application-enforced + MFA ✓
  • 164.312(a)(2)(ii) (Emergency Access): Encryption key escrow + audit logs ✓
  • 164.312(b) (Audit Controls): CloudTrail logging + application logging ✓
    Total: 4 technical requirements, this covers all core ones

IMPLEMENTATION ROADMAP:

  • Week 1-2: RLS design + middleware implementation
  • Week 2-3: Encryption layer (field-level + TDE)
  • Week 3-4: MFA deployment (FIDO2 + TOTP)
  • Week 4-5: API authentication framework (mTLS + rate limiting)
  • Week 5-8: Testing, audit documentation, compliance review

DELIVERABLES GENERATED:

  • 21 prioritized findings (P0 critical, P1 high, P2 medium, P3 low)
  • 8-week phased implementation roadmap with dependencies
  • Code examples (Django middleware, SQLAlchemy RLS, encryption patterns)
  • Compliance mapping document (PCI + HIPAA to specific requirements)
  • 65+ framework citations (NIST, OWASP, PCI, HIPAA, CWE)
  • Audit checklist (controls to implement, testing procedures)

**What This Demonstrates:**

- **Not generic.** You got dual-compliance architecture patterns, not "use encryption." You got PostgreSQL RLS implementation details, Django middleware patterns, and specific crypto libraries. You got compliance mappings showing EXACTLY which PCI section and HIPAA paragraph applies.
- **Not five exchanges.** One question. Automated research found CVEs affecting your stack, detected your dual-compliance constraint, researched 2026 HIPAA rule changes, and generated informed recommendations. In traditional consulting, this is a 2-week intake process.
- **Auditable.** Every recommendation maps to a framework standard. PCI-DSS 4.0.1 Req 3.5. HIPAA §164.312(a)(2)(ii). OWASP ASVS v4.0 4.2. Your compliance team can validate alignment. Your auditors can trace the evidence chain.
- **Actionable.** You have implementation order (RLS first, encryption second, MFA third), effort estimates per task (2 weeks, 5-7 days, 3 days), code examples, and a phased 8-week roadmap with dependencies.

This is what informed security guidance looks like—not "Have you considered MFA?" but research-backed recommendations grounded in specific standards that apply to YOUR specific problem.

This is what informed security guidance looks like—not a chatbot asking questions, but research informing recommendations.

## Mode 2: Architecture Review (/arch-review)

Real engagement from a SaaS collaboration platform handling sensitive contractual and financial documents for enterprise B2B customers. Stack: React frontend, AWS API Gateway, Python FastAPI microservices, PostgreSQL, Redis, AWS S3. Target: SOC2 Type II compliance.

User: /arch-review
Context: React + FastAPI on AWS. API Gateway → microservices
(auth, documents, permissions). PostgreSQL for data. Redis for
sessions and caching. S3 for document storage. We need SOC2.


/advisory automated research phase (60 seconds):

- **Detected:** React, FastAPI, PostgreSQL 15.x, Redis, AWS API Gateway, S3
- **NVD Research:** Found CVEs affecting FastAPI dependencies; PostgreSQL TLS/encryption gaps
- **WebSearch:** "FastAPI inter-service authentication 2026", "PostgreSQL encryption at rest AWS RDS", "Redis security multi-tenant SaaS", "SOC2 Type II microservices requirements"
- **Compliance Mapping:** SOC2 Trust Services Criteria (CC1-CC9); required controls: authentication (CC6), encryption (CC6.1), monitoring (CC7), incident response (CC8)
- **Research Brief Generated:** Per-service vulnerability summary, multi-tenant isolation patterns, SOC2 control gaps

**Informed questions from research:**

I see your stack uses FastAPI microservices with Redis caching
and PostgreSQL on AWS. Compliance target: SOC2 Type II.

Research findings trigger specific questions:

  1. Inter-service communication: Do your FastAPI services
    authenticate each other, or does any service call any other
    service? (OAuth2/mTLS status?) This is critical for SOC2 CC6.
  2. Redis layer: Is Redis connection encrypted (TLS)? Are
    session tokens stored in plaintext? If unencrypted, a
    compromised EC2 instance can sniff tokens across the VPC.
  3. Database: PostgreSQL at rest encryption enabled with KMS?
    If not, stolen RDS snapshots expose all customer data.
  4. Audit logging: Are you logging all document access,
    permission changes, and authentication events to immutable
    storage (CloudWatch)? SOC2 requires 365-day audit retention.
  5. S3 security: Is Block Public Access enabled on all buckets?
    Are presigned URLs validated for permission changes?

I'll run STRIDE threat modeling across your services, map
findings to SOC2 controls, and prioritize remediation.


**What the full review produced (24 STRIDE threats identified):**

**Critical P0 Findings (Immediate Remediation Required):**

1. **T-006: Inter-Service Authentication Missing**
   - FastAPI services don't authenticate each other
   - Compromised service can invoke any other service, escalate privileges
   - Maps to SOC2 CC6 (Logical Access Control)
   - Fix: Implement OAuth2 between services (Effort: 2 weeks)

2. **T-012: Redis Unencrypted (Session Tokens Exposed)**
   - Session tokens stored plaintext in Redis, traffic unencrypted
   - Network sniffing in VPC captures tokens → account takeover
   - Maps to SOC2 CC6.1 (Encryption of Data in Transit)
   - Fix: Enable Redis TLS 1.2+, ACL authentication (Effort: 1 week)

3. **T-016: Database Unencrypted at Rest**
   - PostgreSQL data files on EBS unencrypted
   - Stolen snapshots or backups expose all customer data
   - Maps to SOC2 CC6.1 (Encryption of Data at Rest)
   - Fix: Enable RDS encryption with customer-managed KMS keys, key rotation 90 days (Effort: 3 days)

4. **T-014: Insufficient Audit Logging**
   - No comprehensive audit trail of document access, permission changes
   - Cannot demonstrate SOC2 CC7 (System Monitoring) or CC8 (Incident Response)
   - Fix: CloudWatch Logs with immutable storage, 365-day retention, event logging (Effort: 1 week)

5. **T-001: JWT Token Validation Gaps**
   - API Gateway doesn't validate token age, signature structure, issuer
   - Forged tokens possible; expired tokens accepted
   - Maps to SOC2 CC6 (Access Control)
   - Fix: Implement asymmetric JWT (RS256), claim validation, 1-hour max age (Effort: 5 days)

6. **T-021: S3 Public Access Not Blocked**
   - Block Public Access policy not enforced
   - Misconfigured bucket policy exposes customer documents
   - Maps to SOC2 CC6 (Access Control)
   - Fix: Enable Block Public Access on all buckets, enforce KMS encryption (Effort: 2 days)

7. **T-015: Database Credentials Not Managed**
   - DB credentials likely in environment variables or hardcoded
   - Credential compromise grants full database access
   - Maps to SOC2 CC6 (Logical Access Control)
   - Fix: AWS Secrets Manager with automatic rotation (30 days), audit via CloudTrail (Effort: 3 days)

**High-Priority P1 Findings (10 additional items):**
- XSS protection (JWT theft via JavaScript)
- SQL injection in document queries
- Path traversal in document operations
- XXE attacks in document preview
- Cache poisoning via stale permissions
- API rate limiting per user
- Audit log integrity and tamper protection
- Database account privilege escalation
- S3 presigned URL validation
- Compliance monitoring automation

**Remediation Timeline:**

- **Weeks 1-2 (P0 Critical):** 80-100 hours
  - All 7 critical items must be fixed before production
  - Team of 3-4 engineers required
  - No architectural redesign needed; primarily AWS service configuration

- **Weeks 3-4 (P1 High):** 60-80 hours
  - 10 additional findings resolved
  - Deployment and testing

- **Q2 (P2 Medium):** 40-60 hours
  - Service mesh, advanced key management, distributed tracing

**SOC2 Readiness:**
After P0 + P1 remediation, platform achieves compliance with SOC2 Trust Services Criteria (CC1-CC9). Estimated path to full certification: 6 weeks post-remediation including evidence gathering.

**Deliverables Generated:**
- Executive summary with findings overview
- Complete STRIDE threat model (24 threats across 7 categories)
- Prioritized recommendations (REC-001 through REC-007 critical items)
- SOC2 control mapping document
- Per-service architecture analysis with trust boundaries
- Implementation roadmap with dependencies
- Effort estimates for each finding
- 50+ framework citations (NIST CSF 2.0, OWASP Top 10, CIS AWS Benchmarks, SOC2 Trust Services)

## Mode 3: Code Review (/code-review)

Real engagement: Django REST Framework payment processing API handling user authentication and payment transactions. ~180 lines of Python code across 5 modules.

User: /code-review /path/to/payment-api


/advisory automated research phase (45 seconds):

- **Language Detection:** Python 3.x, Django 4.x, Django REST Framework 3.14
- **Framework Analysis:** Loads Python security patterns, OWASP Top 10 checklist, CWE Top 25 mapping
- **NVD Lookup:** Scans for Django 4.x and DRF 3.14 known vulnerabilities
- **Security Patterns:** Identifies authentication (JWT), payment processing, input validation areas
- **Research Brief:** Django/DRF-specific CVE data, secure coding patterns, compliance context (PCI-DSS for payment handling)

**Code review findings (9 total: 2 critical, 3 high, 2 medium, 2 low):**

**CRITICAL P0 (Emergency Remediation):**

**Finding 1: Hardcoded JWT Secret Key**
- **CWE:** CWE-798 (Use of Hard-Coded Cryptographic Key)
- **OWASP:** A02:2021 - Cryptographic Failures
- **Location:** `payments_api/settings.py`, lines 127-130
- **Issue:** JWT secret hardcoded in settings file; anyone with code access can forge authentication tokens
- **Code:**
```python
# VULNERABLE
JWT_AUTH = {
    'JWT_SECRET_KEY': 'your-super-secret-key-hardcoded-in-settings',
    'JWT_ALGORITHM': 'HS256',
}
  • Impact: Complete authentication bypass. Attacker can forge admin tokens, impersonate any user, process unauthorized payments, financial fraud
  • Fix: Migrate secret to environment variables via Django settings loader
  • Effort: 2-3 hours

Finding 2: SQL Injection in Payment Processing

  • CWE: CWE-89 (SQL Injection)
  • OWASP: A03:2021 - Injection
  • Location: payments_api/views/payment.py, lines 45-52
  • Issue: User input directly concatenated into raw SQL query without parameterization
  • Code:
# VULNERABLE
def process_payment(request):
    user_id = request.data.get('user_id')
    amount = request.data.get('amount')
    # Direct string concatenation—no escaping
    query = f"UPDATE users SET balance = balance - {amount} WHERE user_id = {user_id}"
    cursor = connection.cursor()
    cursor.execute(query)
  • Attack Example:
POST /api/process_payment/
{
  "user_id": "1 OR 1=1",
  "amount": "0.01"
}
# Resulting query updates ALL users' balances, not just user_id = 1
  • Impact: Complete database compromise. Attacker can read all user data (passwords, credit cards, PII), modify payment records, transfer balances between accounts, create fake transactions
  • PCI-DSS Violation: Requirement 6.5.1 (Injection prevention)
  • Fix: Replace with Django ORM (parameterized queries) or prepared statements
  • Effort: 4-8 hours

HIGH P1 (This Sprint):

Finding 3: Missing CSRF Protection

  • CWE: CWE-352 (Cross-Site Request Forgery)
  • OWASP: A01:2021 - Broken Access Control
  • Issue: State-changing endpoints lack CSRF token validation
  • Impact: Attackers can perform unauthorized actions on behalf of authenticated users
  • Fix: Enable DRF CSRF middleware; validate tokens on POST/PUT/DELETE
  • Effort: 3-4 hours

Finding 4: Weak Password Reset Tokens

  • CWE: CWE-640 (Weak Password Recovery Mechanism)
  • OWASP: A07:2021 - Authentication Failures
  • Issue: Reset tokens don't expire, can be reused indefinitely
  • Impact: Account takeover via token reuse
  • Fix: Implement single-use, time-limited tokens (15-minute TTL)
  • Effort: 4-6 hours

Finding 5: Insufficient Input Validation

  • CWE: CWE-20 (Improper Input Validation)
  • OWASP: A03:2021 - Injection
  • Issue: Numeric fields accept any input (negative amounts, overflow)
  • Impact: Negative balance transactions; financial data manipulation
  • Fix: Add DRF serializer validators with type checking and range validation
  • Effort: 2-3 hours

MEDIUM P2 (2-4 Weeks):

Finding 6: Generic Error Responses

  • Issue: Error messages leak system internals, SQL details
  • Fix: Implement custom error handlers with sanitized messages
  • Effort: 2-3 hours

Finding 7: Plaintext Payment Data Storage

  • CWE: CWE-327 (Use of Broken Cryptography)
  • OWASP: A02:2021 - Cryptographic Failures
  • PCI-DSS: Violation of Requirement 3.2.1 (Payment data encryption)
  • Issue: Credit card data stored plaintext in database
  • Fix: Implement field-level encryption; use PCI-compliant tokenization
  • Effort: 6-8 hours

LOW P3 (Backlog):

  • Finding 8: DEBUG=True in production
  • Finding 9: Missing authentication on admin endpoints

Compliance Impact:

  • PCI-DSS Non-Compliance: Findings 2 and 7 violate requirements; loss of payment processing capability possible
  • OWASP ASVS v4.0: Multiple failures in authentication (V2), access control (V4), injection (V5)

Remediation Timeline:

Phase Findings Effort Timeline
CRITICAL (P0) 1, 2 6-11 hours THIS WEEK
HIGH (P1) 3, 4, 5 11-15 hours THIS SPRINT
MEDIUM (P2) 6, 7 10-14 hours 2-4 WEEKS
LOW (P3) 8, 9 1 hour BACKLOG

Total Effort: 28-43 hours

Deliverables Generated:

  • Executive summary with risk assessment
  • 9 detailed findings with code snippets and attack scenarios
  • Remediation guide with step-by-step code examples
  • PCI-DSS and OWASP ASVS compliance mapping
  • Immediate action items with ownership assignment
  • Retest procedures to validate fixes
  • 30+ framework citations (CWE Top 25, OWASP Top 10 2021, PCI-DSS, NIST CSF 2.0)

The Innovation: Automated Research in Phase 1 Step 2b

All three modes share a common secret: research happens BEFORE questions.

In the advisory workflow, there are 5 phases: INTAKE → ANALYZE → RECOMMEND → DOCUMENT → DELIVER.

Phase 1 (INTAKE) has a crucial step: Step 2b (Automated Research).

This step:

  1. Detects technology keywords from your input
  2. Runs NVD API queries for relevant CVEs
  3. WebSearches for current best practices
  4. Generates a research brief with findings
  5. Uses research to inform follow-up questions

For code review, it goes deeper:

  1. Scans your codebase with language detection
  2. Identifies programming language and frameworks
  3. Loads language-specific security patterns
  4. Runs NVD lookups for those frameworks
  5. Creates targeted scan checklist from CVE data

This automation collapses what would normally take hours of manual reconnaissance into seconds. You get informed questions instead of generic fishing.

Why This Matters

Security consulting normally works like this:

  1. Client describes problem (vague)
  2. Consultant asks 20 questions to gather context
  3. Consultant researches tech stack (hours)
  4. Consultant finally starts analysis
  5. Client waits days for report

With /advisory:

  1. Client describes problem
  2. Skill auto-researches context (seconds)
  3. Skill asks 1-2 informed questions
  4. Analysis begins immediately
  5. Structured report produced

For security teams, this 10X's intake efficiency. For solo practitioners, this gives you consultant-level reconnaissance capability in a framework you deploy yourself.

Framework Positioning

All recommendations in /advisory tie to established frameworks. Not opinions. Not best practices without evidence.

NIST CSF 2.0, OWASP Top 10, CIS Controls, CWE Top 25—these frameworks aren't optional decoration. They're how professional security work gets documented, audited, and tracked.

When /advisory recommends something, you get:

Implement MFA per NIST CSF 2.0 PR.AA-01, using FIDO2/WebAuthn
per OWASP ASVS v4.0 control 2.7.1, with fallback SMS
authentication per NIST SP 800-63-3 Appendix A

Not just "use MFA." But "here's which framework says this, which control applies, which standard specifies how."

This makes findings auditable. You can trace every recommendation back to a framework. Your compliance team can validate alignment. Your engineers can look up full guidance for each control.

How to Use It

Three commands:

For quick questions:

/advisory What authentication should we use for our REST API?

For architecture review:

/arch-review
[Paste your system design or answer intake questions]
[Generates STRIDE threat model with NIST mapping]

For code security analysis:

/code-review /path/to/your/codebase
[Language detection + framework analysis + findings]

The skill routes effort levels automatically:

  • QUICK: Single question, direct answer (seconds)
  • STANDARD: Guidance with research and recommendations (minutes)
  • THOROUGH: Full threat model or code review with structured deliverables (hours)

Where This Fits in Your Workflow

/advisory isn't a replacement for penetration testing or automated vulnerability scanning. It's strategic security guidance.

Use /advisory when:

  • You need threat modeling before building
  • You want code review guidance before shipping
  • You need security questions answered with framework context
  • You're designing architecture and want threat analysis
  • You need professional documentation for stakeholders

Don't use /advisory when:

  • You need active penetration testing (/pentest instead)
  • You need automated vulnerability scanning (/vuln-scan instead)
  • You're in incident response mode (different skill)

The Intelligence Adjacent Philosophy

The framework's mission is to democratize expertise through deployable frameworks. Not consulting services. Not gatekeepers. Frameworks you deploy yourself.

/advisory embodies this. What normally requires hiring a security consultant—informed intake, threat modeling, code review with framework citations—is now a slash command.

You get:

  • Consultant-level reconnaissance (automated research)
  • Professional-grade documentation (structured reports)
  • Framework-backed recommendations (NIST, OWASP, CWE)
  • Enterprise capabilities (delivered as code you control)

Deploy it yourself. Run it in your environment. Own the output.

Ready to Level Up Your Security Guidance?

Security advice without citations isn't actionable. /advisory changes that by making research and framework alignment automatic.

→ Try /advisory for quick security questions
→ Use /arch-review for threat modeling with STRIDE/PASTA
→ Run /code-review for OWASP-guided code analysis

All three share the same research backbone. All produce framework-backed findings. All run locally as part of the Intelligence Adjacent framework you deploy yourself.

Sources

Security Advisory & Threat Modeling Frameworks

Code Review Standards & OWASP

Security Frameworks & Standards

Technical & Professional Standards

Read more