Product Infrastructure Security Engineer
When to Use
- Threat-model product features, internal APIs, workers, and customer-facing infrastructure
- Design or review tenant isolation, authorization boundaries, and customer data-plane controls
- Harden product-owned services with secure defaults, service auth, rate limits, audit logs, and encryption
- Review product IaC or runtime changes for cross-tenant data leaks and abuse paths
- Support incidents involving customer workloads, tenant blast radius, or product security regressions
When NOT to Use
- Implement corporate IdP, KMS, PAM, SIEM, or EDR systems →
information-security-engineer
- Add CI/CD security gates, SBOMs, or supply-chain controls only →
devsecops
- Run SOC alert triage and detection tuning →
defensive-security-analyst
- Execute authorized pentests or exploit validation →
offensive-security-analyst
- Build general IDP, golden paths, or developer portals →
platform-engineer
- Define company-wide security strategy or GRC roadmap →
cybersecurity
- Design RAG/copilot/LLM solution architecture →
applied-ai-architect-commercial-enterprise
Related skills
| Need |
Skill |
| Org-wide IAM, KMS ops, SIEM |
information-security-engineer |
| Pipeline scans, SBOM, CI OIDC |
devsecops |
| Product feature code and APIs |
senior-fullstack-developer |
| Core cloud/K8s provisioning |
infrastructure-engineer |
| IDP templates and portal |
platform-engineer |
| Pentest reproduction |
offensive-security-analyst |
| Customer-impacting incident comms |
cybersecurity |
| AI copilot/RAG architecture |
applied-ai-architect-commercial-enterprise |
| K8s namespace isolation and deploy |
cluster-deployment-engineer |
Core Workflows
1. Product threat modeling
Scope the product boundary (what attackers and tenants can reach):
- List actors: customer user, tenant admin, partner integration, internal operator, anonymous
- Map assets: customer data, credentials, billing, config, audit logs
- Draw data flows across services and stores
- Identify trust boundaries (tenant, region, env)
- Prioritize threats: cross-tenant access, privilege escalation, data exfil, abuse
- Record mitigations and residual risk owners
See references/product_threat_model.md for STRIDE-lite worksheet.
2. Multi-tenant isolation
Isolation goals:
- No cross-tenant read/write on data paths
- Blast radius contained per tenant on compromise
- Strong tenant ID in every authZ decision (never trust client-supplied tenant alone)
Patterns: row-level security, per-tenant keys, namespace isolation, dedicated cells for enterprise tier.
See references/multi_tenant_isolation.md for patterns and test cases.
3. Service and API security baselines
Every product service should default to:
- Authenticated internal calls (mTLS or signed service tokens)
- AuthZ at resource level, not only route level
- Input validation and size limits on APIs
- Structured audit logs for security-relevant actions
- No secrets in images; workload identity for cloud APIs
See references/secure_service_defaults.md for checklist and anti-patterns.
4. Customer data protection
| Control |
Product infra angle |
| Encryption at rest |
Per-tenant or per-table keys where required |
| Encryption in transit |
TLS everywhere; no TLS termination that exposes plaintext internally without justification |
| Retention |
Deletion hooks for account closure |
| Logging |
Redact PII in product logs; separate security audit stream |
See references/customer_data_protection.md for key hierarchy and deletion workflow.
5. Abuse and resilience
- Rate limits per tenant/user/IP on public and partner APIs
- Idempotency and replay protection on sensitive mutations
- Circuit breakers on dependency calls that handle tenant context
- Quotas on expensive operations (exports, bulk API)
Align with defensive monitoring for anomaly signals.
6. Security design review (product infra)
Review triggers: new data store, new cross-service API, tenancy model change, new integration surface, crypto change.
Review output:
- Findings with severity
- Required controls before launch
- Test plan (isolation tests, negative authZ cases)
- Rollback / feature flag recommendation
See references/security_design_review.md for review template.
7. Incident support (product scope)
When customer workloads are affected:
- Confirm blast radius (which tenants, regions)
- Preserve tenant-scoped logs and configs
- Coordinate containment without cross-tenant impact
- Post-incident: add regression test and detection
Hand off enterprise IR/comms to cybersecurity when required.
When to load references
- Threat modeling →
references/product_threat_model.md
- Tenancy →
references/multi_tenant_isolation.md
- Service baselines →
references/secure_service_defaults.md
- Data and crypto →
references/customer_data_protection.md
- Design reviews →
references/security_design_review.md
1---2name: product-infrastructure-security-engineer3description: Guides product infrastructure security—securing the runtime, data plane, and control plane that ships with the product: multi-tenant isolation, service-to-service auth, customer data boundaries, secure defaults in APIs and workers, abuse-resistant rate limits, product-scoped secrets and encryption, and security design reviews for product infra changes. Use when threat-modeling product features, designing tenant isolation, hardening service mesh or internal APIs, reviewing product IaC/modules for data leaks, defining secure baselines for microservices the product team owns, or partnering on incidents affecting customer workloads—not for corporate IdP/SIEM (information-security-engineer), CI pipeline gates only (devsecops), SOC operations (defensive-security-analyst), authorized pentest execution (offensive-security-analyst), general IDP golden paths (platform-engineer), company-wide GRC (cybersecurity), or applied AI solution architecture for LLM features (applied-ai-architect-commercial-enterprise).4---56# Product Infrastructure Security Engineer78## When to Use910- Threat-model product features, internal APIs, workers, and customer-facing infrastructure11- Design or review tenant isolation, authorization boundaries, and customer data-plane controls12- Harden product-owned services with secure defaults, service auth, rate limits, audit logs, and encryption13- Review product IaC or runtime changes for cross-tenant data leaks and abuse paths14- Support incidents involving customer workloads, tenant blast radius, or product security regressions1516## When NOT to Use1718- Implement corporate IdP, KMS, PAM, SIEM, or EDR systems → `information-security-engineer`19- Add CI/CD security gates, SBOMs, or supply-chain controls only → `devsecops`20- Run SOC alert triage and detection tuning → `defensive-security-analyst`21- Execute authorized pentests or exploit validation → `offensive-security-analyst`22- Build general IDP, golden paths, or developer portals → `platform-engineer`23- Define company-wide security strategy or GRC roadmap → `cybersecurity`24- Design RAG/copilot/LLM solution architecture → `applied-ai-architect-commercial-enterprise`2526## Related skills2728| Need | Skill |29|---|---|30| Org-wide IAM, KMS ops, SIEM | `information-security-engineer` |31| Pipeline scans, SBOM, CI OIDC | `devsecops` |32| Product feature code and APIs | `senior-fullstack-developer` |33| Core cloud/K8s provisioning | `infrastructure-engineer` |34| IDP templates and portal | `platform-engineer` |35| Pentest reproduction | `offensive-security-analyst` |36| Customer-impacting incident comms | `cybersecurity` |37| AI copilot/RAG architecture | `applied-ai-architect-commercial-enterprise` |38| K8s namespace isolation and deploy | `cluster-deployment-engineer` |3940## Core Workflows4142### 1. Product threat modeling4344Scope the **product boundary** (what attackers and tenants can reach):45461. List actors: customer user, tenant admin, partner integration, internal operator, anonymous472. Map assets: customer data, credentials, billing, config, audit logs483. Draw data flows across services and stores494. Identify trust boundaries (tenant, region, env)505. Prioritize threats: cross-tenant access, privilege escalation, data exfil, abuse516. Record mitigations and residual risk owners5253**See `references/product_threat_model.md` for STRIDE-lite worksheet.**5455### 2. Multi-tenant isolation5657**Isolation goals:**5859- No cross-tenant read/write on data paths60- Blast radius contained per tenant on compromise61- Strong tenant ID in every authZ decision (never trust client-supplied tenant alone)6263Patterns: row-level security, per-tenant keys, namespace isolation, dedicated cells for enterprise tier.6465**See `references/multi_tenant_isolation.md` for patterns and test cases.**6667### 3. Service and API security baselines6869Every product service should default to:7071- Authenticated internal calls (mTLS or signed service tokens)72- AuthZ at resource level, not only route level73- Input validation and size limits on APIs74- Structured audit logs for security-relevant actions75- No secrets in images; workload identity for cloud APIs7677**See `references/secure_service_defaults.md` for checklist and anti-patterns.**7879### 4. Customer data protection8081| Control | Product infra angle |82|---|---|83| Encryption at rest | Per-tenant or per-table keys where required |84| Encryption in transit | TLS everywhere; no TLS termination that exposes plaintext internally without justification |85| Retention | Deletion hooks for account closure |86| Logging | Redact PII in product logs; separate security audit stream |8788**See `references/customer_data_protection.md` for key hierarchy and deletion workflow.**8990### 5. Abuse and resilience9192- Rate limits per tenant/user/IP on public and partner APIs93- Idempotency and replay protection on sensitive mutations94- Circuit breakers on dependency calls that handle tenant context95- Quotas on expensive operations (exports, bulk API)9697Align with defensive monitoring for anomaly signals.9899### 6. Security design review (product infra)100101**Review triggers:** new data store, new cross-service API, tenancy model change, new integration surface, crypto change.102103**Review output:**104105- Findings with severity106- Required controls before launch107- Test plan (isolation tests, negative authZ cases)108- Rollback / feature flag recommendation109110**See `references/security_design_review.md` for review template.**111112### 7. Incident support (product scope)113114When customer workloads are affected:1151161. Confirm blast radius (which tenants, regions)1172. Preserve tenant-scoped logs and configs1183. Coordinate containment without cross-tenant impact1194. Post-incident: add regression test and detection120121Hand off enterprise IR/comms to `cybersecurity` when required.122123## When to load references124125- **Threat modeling** → `references/product_threat_model.md`126- **Tenancy** → `references/multi_tenant_isolation.md`127- **Service baselines** → `references/secure_service_defaults.md`128- **Data and crypto** → `references/customer_data_protection.md`129- **Design reviews** → `references/security_design_review.md`
daemon-blockint-tech