pentest gforge loom ai-gateway genai prompt-injection idor bola okta aws appsec
GForge — Test Cases
Test themes and checklists for the GForge / Loom / AI Gateway engagement. These are test ideas, not findings.
Record what you actually observe in GForge - Evidence Log. Promote validated issues to GForge - Findings.
Before You Start
Warning
Several themes depend on unconfirmed architecture. Resolve the relevant items in GForge - Kickoff Questions before drawing conclusions — particularly the ownership model for Projects and Chat History.
- Scope frozen and current-vs-planned recorded → GForge - Current vs Planned Capabilities
- Endpoint inventory started → GForge - Endpoint Inventory
- Baseline normal behavior captured
- Approved test identities available
1. Internal Exposure and Trust of the VPN Boundary
- Confirm Loom and gateway endpoints are reachable only through intended corporate network paths
- Check whether alternate hostnames unintentionally bypass the boundary
- Check direct service endpoints
- Check cloud load balancers
- Check development endpoints
Important
Do not treat “internal-only” as equivalent to “trusted user”. Application controls still need to enforce identity and permissions.
2. Okta / PKCE Authentication and Token Handling
- Map the browser PKCE flow
- Identify the exact token(s) consumed by Loom and by the gateway
- Validate issuer at the actual enforcement point
- Validate audience
- Validate expiry
- Validate signature
- Validate intended token type
- Check logout behavior
- Check expiry behavior
- Check token exposure in URLs
- Check token exposure in logs
- Check token exposure in browser storage
- Check for accidental forwarding of tokens to model/provider layers
Note
Future CLI authentication is excluded unless actually enabled — see GForge - Current vs Planned Capabilities.
3. Authorization, Projects, and Chat/History Isolation
Warning
The demo visibly included Projects and Chat History, but the role/ownership model is unknown. Establish expected behavior first.
Step 1 — establish the model:
- Determine whether conversations are private, shared, team-scoped, or administrative objects
- Determine the same for Projects
- Determine what roles exist (normal user, admin, support, project owner, etc.)
Step 2 — then test boundaries:
- Validate object identifiers cannot cross the intended user boundary
- Validate object identifiers cannot cross the intended team boundary
- Validate function-level boundaries per role
- Test chat history access across identities
- Test project access across identities
- Test configuration / model settings access per role
Important
Do not label a cross-user behavior as a vulnerability until the expected sharing model is confirmed.
4. AI Gateway Routing and Policy Enforcement
- Determine which request fields the client can influence: model
- …provider
- …route
- …timeout
- …generation parameters
- …metadata
- …tenant / user context
- Validate that only approved models/routes can be reached
- Validate that server-side policy cannot be overridden by modified client requests
- Confirm upstream credentials are never returned to the client
- Confirm provider-specific internals are never returned to the client
- Verify failure modes are safe (no internal hosts, credentials, or provider detail in errors)
Note
If governance / budget / rate controls are not yet implemented, document the current control model accurately rather than testing nonexistent features.
5. Direct Prompt Injection and System-Context Protection
- Establish whether Loom/GForge adds system instructions
- …policies
- …hidden context
- …model-routing metadata
- Test whether user prompts can cause disclosure of hidden instructions
- …internal context
- …secrets or credentials
- …sensitive operational metadata
Important
Differentiate harmless instruction-following or jailbreak behavior from security impact. A meaningful finding needs a protected asset or control boundary that is actually bypassed. See GForge - Findings > Finding Discipline.
Note
Indirect prompt injection is future-scope unless tools, retrieval, or connectors are enabled.
6. Sensitive Information Disclosure
Check for tokens, secrets, internal URLs, stack traces, environment variables, user identifiers, or prior-user content in:
- Model responses
- Error messages
- Streaming events
- Browser responses
- Logs
- Diagnostics
- Verify chat/history storage and retention once the storage layer is confirmed
Warning
Use synthetic test data. Do not seed real secrets into prompts merely to prove that a model can repeat them.
7. Improper Output Handling in Loom
Treat model output as untrusted content at the UI boundary.
- Validate Markdown rendering
- Validate HTML rendering
- Validate link handling
- Validate code blocks
- Validate previews
- Validate any other rich content for safe browser handling
Note
If the UI later supports tools, files, or plugins, reassess output-to-action boundaries separately.
8. Resource Consumption and Cost-Abuse Controls
Warning
Spending and rate governance is described as future work. Confirm what limits exist today before testing, and stay within approved thresholds.
- Confirm current rate limits / quotas
- Test oversized prompts
- Test long generations
- Test repeated requests
- Test concurrency
- Test cancellation behavior
- Measure operational impact without creating uncontrolled model spend or availability risk
9. Secrets and Runtime Configuration
- Trace only the approved application-facing portions of Vault → SSM → secret injection
- Validate environment-injected secrets are not exposed in client-side bundles
- …API responses
- …debug endpoints
- …model prompts
- …logs
- Confirm service identities follow least privilege
Warning
Avoid turning this into a standalone Vault pentest unless explicitly scoped — Vault API - Pentest Game Plan.
Path detail → GForge - Architecture > Supporting Secret and Configuration Path
10. Dependency, Open-Source, and Configuration Risk
- Identify the actual deployed LibreChat version and configuration
- Review Snyk findings as input
- Review dependency / configuration posture
- Focus manual effort on runtime exploitability and architecture-specific control failures
Important
Do not report generic upstream weaknesses unless the deployed build/configuration is demonstrably affected.
Snyk split → GForge - Pentest Game Plan > Snyk vs Manual Effort
11. Environment Separation and Staging Parity
- Confirm staging is representative for authentication
- …gateway routing
- …model configuration
- …network policy
- …secret structure
- Ensure staging uses safe / synthetic data
- Ensure staging does not inherit production credentials unnecessarily
- If production validation is approved, keep it minimal, low-volume, and specific to confirming a staging finding
Out of Scope by Default
Warning
Do not build active test cases for these unless they are confirmed enabled and approved in staging.
| Area | Reason |
|---|---|
| CLI authentication | Planned / future |
| Agentic email / Teams / GitHub connectors | Planned / future |
| Indirect prompt injection | Requires tools / retrieval / connectors |
| Excessive agency / tool authorization | Requires agent capability |
| Budget governance bypass | Enforcement does not yet exist |