Problem
resolved_assets (#246/#665) reaches the guest on lambda-microvm without any strategy change — traced and confirmed: orchestrator.ts:999 puts it on the shared agentPayload, the MicroVM strategy forwards that verbatim (inline or via S3), server.py:2122 _extract_invocation_params → :566 → :677 → _spawn_background(**params) → _run_task_background(resolved_assets=…) → pipeline.py:1167 apply_resolved_assets, which is pure-local (writes .mcp.json, makes no AWS calls). So the delivery path is genuinely free.
Two constraints make execution of those assets non-portable, and neither is recorded anywhere:
- 443-only runtime egress.
LambdaMicrovmCompute's runtime security group is allowAllOutbound: false with a single TCP 443 rule (lambda-microvm-compute.ts:862-870). A registry mcp_server asset whose runtime config points at any other port works on agentcore and ecs and fails on lambda-microvm. apply_mcp_assets is fail-CLOSED on load errors but cannot see a connectivity constraint, so the symptom is a task that starts normally and then cannot reach its tool.
resolved_assets consumes the 4 096-byte runHookPayload budget. That cap is exact and measured (lambda-microvm-strategy.ts:100-125), and it is the branch point between inline and S3-pointer delivery. Adding asset entries shifts which tasks inline. Not a bug — the S3 path is already dominant — but it is an untested interaction: no test covers an envelope that crosses 4 096 bytes because of resolved_assets.
Expected
- Document the 443-only constraint where registry assets are described (
docs/design/REGISTRY.md) and in the lambda-microvm section of COMPUTE.md / DEPLOYMENT_GUIDE.md.
- Decide whether to validate it: either a synth/onboarding-time check that a pinned
mcp_server asset's runtime is 443-reachable, or an explicit "not supported on this backend" note.
- Add a strategy test that pushes an envelope over 4 096 bytes via
resolved_assets specifically and asserts the S3-pointer branch is taken.
Refs #645, #246, #665. Blocked by nothing; P2.
Problem
resolved_assets(#246/#665) reaches the guest onlambda-microvmwithout any strategy change — traced and confirmed:orchestrator.ts:999puts it on the sharedagentPayload, the MicroVM strategy forwards that verbatim (inline or via S3),server.py:2122 _extract_invocation_params→:566→:677→_spawn_background(**params)→_run_task_background(resolved_assets=…)→pipeline.py:1167 apply_resolved_assets, which is pure-local (writes.mcp.json, makes no AWS calls). So the delivery path is genuinely free.Two constraints make execution of those assets non-portable, and neither is recorded anywhere:
LambdaMicrovmCompute's runtime security group isallowAllOutbound: falsewith a single TCP 443 rule (lambda-microvm-compute.ts:862-870). A registrymcp_serverasset whose runtime config points at any other port works onagentcoreandecsand fails onlambda-microvm.apply_mcp_assetsis fail-CLOSED on load errors but cannot see a connectivity constraint, so the symptom is a task that starts normally and then cannot reach its tool.resolved_assetsconsumes the 4 096-byterunHookPayloadbudget. That cap is exact and measured (lambda-microvm-strategy.ts:100-125), and it is the branch point between inline and S3-pointer delivery. Adding asset entries shifts which tasks inline. Not a bug — the S3 path is already dominant — but it is an untested interaction: no test covers an envelope that crosses 4 096 bytes because ofresolved_assets.Expected
docs/design/REGISTRY.md) and in thelambda-microvmsection ofCOMPUTE.md/DEPLOYMENT_GUIDE.md.mcp_serverasset's runtime is 443-reachable, or an explicit "not supported on this backend" note.resolved_assetsspecifically and asserts the S3-pointer branch is taken.Refs #645, #246, #665. Blocked by nothing; P2.