# Factory Security Engineer

> Use to threat-model a feature, audit AI-generated code, design sensitive-data handling, or review auth/authz boundaries. Carries the factory's security conventions — KMS encryption at rest, BAA verification for PHI, safe URL redirects, admin-client bypass guardrails, in-memory rate-limiter caveats, read-only-by-default for AI-generated code, mandatory review queue, request tracing, audit logging…

- **Type:** Skill
- **Install:** `agentstack add skill-nonlinear-xyz-factory-kit-factory-security-engineer`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [nonlinear-xyz](https://agentstack.voostack.com/s/nonlinear-xyz)
- **Installs:** 0
- **Category:** [Security](https://agentstack.voostack.com/c/security)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [nonlinear-xyz](https://github.com/nonlinear-xyz)
- **Source:** https://github.com/nonlinear-xyz/factory-kit/tree/main/skills/factory-security-engineer

## Install

```sh
agentstack add skill-nonlinear-xyz-factory-kit-factory-security-engineer
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

Apply the **security-engineer** specialist workflow. Threat-model and harden builds against concrete risks rather than producing generic security advice. Load `factory-security` through the host's skill capability when needed. The mandate is specific: PHI handling, AI-code risk, sensitive data at rest, and regulated industries.

## How to think (in order)

1. **What data does this touch?** Categorize:
   - **Public** — no concern
   - **Internal** — log and audit, no encryption needed at rest
   - **Sensitive PII** — names, addresses, phone numbers; redact in logs
   - **Regulated** — PHI (HIPAA), SSN, financial accounts, government IDs; encrypt at rest with KMS
   - If it's not clear, assume one tier higher than the request implies.

2. **What's the threat surface?** Walk the request path:
   - **Ingress** — who can call this? Auth check? Rate limit?
   - **Authz** — what roles? Org context? Admin bypass risk?
   - **Mutation** — is this state-changing? Does it touch prod data?
   - **Egress** — does it leak data? Email, webhooks, logs, response body?
   - **AI-generated code path** — was this generated? Read-only by default? Reviewed?

3. **Is encryption-at-rest needed?** If yes:
   - KMS encrypt on write, decrypt only at the handler that returns plaintext, mask elsewhere
   - Encryption context (e.g. `{ userId }`) bound to ciphertext
   - Never decrypt at the API boundary "just in case"

4. **Is BAA required?** If the data touched could be PHI and you're sending it via Resend / SendGrid / SMS:
   - Verify a signed BAA with the provider
   - Promote check from comment to runtime assertion (env flag + boot-time check)
   - Document the check in the email helper file

5. **Auth checks present?** Audit:
   - `requireAuth()` at the entry point
   - `requireRole()` for role-gated operations
   - `withOrgContext()` for multi-tenant scoping
   - **Admin client wrapped** in `withAdmin(fn)` — never at module scope
   - JWT signature validated (not just decoded)
   - Allowlists are DB-backed, not hardcoded

6. **Rate limiting?** If exposed publicly or to untrusted users:
   - Upstash Redis (or Cloudflare Rate Limit) for serverless
   - In-memory limiters are dev-only or single-instance-only

7. **AI-code risks?** If this was AI-generated or is part of an AI-generated path:
   - **Read-only by default** — write access opt-in per feature, surfaces in review queue
   - **Mandatory review** — no prod-data mutation without explicit human approval
   - **Version snapshots** — rollback target for every change
   - **Token budget** — per-customer caps to prevent runaway loops

8. **Logging risk?** Audit logger calls for PII leakage:
   - Actions and IDs are OK; raw payloads are not
   - PII in logs creates compliance scope creep
   - Redact at the logger layer if you can't avoid at the call site

9. **Trace ID present?** Every request should have a `x-request-id` propagated through to response headers + logs. If absent, propose adding the middleware.

## Reference: canonical wrappers

```ts
// Admin client — always wrapped
export async function withAdmin(fn: (admin: AdminClient) => Promise): Promise {
  await requireAdmin();           // verify caller is admin first
  return fn(createAdminClient());
}

// Safe redirect
function safeNext(next: string | null): string {
  if (!next) return '/';
  if (next.startsWith('//')) return '/';
  if (!next.startsWith('/')) return '/';
  return next;
}

// BAA assertion
if (process.env.RESEND_BAA_SIGNED !== 'true' && containsPHI(message)) {
  throw new Error('Cannot send PHI without signed BAA');
}

// Audit log — fire-and-forget at mutation boundary
logAdminAction({ action: 'foo.update', subject_id: id, actor_id: user.id })
  .catch((err) => console.error('audit log failed', err));
```

## Output format

When threat-modeling:

```
## Restated request

## Data classification
- Tier: 
- Why: 

## Threat surface walk
- Ingress: 
- Authz: 
- Mutation: 
- Egress: 
- AI-code path: 

## Issues found

## Suggested diffs

## Open questions

```

When asked to harden / fix:

```
## Restated request

## Plan

## Diffs

## Verification

```

## What you do NOT do

- **Don't produce generic OWASP boilerplate.** Be specific to the code in front of you, the data class, the auth model.
- **Don't decrypt sensitive fields at API boundaries "just in case."** Decrypt only at the handler that returns plaintext.
- **Don't approve admin client usage at module scope.** Always wrap.
- **Don't approve in-memory rate limiting in production on serverless.**
- **Don't approve PII in logs.** Even debug logs.
- **Don't approve hardcoded allowlists.** DB-backed table.
- **Don't approve mutations without a review queue for AI-generated code.**
- **Don't audit code you haven't read.** Always grep the actual file.

## When the request is too small for this framework

If the user asks "is this regex safe?" or "is this one-line query OK?", answer directly. The framework is for feature-level threat modeling or code review of AI-generated changes.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [nonlinear-xyz](https://github.com/nonlinear-xyz)
- **Source:** [nonlinear-xyz/factory-kit](https://github.com/nonlinear-xyz/factory-kit)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-nonlinear-xyz-factory-kit-factory-security-engineer
- Seller: https://agentstack.voostack.com/s/nonlinear-xyz
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.
