Gated on the untrusted-user (external-lab) rollout — NOT near-term. The internal solve-service (Δ1–Δ10) ships first on trusted internal users; this issue tracks the hardening that must land before we open the API to untrusted/external users. Surfaced grilling the Executor-contract freeze (2026-07-02). Spec: spec-20260628-amicode-cloud-solve-service ("Deferred" section).
Already handled by the architecture (not a gap): external users hit an API broker — an amico-issued token (not AWS creds) on POST /solves (Δ2, #36) + GET /solves/{id}/… (Δ4, #38); the Lambda/API layer holds AWS; results come back as presigned S3 URLs. AWS creds never leave our backend. This issue is the hardening on top of that, which the internal spec deliberately punts.
1. Enforcement / quota (external only)
Internal stance is "record usage, don't enforce" (Δ7 records; no quotas). That's a footgun for external: an external token that can submit unbounded L-size solves spends our money with no ceiling. Before untrusted rollout, external tokens need per-tenant submission rate / concurrency / cost caps. Note Δ6 (#40) is a per-solve wall-clock cap and Δ7 (#41) is a record, not a per-tenant quota — this is net-new.
2. Tenant isolation (external only)
Internal relies on per-user S3 prefix + a Lambda 403. External partners' pulse designs are IP (potentially competitors sharing one bucket) — one bug in the 403 check = cross-tenant leak. Decide the isolation strength for external tenants: prefix-in-one-bucket (current) vs per-tenant bucket / KMS key (or, further out, per-tenant account). Internal can stay prefix-isolated; external likely can't. This is the spec's deferred "external-lab tenancy hardening."
3. Auth — DECIDED: use builtins, don't hand-roll
It's our token. Use platform builtins for issuance / rotation / revocation (AWS Cognito or API Gateway keys + usage plans — not a bespoke token system), and store it extension-side in VS Code SecretStorage (builtin). This is the SecretStorage seam D11 deferred; the cloud token is amico's first owned secret — acceptable because it's our token (scoped + revocable), not a provider key. Revocation/offboarding falls out of the builtin (e.g. delete the Cognito user / disable the key).
Acceptance (pre-rollout): external token can submit + read only its own runs; per-tenant cost/concurrency cap enforced; cross-tenant read is impossible by construction (not just a 403 check); token is revocable via a builtin; extension stores it in SecretStorage.
Gated on the untrusted-user (external-lab) rollout — NOT near-term. The internal solve-service (Δ1–Δ10) ships first on trusted internal users; this issue tracks the hardening that must land before we open the API to untrusted/external users. Surfaced grilling the Executor-contract freeze (2026-07-02). Spec:
spec-20260628-amicode-cloud-solve-service("Deferred" section).Already handled by the architecture (not a gap): external users hit an API broker — an amico-issued token (not AWS creds) on
POST /solves(Δ2, #36) +GET /solves/{id}/…(Δ4, #38); the Lambda/API layer holds AWS; results come back as presigned S3 URLs. AWS creds never leave our backend. This issue is the hardening on top of that, which the internal spec deliberately punts.1. Enforcement / quota (external only)
Internal stance is "record usage, don't enforce" (Δ7 records; no quotas). That's a footgun for external: an external token that can submit unbounded L-size solves spends our money with no ceiling. Before untrusted rollout, external tokens need per-tenant submission rate / concurrency / cost caps. Note Δ6 (#40) is a per-solve wall-clock cap and Δ7 (#41) is a record, not a per-tenant quota — this is net-new.
2. Tenant isolation (external only)
Internal relies on per-user S3 prefix + a Lambda 403. External partners' pulse designs are IP (potentially competitors sharing one bucket) — one bug in the 403 check = cross-tenant leak. Decide the isolation strength for external tenants: prefix-in-one-bucket (current) vs per-tenant bucket / KMS key (or, further out, per-tenant account). Internal can stay prefix-isolated; external likely can't. This is the spec's deferred "external-lab tenancy hardening."
3. Auth — DECIDED: use builtins, don't hand-roll
It's our token. Use platform builtins for issuance / rotation / revocation (AWS Cognito or API Gateway keys + usage plans — not a bespoke token system), and store it extension-side in VS Code SecretStorage (builtin). This is the SecretStorage seam D11 deferred; the cloud token is amico's first owned secret — acceptable because it's our token (scoped + revocable), not a provider key. Revocation/offboarding falls out of the builtin (e.g. delete the Cognito user / disable the key).
Acceptance (pre-rollout): external token can submit + read only its own runs; per-tenant cost/concurrency cap enforced; cross-tenant read is impossible by construction (not just a 403 check); token is revocable via a builtin; extension stores it in SecretStorage.