feat(security): deepen tenant boundary controls (#362)

Add plane separation, identity propagation, support access, resource isolation, lifecycle proof, exhaustion threats, evals, and specialist routing.\n\nAI-assisted: Jasper orchestrated implementation and verification with OpenCode.

Signed-off-by: Magnus Hedemark <magnus919@pm.me>

.claude-plugin/marketplace.json

@@ -1065,7 +1065,7 @@
         "./secure-software-engineering"
       ],
       "strict": false,
-      "description": "Use when designing or implementing software securely: define security requirements, threat-model a feature, choose secure defaults, design authentication and authorization, handle untrusted data and secrets, evaluate dependencies, or review security-sensitive changes. Use for prevention during requirements, design, implementation, and review; not for post-build security assessments or scanning an existing codebase."
+      "description": "Use when designing or implementing software securely: define security requirements, threat-model a feature, choose secure defaults, design authentication and authorization, handle untrusted data and secrets, evaluate dependencies, design multi-tenant trust boundaries, or review security-sensitive changes. Use for prevention during requirements, design, implementation, and review; not for post-build security assessments or scanning an existing codebase."
     },
     {
       "name": "security-audit-methodology",

llms.txt

@@ -119,7 +119,7 @@
 - [research-methodology](research-methodology/SKILL.md): Plan, conduct, evaluate, and synthesize rigorous research. Use for journalistic, industry, or technical investigations that need credible evidence and a traceable method.
 - [resilience-and-recovery](resilience-and-recovery/SKILL.md): Design, exercise, and evidence graceful degradation, disaster recovery, and restoration behavior across systems and dependencies. Covers failure-mode analysis, RTO/RPO decision records, restore testing, game days, failover drills, data integrity verification, and recovery communication. Do not use for live incident command or incident response; route to site-reliability-engineering for those. Do not use for infrastructure implementation details; route to platform-engineering.
 - [restic](restic/SKILL.md): Install, configure, operate, secure, automate, tune, troubleshoot, and recover restic backups across local, SFTP, S3-compatible, cloud, and REST backends. Use when creating or managing a restic repository, designing backup or retention policy, validating restores, handling repository health or locks, moving repositories, or building safe scheduled backup jobs. Do not use for a generic file-copy task that does not need encrypted, deduplicated snapshots.
-- [secure-software-engineering](secure-software-engineering/SKILL.md): Use when designing or implementing software securely: define security requirements, threat-model a feature, choose secure defaults, design authentication and authorization, handle untrusted data and secrets, evaluate dependencies, or review security-sensitive changes. Use for prevention during requirements, design, implementation, and review; not for post-build security assessments or scanning an existing codebase.
+- [secure-software-engineering](secure-software-engineering/SKILL.md): Use when designing or implementing software securely: define security requirements, threat-model a feature, choose secure defaults, design authentication and authorization, handle untrusted data and secrets, evaluate dependencies, design multi-tenant trust boundaries, or review security-sensitive changes. Use for prevention during requirements, design, implementation, and review; not for post-build security assessments or scanning an existing codebase.
 - [security-audit-methodology](security-audit-methodology/SKILL.md): Plan authorized security reviews with threat modeling, architecture and dependency audits, and vulnerability classification. Use for scoped defensive security assessment. Do not use for offensive operations, unauthorized testing, or security control implementation.
 - [semantic-spacetime](semantic-spacetime/SKILL.md): Model and diagnose shared semantic ground between agents with Semantic Spacetime (Mark Burgess, 2014-2025): a discrete graph model of meaning over time, where local proper time replaces global clocks, causality is cooperative promises, and gamma(3,4) graphs expose semantic drift, world model divergence, and absorbing states. Use for designing convergent self-healing coordination, modeling intent and trajectories over time, mapping promises onto spacetime, diagnosing semantic drift or dead-ends, and analyzing temporal blindness in agents. Do not use for physics or relativity, pure vector embeddings or RAG without temporal-causal structure, enforceable centralized control, simple single-agent prompting, or tool manuals — route those to the appropriate skill.
 - [seo-audit](seo-audit/SKILL.md): Audit websites and pages for technical SEO, on-page SEO, schema markup, content discoverability, and answer-engine readiness. Use when prioritizing search visibility improvements; route AEO-specific implementation and measurement to the dedicated aeo skill.

references/skill-triggers.md

@@ -89,7 +89,7 @@ Each skill's `description` field is the canonical routing contract. This conveni
 | "resilience", "recovery", "graceful degradation", "disaster recovery", "DR plan", "game day", "restore test", "failover drill", "RTO", "RPO", "recovery plan", "resilience plan", "data integrity after restore", "recovery exercise", "follow-up work ledger", "recovery communication", "dependency loss", "circuit breaker resilience", "degradation path", "feature shedding" | [resilience-and-recovery](../resilience-and-recovery/SKILL.md) |
 | "restic", "restic backup", "restic repository", "restic restore", "restic prune", "restic forget", "restic check", "restic snapshots", "encrypted backup", "backup retention", "restore drill", "backup integrity", "repository lock", "S3 backup", "SFTP backup" | [restic](../restic/SKILL.md) |
 | "technical-documentation", "technical documentation" | [technical-documentation](../technical-documentation/SKILL.md) |
-| "secure software engineering", "build securely", "secure by design", "security requirements", "security acceptance criteria", "threat model this design", "secure code review", "secure defaults", "authorization design", "multi-tenant isolation", "release evidence", "SBOM", "software supply chain", "AI security", "LLM security", "prompt injection", "tool authorization", "RAG security" | [secure-software-engineering](../secure-software-engineering/SKILL.md) |
+| "secure software engineering", "build securely", "secure by design", "security requirements", "security acceptance criteria", "threat model this design", "secure code review", "secure defaults", "authorization design", "multi-tenant isolation", "tenant trust boundary", "control-plane security", "application-plane security", "tenant identity propagation", "support impersonation security", "tenant backup security", "tenant export security", "tenant deletion security", "noisy neighbor security", "resource exhaustion tenant", "release evidence", "SBOM", "software supply chain", "AI security", "LLM security", "prompt injection", "tool authorization", "RAG security" | [secure-software-engineering](../secure-software-engineering/SKILL.md) |
 | "security-audit-methodology", "security audit methodology" | [security-audit-methodology](../security-audit-methodology/SKILL.md) |
 | "mermaid-diagrams", "mermaid diagrams" | [mermaid-diagrams](../mermaid-diagrams/SKILL.md) |
 | "adr-authoring", "adr authoring", "architecture decision record", "fitness function", "decision confirmation" | [adr-authoring](../adr-authoring/SKILL.md) |

secure-software-engineering/README.md

@@ -14,7 +14,7 @@ Instead of treating a checklist or scanner as a security guarantee, the workflow
 |---|---|
 | `SKILL.md` | A five-phase, prevention-oriented workflow and routing guide. |
 | `references/source-index.md` | Version-pinned primary sources and the decisions they inform. |
-| `references/` | Focused guidance for threat modeling, controls, review, release, incident learning, and AI systems. |
+| `references/` | Focused guidance for threat modeling, controls, review, release, incident learning, AI systems, and multi-tenant boundaries. |
 | `templates/` | Adaptable threat-model, acceptance-criteria, and review-checklist starting points. |
 
 ## Quick Start
@@ -33,7 +33,13 @@ The resulting model should name assets, boundaries, assumptions, abuse cases, mi
 - Threat-model a system, API, integration, tenant boundary, or AI capability.
 - Define security acceptance criteria or review a security-sensitive change.
 - Choose authentication, authorization, secret handling, dependency, logging, or release-evidence practices.
+- Threat-model pooled, bridge, or silo tenant isolation, support impersonation, tenant lifecycle, or shared-resource exhaustion.
 
 ## Requirements
 
 No runtime dependency, API key, or platform-specific tool is required. The included sources are decision aids; adopt the controls that apply to your organization, contract, regulator, and threat model.
+
+For end-to-end SaaS tenant semantics and placement decisions, use
+`multi-tenant-saas-architecture`. For quantitative tenant capacity and cost
+evidence, use `capacity-and-cost-engineering`; for privacy lifecycle artifacts,
+use `privacy-engineering`.

secure-software-engineering/SKILL.md

@@ -3,9 +3,10 @@ name: secure-software-engineering
 description: >-
   Use when designing or implementing software securely: define security requirements,
   threat-model a feature, choose secure defaults, design authentication and authorization,
-  handle untrusted data and secrets, evaluate dependencies, or review security-sensitive
-  changes. Use for prevention during requirements, design, implementation, and review;
-  not for post-build security assessments or scanning an existing codebase.
+  handle untrusted data and secrets, evaluate dependencies, design multi-tenant trust
+  boundaries, or review security-sensitive changes. Use for prevention during
+  requirements, design, implementation, and review; not for post-build security
+  assessments or scanning an existing codebase.
 license: MIT
 compatibility: No runtime dependency. Host-neutral guidance for authorized software engineering work.
 ---
@@ -20,6 +21,10 @@ Use this skill to answer "How do we build this securely?" for a new feature, int
 
 Do not use it for an authorized post-build assessment: use [security-audit-methodology](../security-audit-methodology/SKILL.md). Do not use it as a vulnerability scanner for an existing codebase; use an authorized scanning tool or specialist security assessment. Use [spec-driven-development](../spec-driven-development/SKILL.md) when the task is to formalize the resulting requirements and phase gates, and [verification-methodology](../verification-methodology/SKILL.md) to make evidence-backed completion claims.
 
+## When not to use
+
+Use [multi-tenant-saas-architecture](../multi-tenant-saas-architecture/SKILL.md) for the end-to-end tenant model, control/application-plane placement, commercial lifecycle, and SaaS operating architecture; this skill owns the threat model and enforceable isolation controls. Use [capacity-and-cost-engineering](../capacity-and-cost-engineering/SKILL.md) for quantitative tenant demand, quota sizing, fairness, load/soak evidence, and unit-cost tradeoffs. Route privacy lifecycle and deletion-verification artifacts to [privacy-engineering](../privacy-engineering/SKILL.md).
+
 ## Workflow
 
 1. **Requirements**: identify assets, actors, harm, data classifications, regulatory or contractual constraints, and security outcomes. Write testable acceptance criteria before selecting controls.
@@ -41,7 +46,7 @@ Loop to the affected phase when evidence contradicts an assumption or a design c
 | Adding a key, token, credential, or signing material | [references/secrets-lifecycle.md](references/secrets-lifecycle.md) |
 | Adding, updating, building, or publishing dependencies | [references/dependency-supply-chain.md](references/dependency-supply-chain.md) |
 | Designing logs, audit events, monitoring, or forensic evidence | [references/secure-logging-audit.md](references/secure-logging-audit.md) |
-| Sharing infrastructure or data across tenants | [references/multi-tenant-isolation.md](references/multi-tenant-isolation.md) |
+| Sharing infrastructure or data across tenants, including control/application planes, tenant context, support access, or tenant lifecycle proof | [references/multi-tenant-isolation.md](references/multi-tenant-isolation.md) |
 | Reviewing a change or defining a security review gate | [references/secure-code-review.md](references/secure-code-review.md) |
 | Preparing artifacts, exceptions, rollback, or response for release | [references/release-evidence.md](references/release-evidence.md); load [release-engineering](../release-engineering/SKILL.md) to carry those controls and evidence through build, registry, promotion, and deployment gates |
 | Learning from an incident, near miss, or escaped defect | [references/incident-learning.md](references/incident-learning.md) |

secure-software-engineering/evals/evals.json

@@ -61,6 +61,42 @@
         "The decision framework includes rejection and isolation options, not just acceptance",
         "Ongoing controls are prescribed: lockfiles, CI scanning, and review cadence"
       ]
+    },
+    {
+      "id": "multi-tenant-boundary",
+      "prompt": "We run a pooled SaaS API with a separate control plane. Design the security review for tenant identity propagation, support impersonation, caches, search, queues, exports, backups, and deletion. Keep the SaaS placement decision and capacity modeling with their specialist owners.",
+      "expected_output": "A security-focused review that treats control-plane to application-plane handoffs as trust boundaries; derives tenant context from verified identity; independently authorizes downstream services, workers, and support tools; defines scoped, expiring impersonation; covers cache, search, queue, export, backup, deletion, keys, logs, and restore boundaries; and names direct negative tests and provisioning/deprovisioning evidence. It explicitly routes end-to-end SaaS architecture and quantitative capacity evidence to their neighboring skills.",
+      "assertions": [
+        "Control-plane and application-plane trust boundaries, authority, freshness, and failure behavior are explicit",
+        "Tenant identity is server-derived and re-authorized across APIs, workers, callbacks, and downstream services",
+        "Privileged support and impersonation require scope, purpose, expiry, approval, and audit evidence",
+        "Caches, search, queues, keys, logs, exports, backups, restore, and deletion are addressed as tenant-bearing boundaries",
+        "The output routes SaaS architecture and capacity evidence to the named neighboring owners"
+      ]
+    },
+    {
+      "id": "tenant-resource-exhaustion",
+      "prompt": "A large customer can saturate our shared queue workers and search cluster, causing smaller tenants to time out. Threat-model the issue and define security controls and proof without inventing universal utilization targets.",
+      "expected_output": "A threat model for noisy-neighbor and resource-exhaustion abuse that identifies shared resource blast radius, tenant attribution, admission control, bounded work, per-tenant limits, fair scheduling or reserved capacity, backpressure, safe degradation, and abuse detection. It asks for tenant-distributed load or soak evidence and clearly routes sizing, utilization rationale, and cost tradeoffs to capacity-and-cost-engineering.",
+      "assertions": [
+        "The threat model identifies shared queue/search exhaustion and cross-tenant availability impact",
+        "Controls include tenant attribution, bounded work, quotas or rate limits, fair scheduling or isolation, and safe degradation",
+        "Verification requires tenant-distributed load or soak evidence and observes fairness and denial behavior",
+        "The response avoids universal utilization targets and routes quantitative capacity decisions correctly",
+        "The response distinguishes security controls from platform implementation details"
+      ]
+    },
+    {
+      "id": "tenant-lifecycle-privilege",
+      "prompt": "Review a tenant offboarding flow where deletion is asynchronous and customer support can impersonate users to troubleshoot. What security requirements and evidence are missing?",
+      "expected_output": "A review that requires authenticated, idempotent deprovisioning with revocation of sessions, tokens, jobs, callbacks, and export access; bounded handling of replicas, indexes, caches, logs, backups, and derived data; reconciliation and completion evidence; and support impersonation with named operator, purpose, target scope, approval, expiry, visible indication, least privilege, and audit trail. It routes privacy deletion artifacts to privacy-engineering rather than treating a security review as legal advice.",
+      "assertions": [
+        "Asynchronous deprovisioning includes authority, idempotency, revocation, blocking new work, retries, and reconciliation",
+        "Deletion and retention evidence covers replicas, indexes, caches, logs, backups, exports, and derived data",
+        "Support impersonation is scoped, time-limited, approved, visible, least-privileged, and auditable",
+        "Direct negative tests cover stale jobs, revoked access, wrong tenant, and expired impersonation",
+        "Privacy lifecycle ownership is routed to privacy-engineering"
+      ]
     }
   ]
 }

secure-software-engineering/references/multi-tenant-isolation.md

@@ -1,24 +1,146 @@
 # Multi-Tenant Isolation
 
+Security owns the threat model and enforceable controls for tenant boundaries. The
+end-to-end SaaS architecture, commercial tiers, placement strategy, and lifecycle
+authority belong to [multi-tenant-saas-architecture](../../multi-tenant-saas-architecture/SKILL.md).
+
 ## Make The Decision Now
 
-Define the isolation promise: which tenants may share compute, storage, keys, queues, caches, search indexes, logs, and support paths, and which may not. Derive tenant context on the server from a verified identity or trusted workload binding, then enforce it at every data and resource boundary.
+State the isolation promise per tenant tier and resource. For compute, storage,
+keys, queues, caches, search, logs, backups, exports, support paths, and recovery,
+record whether tenants share a pooled boundary, use a bridge boundary with a
+dedicated sensitive component, or receive a silo boundary. A tier name is not a
+control: identify the mechanism, the failure it prevents, and the evidence that
+supports the promise. Route demand distributions, quota sizing, fairness targets,
+and unit-cost evidence to
+[capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md).
 
-## Choose Layered Controls
+## Model The Two Planes
 
-- Scope queries, object stores, caches, queues, search, exports, background jobs, and analytics by server-derived tenant context.
-- Use one or more fitting mechanisms: separate accounts or databases, schema or namespace boundaries, application-enforced predicates, row-level security, encryption-key separation, or workload isolation. RLS is one option and still needs correct policy, connection, and privileged-job handling.
-- Bind job payloads and callbacks to tenant context; authorize workers and support tools independently rather than trusting a queue field.
-- Partition caches and rate limits; avoid keys, reuse, or resource quotas that let one tenant read, influence, or exhaust another tenant's resources.
-- Make safe defaults automatic: a new tenant should receive restrictive permissions, isolation, logging, and limits without manual hardening. This aligns with CISA Secure by Design joint guidance.
-- Constrain AI retrieval and tools to the authorized tenant and user context. A prompt must not broaden a corpus or tool capability.
+Treat the control plane and application plane as distinct trust boundaries even if
+they run in one deployment. The control plane may decide tenant identity,
+placement, entitlements, support grants, provisioning, suspension, export, and
+deletion; it must not become an unrestricted reader of application data by default.
+The application plane serves tenant work and must consume authenticated,
+versioned policy state without treating a client claim as authority.
+
+For every crossing, document the actor and authority, credential audience, tenant
+and user context, policy version, freshness rule, failure behavior, idempotency
+key, and audit event. A stale or unavailable control-plane decision must fail in a
+defined safe mode, not silently widen access. Provisioning and deprovisioning
+commands need authenticated origin, replay protection, duplicate handling, and
+reconciliation evidence. Platform implementation of network, workload, secret,
+logging, and backup substrate belongs to
+[platform-engineering](../../platform-engineering/SKILL.md).
+
+## Propagate Identity Without Trusting Labels
+
+Derive tenant context from a verified user or workload identity and an authoritative
+membership/placement lookup. Bind it to the request, transaction, job, trace,
+export, and downstream call using a server-controlled context. Reject missing,
+stale, mismatched, or audience-confused context. A tenant ID in a header, URL,
+queue payload, callback, cache key, or JWT custom claim is an input to validate,
+not proof of authority.
+
+At each hop preserve the subject, tenant, actor type, delegated purpose, resource
+scope, and correlation identifier. Downstream services and workers must authorize
+again within their own authority; gateway authentication or an upstream predicate
+is not sufficient. API and event contract details belong to
+[api-design-and-evolution](../../api-design-and-evolution/SKILL.md), while service
+middleware, data access, jobs, and integration tests belong to
+[backend-engineering](../../backend-engineering/SKILL.md).
+
+## Protect Privileged Support Paths
+
+Support access and impersonation are separate administrative capabilities, not a
+special case that bypasses tenant authorization. Require a named operator, an
+approved purpose, target tenant and resource scope, time limit, ticket or case
+reference where policy requires it, and a visible session indicator. Prefer
+read-only or customer-approved actions; require step-up approval for writes,
+exports, key access, deletion, or cross-tenant investigation. Prevent chaining
+impersonation into broader operator privileges, and make break-glass access
+expire automatically.
+
+Record who initiated, who was impersonated, why, what policy allowed it, which
+objects were touched, what changed, and when the grant expired. Test direct API,
+bulk, background, and support-tool paths with expired, revoked, wrong-tenant, and
+cross-tenant grants. Audit-event design and sensitive-field minimization belong
+to the logging owner; the security requirement is that the action be attributable
+and reviewable.
+
+## Apply Controls To Every Tenant-Bearing Resource
+
+- **Data and keys:** Scope queries and object stores by server-derived tenant
+  context. Use separate accounts, databases, schemas, namespaces, predicates,
+  RLS, workload boundaries, or key hierarchies as the promise requires. Per-tenant
+  keys can reduce blast radius but do not replace authorization; define key access,
+  rotation, disablement, recovery, and destruction evidence.
+- **Caches, search, and queues:** Include an authoritative tenant and resource
+  scope in cache identity and invalidation. Filter search at query authorization
+  and index/write boundaries. Bind queue messages, worker credentials, callbacks,
+  retries, dead letters, and replay tools to tenant scope. Never let a shared
+  worker select a tenant solely from message data.
+- **Logs and traces:** Keep tenant context for investigation without copying
+  customer payloads into shared telemetry. Separate audit access from ordinary
+  operators, restrict query scope, redact secrets and sensitive content, and
+  define retention and deletion behavior. A trace ID is correlation, not an
+  authorization token.
+- **Backups, restore, export, and deletion:** Define whether backup snapshots
+  are pooled, bridge, or siloed and who may restore them. Restore into a bounded
+  quarantine before serving data; verify tenant identity, key availability,
+  authorization, and integrity. Exports must be tenant-scoped, purpose-bound,
+  time-limited, encrypted, and independently authorized. Deletion must cover
+  primaries, replicas, indexes, caches, queues, logs, derived data, exports, and
+  backups according to the adopted retention policy, with completion and gap
+  evidence. Route lifecycle and privacy acceptance artifacts to
+  [privacy-engineering](../../privacy-engineering/SKILL.md).
+- **Resource controls:** Give each tenant and tier explicit concurrency, storage,
+  request, queue, search, export, and job limits where exhaustion can cross a
+  boundary. Protect shared pools with admission control, bounded work, fair
+  scheduling, backpressure, and reserved capacity where justified. A quota is
+  not a capacity model; route sizing, load/soak evidence, hot-tenant analysis,
+  and cost tradeoffs to [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md).
+
+## Threat Cases
+
+Threat-model at least these abuse paths and add design-specific variants:
+
+| Case | Security question | Evidence to seek |
+|---|---|---|
+| Control-plane compromise or confused deputy | Can a provisioning, support, entitlement, or restore capability read or alter application data beyond its purpose? | Separate credentials and policy tests for each plane and privileged command. |
+| Context substitution | Can a caller replace tenant context between authentication, lookup, queueing, storage, or downstream calls? | Direct, asynchronous, retry, and callback tests with mismatched context. |
+| Support impersonation abuse | Can an operator hide, prolong, chain, or broaden an impersonation session? | Approval, expiry, scope, audit, revocation, and break-glass tests. |
+| Shared-resource bleed | Can cache reuse, search ranking, logs, backups, exports, or dead letters reveal another tenant? | Distinct sentinel data and negative tests at every resource boundary. |
+| Noisy neighbor or exhaustion | Can one tenant consume shared workers, connections, memory, queue depth, search capacity, storage, or export bandwidth and deny another? | Tenant-distributed load/soak evidence, quotas, fairness observations, and safe degradation. |
+| Lifecycle race | Can a suspended, deleted, or deprovisioned tenant continue receiving jobs, tokens, exports, or restored data? | Provision/deprovision state machine tests, tombstone handling, retries, and reconciliation records. |
 
 ## Evidence And Verification
 
-Test cross-tenant reads, writes, cache hits, search results, exports, jobs, audit events, and resource exhaustion using distinct tenants. Inspect privileged paths, migrations, support tools, and batch workers for policy bypass. Prove provisioning produces safe defaults.
+Build an authorization matrix and a resource-boundary inventory. Prove, with
+distinct tenants and tiers, allowed and denied reads/writes, direct and bulk API
+paths, worker retries and replays, cache hits, search results, logs, keys, backup
+restore, exports, deletion, support impersonation, and resource exhaustion. Verify
+that a new tenant is born with restrictive permissions, scoped credentials,
+tenant-aware observability, limits, and no unintended shared data.
+
+For deprovisioning, show the initiating authority, state transition, revocation
+of sessions and jobs, blocking of new work, completion across every store, and
+reconciliation of failures. Record evidence location, test environment, policy
+version, owner, and residual gap. A passing database test does not prove that
+cache, search, logs, backups, queues, support tools, or capacity boundaries are
+safe.
 
 ## Misuse To Avoid
 
-- Filtering tenant IDs only in the UI or trusting a client-provided tenant header.
-- Treating database isolation as sufficient while cache keys, logs, or asynchronous workers remain shared.
-- Granting an AI agent a tenant-wide capability when the user needs a document-scoped one.
+- Treating a pooled, bridge, or silo label as proof without naming its actual
+  isolation mechanism and failure blast radius.
+- Filtering tenant IDs only in the UI or trusting client headers, URL segments,
+  queue fields, trace fields, or support claims.
+- Treating control-plane administrator access, database privilege, or restore
+  access as permission to view every tenant's application data.
+- Calling a database boundary complete while cache keys, logs, search indexes,
+  asynchronous workers, exports, backups, or deletion jobs remain shared.
+- Calling a rate limit or quota capacity evidence without representative load,
+  distribution, fairness, and degradation measurements.
+- Granting an AI agent tenant-wide capability when the user needs a
+  document-scoped capability; prompts and retrieval content cannot grant access.

secure-software-engineering/references/source-index.md

@@ -8,7 +8,7 @@ Use this manifest to select a source for a concrete decision, not to imply that
 | NIST SSDF AI Profile | SP 800-218A Final, 2024-07 | https://doi.org/10.6028/NIST.SP.800-218A | U.S. guidance for AI development practices | Adapt lifecycle controls for AI components and suppliers. |
 | OWASP ASVS | stable 5.0.0, tag `v5.0.0_release`, 2025-05-30 | https://github.com/OWASP/ASVS/releases/tag/v5.0.0_release | Application security verification standard and control catalog | Select and test application control objectives. |
 | OWASP Top 10 | 2025 | https://owasp.org/Top10/2025/ | Awareness and risk-categorization guidance | Communicate web application risk without substituting for a threat model. |
-| OWASP API Security Top 10 | 2023 edition, verified 2026-07-13 | https://owasp.org/API-Security/editions/2023/en/0x11-t10/ | API risk-awareness guidance | Review object and function authorization, resource consumption, inventory, and third-party API use. |
+| OWASP API Security Top 10 | 2023 edition, verified 2026-07-13 | https://owasp.org/API-Security/editions/2023/en/0x11-t10/ | API risk-awareness guidance | Review object and function authorization, resource consumption, inventory, and third-party API use, including tenant context at API and event boundaries. |
 | OWASP Cheat Sheet Series | retrieved 2026-07-13 | https://cheatsheetseries.owasp.org/ | Implementation guidance | Compare framework-specific patterns after choosing a control objective. |
 | CISA Secure by Design | joint guidance, 2024 update | https://www.cisa.gov/securebydesign | Joint manufacturer guidance | Prefer secure defaults, ownership, and transparent evidence. |
 | SLSA | v1.2 | https://slsa.dev/spec/v1.2/ | Supply-chain framework | Decide what build provenance claim to seek and verify. |
@@ -16,5 +16,15 @@ Use this manifest to select a source for a concrete decision, not to imply that
 | SPDX | 3.0.1 | https://spdx.github.io/spdx-spec/v3.0.1/ | SBOM, license, and software metadata standard | Choose interoperable component and license evidence. |
 | MITRE ATLAS | retrieved 2026-07-13 | https://atlas.mitre.org/ | AI adversary behavior taxonomy | Describe AI threat techniques; it is not exhaustive. |
 | OWASP Top 10 for Large Language Model Applications | release tag `2024`, titled `2025` | https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/releases/tag/2024 | LLM risk awareness guidance | Elicit prompt, tool, data, and model boundary risks. |
+| NIST Cybersecurity Framework | CSF 2.0, 2024-02 | https://doi.org/10.6028/NIST.CSWP.29 | Voluntary cybersecurity risk-management framework | Frame tenant-boundary ownership, protection, detection, response, and recovery evidence without treating the framework as a control checklist. |
+| NIST SP 800-57 Part 1 Rev. 5 | 2020-05 | https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final | Key-management guidance | Inform key ownership, separation, lifecycle, recovery, and destruction questions for tenant-scoped data. |
 
 When citing a control, state the decision, selected source, version, evidence, and what would falsify the claim. Do not rely on unchecked section numbers; verify them against the exact release before using them.
+
+For the multi-tenant reference, public sources are decision aids rather than a
+copied checklist. The procedure is an original synthesis organized around trust
+boundaries, resource-specific promises, abuse cases, and verification. SaaS
+architecture choices remain with `multi-tenant-saas-architecture`; quantitative
+capacity evidence remains with `capacity-and-cost-engineering`; privacy lifecycle
+artifacts remain with `privacy-engineering`; and substrate implementation remains
+with `platform-engineering`.