Question
Does this AI stack sample's public surface honestly represent its production-readiness boundaries?
Target surface
Product/surface: sample AI stack support layers and the production-readiness boundary. The report checks whether stated limitations map to concrete support-layer work, not whether the sample is production certified.
Short finding
This AWS sample demonstrates responsible boundary language. It explicitly lists production controls that are not implemented: WAF rules, Cognito/MFA, additional auth layers, and Bedrock Guardrails. The risk is not the sample itself but downstream adoption that treats it as production-ready without closing those gaps.
What FoldEngine checked
- README disclaimers and production-readiness boundary language.
- Listed missing production controls (WAF, Cognito, auth, Guardrails).
- Architecture documentation and deployment scope.
- Whether the boundary language is honest and specific.
Stack evidence map
AI Stack Audit sits above AI Code Stability. It checks generated-code seams plus the surrounding support layers: dependencies, infrastructure templates, runtime assumptions, configuration, deployment path, tests, and documentation. This sample is witness-backed by public evidence only; it does not claim a dedicated runner, live deployment, or automated stack validation.
What FoldEngine did not check
- Live deployment or security testing.
- Code execution or stack deployment.
- Whether the architecture pattern is optimal.
- AWS service pricing or cost modeling.
- Full penetration testing or vulnerability scanning.
Production gap inventory
Based on the repository's own stated boundaries:
- WAF rules - not implemented in sample
- Cognito / MFA - not implemented in sample
- Additional authentication layers - not implemented in sample
- Bedrock Guardrails - not implemented in sample
- Rate limiting / abuse prevention - not addressed
- Production observability - not scoped
Evidence boundary / receipt-style summary
- Artifact kind
- ai_stack_audit
- Evidence surface
- Public README and architecture documentation
- Private access
- None
- Execution
- No stack deployment or code execution
Seed candidates
Each gap from the production inventory becomes a bounded recommendation.
Seed A — Scope WAF/rate-limiting layer
Hypothesis: Adding WAF rules and rate limiting closes the most critical production gap.
Value: high · Risk: medium
Evidence required: WAF configuration defined; rate-limit policy documented.
Verification: WAF rules deployed to staging; rate-limit tested under synthetic load.
Seed B — Add authentication layer (Cognito/MFA)
Hypothesis: Real auth prevents unauthorized access to the AI agent interface.
Value: high · Risk: medium
Evidence required: Cognito pool configured; MFA enforced for admin.
Verification: Unauthenticated request returns 401; MFA challenge confirmed.
Seed C — Enable Bedrock Guardrails
Hypothesis: Content guardrails prevent harmful or off-policy AI outputs in production.
Value: medium · Risk: low
Evidence required: Guardrail policy configured in Bedrock console.
Verification: Blocked prompt returns guardrail response instead of raw model output.
Decision receipt: HOLD
Do not adopt this sample as production-ready. The boundary language is honest, but adopters who skip the listed gaps inherit unmitigated production risk.
- Decision
- Hold
- Expires
- 30 days from issuance, unless superseded by a closure check
What must change:
- WAF/rate-limiting layer scoped and deployed to staging
- Authentication layer (Cognito/MFA) operational
- Bedrock Guardrails enabled
Governed next steps
Recommended execution order with unlock conditions and exit criteria.
-
Priority 1 — Seed A: WAF/rate-limiting
Unlock: AWS account with appropriate permissions available.
Exit: WAF rules active in staging; rate-limit tested.
-
Priority 2 — Seed B: Authentication layer
Unlock: WAF layer active (prevents unauthorized probing during auth setup).
Exit: Unauthenticated requests rejected; MFA enforced.
-
Priority 3 — Seed C: Bedrock Guardrails
Unlock: Auth layer operational (guardrails protect authenticated traffic).
Exit: Blocked prompt confirmed; policy violations logged.
-
Closure check available
Unlock: All three recommendations resolved.
Exit: Closure Verification confirms hold conditions cleared; receipt upgrades to proceed.
Stability Ledger entry
This probe appends a private Stability Ledger entry with the decision receipt, recommendations, next-step order, and evidence boundary. The ledger tracks continuity: when those recommendations are completed and a closure check passes, the receipt upgrades from hold to proceed.