pentest gforge loom ai-gateway genai okta aws appsec
GForge — Kickoff Questions
Unknowns to resolve before and during testing. Move items into GForge - Architecture under Confirmed once validated — never silently promote an inference.
Target kickoff: Sep. 9 / 10 → GForge - Overview > Engagement Timeline
Scope and Targets
To Confirm
- Exact Loom URL(s)
- AI Gateway URL(s) / hostnames
- API base paths
- Repositories in scope
- In-scope infrastructure
- Is the target “Loom + AI Gateway integration”, the gateway service itself, or both plus selected GEL/runtime controls?
- Which functions are definitely enabled in staging on day one?
Architecture
To Confirm
- Provide the Confluence architecture diagram referenced in the meeting
- What exactly is the “Light LLM” component, and where is it deployed?
- What runtime / orchestration technology is used? (Kubernetes was inferred by one analysis but not confirmed)
- Where are chat history, projects, user preferences, and any usage/accounting records stored?
- Do Loom and the AI Gateway have separately reachable endpoints?
- Is the “Internal Vault” in the secret path the same service as the separately assessed Vault API? → Vault API - Overview
Authentication and Authorization
To Confirm
- Which Okta token does the gateway validate, and what issuer / audience / scopes / claims are expected?
- Where is PKCE terminated, and where is token validation enforced?
- What roles exist (normal user, admin, support, project owner, etc.)?
- Are Projects and Chat History private, shared, team-based, or organization-wide?
- Are there multiple approved test identities for isolation testing?
Important
The Projects / Chat History ownership model must be answered before any IDOR / BOLA conclusion.
Gateway and Model Policy
To Confirm
- Can the client select the model / provider / route directly?
- Is GLM 5 still the only production-enabled model at test time?
- Are Kimi / Qwen / self-hosted models enabled in staging?
- Which Bedrock guardrails or model-governance controls, if any, are currently active?
- Which budget / rate controls are actually implemented today versus roadmap?
Secrets, Logging, and Data
To Confirm
- Which secrets are injected into Loom / gateway runtime, and which service identities use them?
- Where are prompts / responses logged, retained, or observable?
- Are prompts / responses classified or filtered for sensitive data?
- What logs are available to testers for correlating security events?
Protocol and Application Behavior
To Confirm
- Does chat use normal HTTP, streaming SSE, WebSocket, or another transport?
- Is Swagger / OpenAPI or other gateway API documentation available?
- Are uploads enabled?
- Is retrieval / RAG enabled?
- Are plugins enabled?
- Is browsing enabled?
- Are tools / connectors enabled?
- Is code execution enabled?
Warning
If any of these are not enabled, record them as explicitly excluded rather than leaving scope ambiguous.
Production and Timeline
To Confirm
- Confirm kickoff target (Sep. 9 / 10)
- Confirm execution target (week of Sep. 14) and the two-week window
- Confirm report target (week of Sep. 28)
- Confirm whether any production parity checks are permitted, and the exact restrictions
Explicit Unknowns — Do Not Assume
Source-listed items that must not be converted into architecture facts.
| Unknown | Note |
|---|---|
| Runtime / orchestration platform | Kubernetes inferred in one analysis, not confirmed by the meeting |
| “Light LLM” component | Exact product/component spelling and implementation unknown |
| Storage layer | Database/storage for chat history, projects, preferences, usage/accounting |
| Authorization / role model | Current model in Loom and the gateway |
| Object ownership semantics | Sharing model for Projects and Chat History |
| Rate limits / quotas / budget controls | Exact current values and enforcement |
| Bedrock guardrails | Exact model-governance controls active at test time |
| Streaming transport | Exact protocol for streaming responses |
| Feature enablement | Whether uploads, RAG, tools, browsing, code execution, plugins, or connectors are enabled |
| CLI authentication design | Future design not yet defined |