# Why I Rejected an 817-Skill Security Pack and Wrote a 2-File Threat-Model Skill

Author: Maksym Tytarenko | Date: 2026-08-06 | Category: AI & ML | Tags: ai-agents, security, threat-modeling, claude-code, automation
Canonical: https://www.tytarenkoagency.com/blog/why-i-rejected-an-817-skill-security-pack-and-wrote-a-2-file-threat-model-skill

> Someone shared a repository of 817 ready-made cybersecurity skills for coding agents. Instead of installing it, I read it, found it thin exactly where my products live, and wrote my own two-file threat-model skill around the one idea no checklist covers: abuse economics — how a product's own logic pays an attacker.

Last week someone shared a repository of 817 ready-made cybersecurity skills for coding agents. My first instinct was the obvious one: install it, instantly upgrade my agent fleet's security game. Instead I spent an evening actually reading what those 817 skills do — and then wrote my own skill. It is two markdown files.

## Why 817 skills were the wrong 817

The repo wasn't bad. It was mis-aimed. The bulk of it covers SOC work, forensics, incident response — jobs I don't do and my agents don't do. And it was thin exactly where my products live: web and API abuse, bot farms, prompt injection into agent pipelines.

That's the trap with mega-packs of agent skills: coverage looks like capability. But an agent doesn't need a skill for every discipline of security. It needs depth in the one place generic checklists structurally fail.

That place is **abuse economics** — the ways a product's own business logic pays an attacker or burns its own users. No checklist finds it, because it isn't a property of TLS configs or dependency versions. It's a property of *your* referral bonus, *your* reward grant, *your* free-credit faucet.

![An infographic showing how abuse economics impacts cybersecurity.](https://adltqzpaelnsrebtkzfj.supabase.co/storage/v1/object/public/blog-images/ai-generated/uploads/20260806_044501_0a8f603b.png)


## The two-sentence core of the skill

The skill I wrote is built around one principle and its mirror image:

![A diagram depicting the client as both attacker and victim in cybersecurity.](https://adltqzpaelnsrebtkzfj.supabase.co/storage/v1/object/public/blog-images/ai-generated/uploads/20260806_044425_b90fd1a5.png)


**The client is the attacker.** Every value the server accepts from outside a trust boundary was written by someone trying to get paid. It doesn't matter how obfuscated your app is — the attacker doesn't need your client at all; they replay the HTTP calls. Design as if the app were a published API.

**The client is also the victim.** Everything the server sends *out* gets rendered, opened, or executed on a device that trusts you. A landing URL stored as free text and validated nowhere is your product acting as a delivery vehicle for someone else's payload.

Everything else in the skill is machinery for applying those two sentences systematically instead of vibes-based.

## Nine lenses, ranked findings, no theater

The skill walks the agent through nine lenses: untrusted client, identity and session, abuse economics, content trust, privacy of held data, resource abuse and cost, blast radius, bots and automation, and agent surfaces. Five of them carry most of the weight; the rest exist so that skipping them is an explicit, recorded decision rather than an oversight.

![An illustrated list of the nine lenses in the cybersecurity skill.](https://adltqzpaelnsrebtkzfj.supabase.co/storage/v1/object/public/blog-images/ai-generated/uploads/20260806_044329_3df8e8c9.png)


A few probes, to give the flavor:

- Can the terminal step of a reward flow — `complete`, `redeem`, `payout` — be called directly, with no predecessor? Trace the grant sequence and try to skip steps on paper.
- Are the physics checked? A "watched the video" completion arriving faster than the video's own duration, measured by the *server's* clock, is a farm signature.
- What does one extra account cost an attacker — an email? a device id the client makes up? Multiply by the per-account payout and you have the bot farm's profit margin. If the margin is positive, the farm is coming.
- Can untrusted text reach an agent's instruction stream, and what is the worst tool it could then trigger?

Two rules keep the output honest. First: **one side alone yields hypotheses, never findings.** Client code tells you what the client sends, not what the server demands. The skill forces the agent to locate and read both sides of every boundary, and to label each finding **confirmed** (every side that could refute it has been read) or **assumed** (naming the exact check that would settle it). Second: findings are ranked by **impact × ease** — what one success is worth, times how cheaply it repeats. A scriptable reward farm outranks a theoretical RCE that needs a rooted device and a stolen key.

## Fixes that can't be forgotten

The skill also encodes a house preference order for fixes, from most durable to fastest-rotting:

![A flowchart representing the order of security fixes in the skill.](https://adltqzpaelnsrebtkzfj.supabase.co/storage/v1/object/public/blog-images/ai-generated/uploads/20260806_044230_56d84143.png)


1. A database constraint — a `UNIQUE (grant_token, event_type)` index cannot be skipped, forgotten, or refactored away.
2. A server-side check on server-owned data — the server's own clock, its own session record. Never the client's timestamp.
3. A cap or rate limit — bounds the loss when the first two are wrong.
4. A guard at the point of use, shipped inside the SDK — for outbound content, where no server constraint can help.
5. A test — only for invariants the schema can't express.
6. A scheduled consistency audit — where two services co-own state and no single database can enforce the invariant.

Attestation, obfuscation, and certificate pinning come last: high upkeep, and they only raise the cost of an attack the server should have refused anyway.

This ordering was paid for in production. A case-sensitivity bug in email matching once let a single mailbox — registered twice with different capitalization — spawn several accounts and orphan a user's token balance across two services. No test caught it, because the author's tests shared the author's blind spot. A unique index on the *normalized* email would have held even while the application code was wrong. That incident is now literally baked into one of the lenses, down to the unicode details: plain `lower()` is locale-sensitive, and neither it nor NFKC strips zero-width characters — normalize properly at ingest, then pin the result with an index.

## Three tools, three jobs

The last design decision was drawing hard boundaries against my other review tools, because blended tools rot into one mushy checklist:

- **Launch hygiene** (TLS, backups, CVEs, key rotation) — a separate production-readiness check owns it.
- **Diff-level bugs** — the per-PR security review owns those.
- **"What does an attacker earn, or a user lose?"** — that's this skill, and only this skill.

When a threat-model run stumbles onto a hygiene gap, it names it in one line and routes it elsewhere instead of absorbing it. Each tool stays sharp because each tool stays narrow.

## The takeaway

If you're building with coding agents, the temptation is to accumulate capabilities — install the 817-skill pack, feel armored. The better move is the opposite: find the one class of problem where your products actually bleed, and encode *your* hard-won incidents, *your* fix preferences, and *your* division of labor into something small enough that the agent reliably loads and follows it.

Two files beat 817 — if the two files know where you live.

## Related reading

- [I Turned a Telegram Group Into a Software Project](https://www.tytarenkoagency.com/blog/i-turned-a-telegram-group-into-a-software-project)
- [Graph engineering is easy. Not blowing your budget on one workflow is the hard part](https://www.tytarenkoagency.com/blog/graph-engineering-is-easy-not-blowing-your-budget-on-one-workflow-is-the-hard-part)
- [AI Automation Architectures for Bootstrapped SaaS: Open-Source Patterns to Match Enterprise Scale](https://www.tytarenkoagency.com/blog/ai-automation-architectures-for-bootstrapped-saas-open-source-patterns-to-match-enterprise-scale)