Plan: Automated AI Incident Blog & LinkedIn Pipeline

Date: 2026-03-09 Status: Ready for review — not yet assigned Origin: Signal validation research validated signal volume; this plan defines the implementation.

1. What This Is

A weekly automated pipeline that:

Gathers AI security incident signals from public sources (RSS, CVE/NVD API, AI Incident Database)
Scores and filters them for relevance using Claude
Generates a blog post (~900 words) framed through the SecurityV0 authority path lens
Generates a LinkedIn post (~180 words) for the same incident
Opens a PR to sv0-website for human review and approval
Auto-publishes to securityv0.com/blog on merge

Human touch per week: ~20 minutes (read draft, edit if needed, merge PR).

This is content, not a product. No SV0 platform changes required. Pure content marketing that builds the SV0 vocabulary and positions the team as the authority on AI execution risk.

2. Repository Decision: `sv0-intelligence` (New Repo)

Recommendation: separate repository

Do NOT add the pipeline to sv0-website. The two repos have different natures:

Concern	sv0-website	sv0-intelligence
What it contains	Astro pages, Tailwind UI, design assets	Python scripts, Claude API calls, cron workflows
Who changes it	Designer/frontend developer	Bot, backend developer
Change cadence	Occasional redesigns	Weekly automated runs
Who reviews PRs	Design/product	Content/product

sv0-intelligence is the right home for all future automated research: weekly incidents, CVE monitor, competitive intel digest, LinkedIn-only posts. Each researcher is a self-contained module. The repo feeds content PRs to sv0-website — clean interface, clean separation.

Repository: `SecurityV0/sv0-intelligence`

sv0-intelligence/
├── researchers/
│   ├── weekly-incident/          ← Phase 1 (this plan)
│   │   ├── gather.py             # Signal collection
│   │   ├── score.py              # Claude scoring
│   │   ├── generate.py           # Blog + LinkedIn post generation
│   │   ├── publish.py            # Open PR to sv0-website
│   │   ├── prompts/
│   │   │   ├── score.txt
│   │   │   ├── blog_post.txt
│   │   │   └── linkedin.txt
│   │   └── tests/
│   ├── cve-monitor/              ← Future Phase 3
│   └── competitive-intel/        ← Future Phase 4
├── shared/
│   ├── claude_client.py          # Claude API wrapper (reused by all researchers)
│   ├── signal_store.py           # SQLite deduplication store
│   └── github_pr.py              # PR creation helper
├── store/
│   └── signals.db                # SQLite (gitignored — persists in Actions cache)
├── .github/
│   └── workflows/
│       ├── weekly-incident.yml   # Cron: Monday 08:00 UTC
│       └── manual-trigger.yml    # workflow_dispatch for testing
├── pyproject.toml
├── requirements.txt
└── README.md

3. sv0-website Changes Required

The website is Astro (static, Tailwind CSS, deployed to Cloudflare Pages at securityv0.com). Currently it has a homepage only — no blog section. A blog section must be added.

3a. Add Astro Content Collections (blog)

Astro's built-in Content Collections handle markdown blog posts natively. Required changes to sv0-website:

sv0-website/src/
├── content/
│   ├── config.ts                 # Define blog collection schema
│   └── blog/                     # Blog post .md files live here
│       └── .gitkeep
├── pages/
│   ├── index.astro               # Existing homepage
│   ├── blog/
│   │   ├── index.astro           # Blog listing page
│   │   └── [...slug].astro       # Individual post page
└── layouts/
    ├── BaseLayout.astro           # Existing
    └── BlogPostLayout.astro       # New: wraps blog post content

Blog post frontmatter schema (content/config.ts):

import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    date: z.coerce.date(),
    description: z.string(),
    incident_type: z.string(),           // e.g. "Scope Drift", "MCP Poisoning"
    owasp_category: z.string().optional(), // e.g. "ASI03"
    sv0_finding: z.string().optional(),   // e.g. "scope_drift"
    tags: z.array(z.string()),
    draft: z.boolean().default(false),
  }),
});

export const collections = { blog };

Effort: 1 Claude Code session (Astro blog infrastructure — listing page, post template, routing, basic styling consistent with existing site).

3b. Blog post URL structure

securityv0.com/blog/                              ← listing, latest 10 posts
securityv0.com/blog/2026-03-10-mcp-tool-poisoning ← individual post

4. Pipeline: Weekly Incident Researcher

4a. Signal Sources (no authentication required)

Source	What It Provides	API / Access
AI Incident Database	Structured incident reports, severity, affected systems	REST API, public
CVE/NVD API v2	AI/ML framework CVEs (filtered by keyword)	REST API, public, no key
Simon Willison RSS	Prompt injection, MCP research, incident analysis	RSS feed
Trail of Bits blog RSS	Deep agent security audits	RSS feed
Invariant Labs blog RSS	MCP tool poisoning, agent security	RSS feed
PointGuard AI RSS	Monthly AI security incident roundups	RSS feed
NIST NVD AI keyword search	Vulnerability disclosures touching AI frameworks	NVD API
Hacker News Algolia API	"ai agent security", "mcp vulnerability" hits	REST API, public

All public. No GitHub admin access required (that's W2/W3 scope for customer repos).

4b. Scoring — Claude evaluates each signal

Each signal gets three scores 1–5. Only signals with all three ≥ 4 proceed:

Dimension	What It Measures
AI relevance	Is this about an AI agent, LLM workflow, or MCP server — not generic software CVE?
Authority relevance	Does it involve execution authority, scope drift, identity, egress, or ownership?
Post-worthiness	Is it specific enough, recent enough, and credible enough for a CISO audience?

Claude is given the full signal text + the three scoring criteria + examples of passing/failing signals. Output is structured JSON.

4c. Content Generation — Claude writes the post

Blog post structure (~900 words):

## The Incident
[2-3 paragraphs: what happened, who was affected, what was the attack vector]

## The Authority Path That Failed
[2 paragraphs: which identity carried the authority, what scope existed vs what was exercised,
 where ownership was missing]

## SecurityV0 Perspective
[1-2 paragraphs: which SV0 finding type maps to this class of failure,
 what a customer with SV0 deployed would have seen, framed as evidence not marketing]

## What To Do
[3-4 bullet points: concrete mitigations for a CISO reader]

## Sources
[Linked citations]

The "SecurityV0 Perspective" section uses the OWASP → SV0 finding type mapping table from the research document. It names a specific finding type (e.g. scope_drift, orphaned_ownership), describes what the evidence pack would show, and links to the relevant OWASP category.

LinkedIn post (~180 words):

Hook: the specific scary number or failure from the incident
What actually happened (one sentence)
The authority path angle (one sentence)
The SV0 insight (one sentence — not a product pitch, a framing)
CTA: link to full post

4d. Output — PR to sv0-website

The pipeline creates a file:

sv0-website/src/content/blog/YYYY-MM-DD-[slug].md

And opens a PR with:

Title: content: weekly AI incident post — [incident name]
Body: summary of the incident, scores, LinkedIn draft (in a collapsed section), and a link to sources
Labels: content, weekly-incident
Assignee: Sergey (or whoever owns content review)

The LinkedIn draft is included in the PR body as a collapsed <details> block — easy to copy-paste to LinkedIn after the blog post is live.

5. Deduplication

Signals are stored in a local SQLite database (store/signals.db) with:

URL/ID of each signal processed
Date processed
Score received
Whether it was used for a post

Before scoring, each new signal is checked against the last 60 days. Prevents the same incident from being re-surfaced across weeks.

The SQLite file is persisted across GitHub Actions runs using actions/cache keyed on signals-db-{week}.

6. Implementation Phases

Phase 1 — Core Pipeline (Sessions 1-5)

Session	What Gets Built	Deliverable
1	sv0-website blog infrastructure: Content Collections, blog listing page, post template, BaseLayout extension	Working `/blog` route on localhost; `sv0-website` PR
2	sv0-intelligence repo scaffold + signal gatherer: RSS + CVE/NVD + AI Incident DB, deduplication store	`gather.py` producing a scored digest locally
3	Claude scoring layer: structured output, 1-5 scores on 3 dimensions, filter logic	`score.py` producing filtered signal list
4	Blog post + LinkedIn generator: prompts, Claude API call, frontmatter generation	Draft blog post + LinkedIn copy for a real incident
5	PR automation + GitHub Actions cron: `publish.py`, `weekly-incident.yml` (Monday 08:00 UTC), end-to-end test	First automated PR in `sv0-website` from CI

End of Phase 1: Pipeline runs weekly, Sergey gets a PR every Monday with a draft post + LinkedIn copy. ~30 min review/week.

Phase 2 — Quality & SV0 Integration (Sessions 6-7)

Session	What Gets Built
6	Prompt tuning on 3-4 real incidents: calibrate voice, tighten "SecurityV0 Perspective" section, ensure finding type citations are accurate
7	SV0 finding cross-references in posts: each post links to the relevant OWASP Agentic Top 10 entry and names the SV0 finding type; "SecurityV0 Perspective" section becomes a consistent block format

End of Phase 2: Posts are consistently on-voice, SV0 integration is natural and non-promotional.

Phase 3 — CVE Monitor Researcher (Sessions 8-9)

A second researcher module: researchers/cve-monitor/. Monitors CVE/NVD for AI framework CVEs (LangChain, AutoGen, CrewAI, Ollama, MCP SDKs), generates shorter advisory-style posts when a high-severity CVE is filed. Separate GitHub Actions trigger (daily instead of weekly).

Phase 4 — Competitive Intel Digest (Sessions 10-11)

A third researcher: researchers/competitive-intel/. Monitors Zenity, Entro, Noma, Wiz AI-SPM for product announcements, positioning changes, funding. Generates internal-only digest to sv0-documentation (not published publicly). Helps the team track competitor moves.

7. Effort Summary

Phase	Sessions	Outcome
Phase 1 (core pipeline)	5	Weekly posts running, PR automation live
Phase 2 (quality + SV0 integration)	2	Consistent voice, proper finding citations
Phase 3 (CVE monitor)	2	Second researcher live
Phase 4 (competitive intel)	2	Internal intel digest live
Total	11	Full intelligence platform

First usable blog post draft: end of Session 4. First automated PR: end of Session 5. Human review time per week: ~20-30 minutes.

8. What This Enables Over Time

Months 1-3: Establish the "AI execution authority" framing vocabulary. Each post says: others report that incidents happened; we explain exactly which authority path failed. CISO readers start associating SV0 with a specific, useful way of thinking about agent risk.

Months 3-6: Posts accumulate as a library. Sales can reference specific posts in prospect conversations: "we wrote about this class of problem in March — here's the finding type that would have caught it." LinkedIn posts drive awareness. Some posts may be picked up by security newsletters.

Month 6+: Retroactive linking — once W1 is in customers' hands, blog posts can be updated with "a customer using SecurityV0 saw this finding type surface before their breach occurred" (with permission). Real case studies emerge from the content property.

9. What This Does NOT Require

No GitHub admin access (public RSS/CVE/AI Incident DB only in Phase 1-2)
No database server (SQLite + GitHub Actions cache)
No CMS or headless CMS
No changes to sv0-platform or sv0-connectors
No new Cloudflare configuration (sv0-website already on Cloudflare Pages)
No ongoing maintenance — weekly cron is self-contained

One new secret added to sv0-intelligence GitHub repo settings:

ANTHROPIC_API_KEY — for Claude blog post generation

One existing secret referenced from sv0-website:

CLOUDFLARE_API_TOKEN / CLOUDFLARE_ACCOUNT_ID — already set, no change

10. Open Questions for Review

Voice and tone: Who reviews and approves the first 3-4 posts before we trust the automation? Sergey only, or also Ivan?
Byline: Posts are AI-generated but human-edited. What byline? "SecurityV0 Team"? A specific persona?
LinkedIn account: Which LinkedIn account posts? Company page or Sergey's personal profile? (The pipeline generates the copy; posting is always manual.)
Posting frequency: Weekly is the default. Could be bi-weekly to start while calibrating quality — lower volume, higher signal.
SV0 website launch timing: The blog section can be built and drafts queued before securityv0.com goes public. Do we hold posts until launch or publish immediately?
sv0-intelligence repo visibility: Private (like all other repos) or public? Public would mean the signal gathering code is visible, which is fine — it uses only public APIs.

11. Success Criteria

Weekly PR opens automatically every Monday by 09:00 UTC
Each PR contains a blog post draft + LinkedIn copy
Blog post scores ≥ 4/5 on relevance and voice (internal review rubric)
No duplicate incidents surfaced within a 60-day window
securityv0.com/blog renders correctly on Cloudflare Pages (Astro build passes)
Human review time ≤ 30 minutes per week

AI Exposure Incident Monitor Research — signal validation, source list, OWASP → SV0 finding type mapping
AI Exposure Incident Monitor Brief — original concept brief from Sergey
Product Vision — confirms this is thought leadership, not product scope

1. What This Is​

2. Repository Decision: sv0-intelligence (New Repo)​

Recommendation: separate repository​

Repository: SecurityV0/sv0-intelligence​

3. sv0-website Changes Required​

3a. Add Astro Content Collections (blog)​

3b. Blog post URL structure​

4. Pipeline: Weekly Incident Researcher​

4a. Signal Sources (no authentication required)​

4b. Scoring — Claude evaluates each signal​

4c. Content Generation — Claude writes the post​

4d. Output — PR to sv0-website​

5. Deduplication​

6. Implementation Phases​

Phase 1 — Core Pipeline (Sessions 1-5)​

Phase 2 — Quality & SV0 Integration (Sessions 6-7)​

Phase 3 — CVE Monitor Researcher (Sessions 8-9)​

Phase 4 — Competitive Intel Digest (Sessions 10-11)​

7. Effort Summary​

8. What This Enables Over Time​

9. What This Does NOT Require​

10. Open Questions for Review​

11. Success Criteria​

Related Documents​