pentest gforge loom ai-gateway genai prompt-injection okta aws appsec api-security
GForge — Pentest Game Plan
Methodology, frameworks, phases, priorities, and guardrails for the GForge / Loom / AI Gateway engagement.
Architecture → GForge - Architecture. Test detail → GForge - Test Cases. Scope guard → GForge - Current vs Planned Capabilities.
Working Principle
Important
Understand the current GForge/Loom security model first, test the enforcement points second, and keep planned/future capabilities out of scope unless they are actually enabled in the approved test environment.
Primary target concept: internal Loom web experience + AI Gateway path to approved models.
Core Security Question
Important
Can an authenticated internal user make Loom or the AI Gateway perform actions, access data, invoke models/routes, or expose information beyond what that user and the approved application workflow are intended to permit?
Primary Objectives
- Validate that the internal-only service boundary is actually enforced and that unintended external paths do not expose Loom or the AI Gateway.
- Validate the Okta/PKCE authentication and token-validation chain without assuming that VPN access alone is sufficient.
- Understand and validate authorization for user-owned or shared objects that actually exist (for example chat history or projects visible in the UI) before attempting cross-user tests.
- Validate that the AI Gateway, not the client, remains the authoritative enforcement point for approved models, routes, providers, and request policy.
- Assess prompt/model interaction controls without conflating normal model behavior with a security vulnerability.
- Validate that secrets, tokens, configuration, system context, and internal metadata do not leak through prompts, model responses, errors, logs, or browser-visible data.
- Assess availability/resource abuse within agreed rate and cost guardrails — especially because budget/rate governance is described as future capability.
- Review the supporting cloud/runtime boundary (least privilege, secret injection, environment separation) without turning the test into an unrestricted AWS assessment.
Framework Stack
| Framework | Use | How to Apply Here |
|---|---|---|
| PTES / NIST SP 800-115 | Engagement lifecycle | Scoping, discovery, controlled testing, evidence, reporting, retest |
| OWASP API Security Top 10 | Gateway / API risk lens | Authentication, object/function authorization, resource consumption, misconfiguration, unsafe API consumption |
| OWASP ASVS | Control verification | Authentication, session/token handling, access control, data protection, logging, configuration |
| OWASP WSTG | Loom web / UI testing | Browser flow, session behavior, input/output handling, client-side security |
| OWASP Top 10 for LLM Applications | GenAI-specific lens | Prompt injection, sensitive information disclosure, improper output handling, supply chain, unbounded consumption — only where implemented features make them applicable |
| AWS security / IAM guidance | Cloud boundary | Least privilege, Bedrock access, SSM/KMS-related permissions, logging, network controls |
| MITRE ATLAS (optional) | AI attack-technique mapping | Useful for reporting/coverage mapping; not required to drive every test |
Testing Phases
Phase 0 — Scope Freeze and Evidence Intake
- Obtain ticket scope, target URLs/hosts, repositories, architecture diagram, approved staging identities, exclusions, and production restrictions
- Record current vs planned capabilities so roadmap items do not silently enter scope → GForge - Current vs Planned Capabilities
- Review available Snyk results before manual testing
Phase 1 — Architecture and Trust-Boundary Mapping
- Map Loom, AI Gateway, Light LLM, Bedrock, Okta, GEL hosting, Vault/SSM secret path, logging, and any data stores actually present
- Identify where authentication is performed and where authorization/policy decisions are enforced
- Confirm whether Loom and the AI Gateway have separately reachable endpoints
Phase 2 — Baseline Behavior and Endpoint Inventory
- Capture normal login, chat creation, model request, streaming/response, history, project, logout, and error flows that actually exist
- Build an endpoint/function inventory from browser traffic and provided API documentation → GForge - Endpoint Inventory
- Identify object identifiers before testing authorization; do not assume UI labels map directly to server-side boundaries
Phase 3 — Network Exposure, Authentication, and Session/Token Controls
- Validate intended internal exposure and authentication enforcement
- Verify token acceptance rules, session lifecycle, logout/expiration behavior, and protection against token leakage or unintended reuse
- Confirm the gateway validates the right identity context rather than trusting client-supplied identity attributes
Phase 4 — Authorization and User-Data Isolation
- Determine the actual user/role/project/chat ownership model first
- Then validate object-level and function-level boundaries using approved test identities
- Focus on chat history, projects, configuration, model settings, or other objects only if they are truly exposed
Phase 5 — AI Gateway and Model-Routing Controls
- Confirm server-side allowlists and policy for model/provider selection
- Test whether client-controlled parameters can bypass intended routing, model governance, or environment restrictions
- Verify failures are safe and do not disclose upstream credentials, internal hosts, or provider details unnecessarily
Phase 6 — GenAI Interaction Testing
- Establish expected system behavior and safety boundaries before interpreting model output
- Test direct prompt injection, system-context leakage, sensitive-information disclosure, and output-handling concerns relevant to the current Loom feature set
- Treat indirect prompt injection and excessive agency as future-scope unless tools/retrieval/connectors are enabled
Phase 7 — Secrets, Cloud/Runtime, and Environment Boundary
- Validate that runtime secrets are not exposed to the browser, model context, responses, logs, or diagnostics
- Review least-privilege assumptions for the service identities used to reach Bedrock/SSM or related services, within agreed scope
- Confirm staging mirrors production sufficiently for security conclusions while keeping real production data out of testing
Phase 8 — Resource Abuse, Resilience, and Logging
- Assess request volume, long prompts/responses, concurrency, and expensive operations only within agreed cost/safety thresholds
- Confirm security-relevant actions are auditable and operational errors are useful without being overly verbose
- Document where planned budget/rate controls create current residual risk rather than assuming future controls already protect the service
Phase 9 — Findings, Clean Validation, and Retest
- Reproduce meaningful issues with minimal evidence in staging
- Separate application findings from model-quality/safety observations → GForge - Findings
- Retest remediation and update status with exact environment/model/build context
Priority Matrix
| Priority | Area | Applicability | Reason |
|---|---|---|---|
| P0 | Scope / architecture confirmation | Before testing | Prevents testing roadmap features or wrong boundaries |
| P1 | Network exposure + Okta/PKCE/token validation | Current | Core external/internal and identity boundary |
| P1 | Authorization / chat-project-history isolation | Current if objects exist | High impact if cross-user access is possible |
| P1 | Gateway route/model policy enforcement | Current | Central purpose of the gateway |
| P1 | Sensitive information / secret leakage | Current | Protect tokens, runtime secrets, prompts, prior-user data |
| P2 | Direct prompt injection / system-context leakage | Current | Validate actual control impact, not merely jailbreak behavior |
| P2 | Unsafe model-output rendering | Current Loom UI | Model output is untrusted browser content |
| P2 | Resource / cost abuse | Current controls unknown | Budget/rate governance is roadmap; test safely |
| P2 | Secrets / runtime / cloud boundary | Current supporting path | Within approved application scope |
| P2 | Dependency / config + Snyk correlation | Current / in progress | Avoid duplicate automated effort |
| P3 | CLI auth | Future | Test only when implemented and in scope |
| P3 | Agentic tool permissions / indirect prompt injection | Future | Major future threat model, not current by default |
| P3 | Budget governance bypass | Future | Only meaningful after enforcement exists |
Testing Environment and Safety Guardrails
Warning
These constraints apply throughout the engagement.
- Primary environment: staging/test that mirrors production as closely as possible
- Use synthetic prompts, synthetic secrets, and approved test identities
- Do not intentionally cause uncontrolled LLM spend, sustained denial of service, or large-scale concurrency
- Do not test future agentic email/Teams/GitHub access unless explicitly enabled and approved
- Do not test production beyond explicit, minimal parity validation
- Do not place real credentials, employee data, or confidential production content into prompts for testing
- Coordinate any tests that may generate unusually high model usage, large logs, alerting, or cloud costs
- Preserve exact model/version/environment context in evidence — AI behavior can change across models and builds
Snyk vs Manual Effort
Snyk integration across repositories, including the AI Gateway, was described as in progress. Use Snyk as evidence and triage input; concentrate manual testing on controls that static/dependency tooling cannot reliably prove.
| Workstream | Best Use |
|---|---|
| Snyk / automated review | Known vulnerable dependencies, static code patterns, configuration findings, repository-level issues |
| Manual pentest | Network exposure, auth/token flows, authorization, cross-user isolation, gateway routing, runtime secret leakage, prompt/control boundaries, unsafe output rendering, abuse scenarios, staging behavior |
| Joint review | A Snyk issue with reachable runtime impact, or a manual finding whose root cause is visible in source/dependency configuration |
General Snyk context → GEL - Integrations > Snyk
One-Page Working Checklist
- Architecture diagram and repositories received
- Exact staging URLs/hosts and API base paths confirmed
- Current features separated from roadmap features
- Multiple approved test identities/roles available where authorization testing requires them
- Normal Okta/PKCE login and token path captured
- Normal Loom → Gateway → model request/response path captured
- Endpoint/function inventory built before negative testing
- Projects/chat-history ownership model confirmed before IDOR/BOLA conclusions
- Gateway model/provider routing policy understood
- Current rate/budget limits confirmed rather than assumed
- Prompt injection testing tied to real protected assets/controls
- Output rendering checked as untrusted content
- Secrets/tokens checked across browser, API, logs, model context, and errors
- Snyk findings reviewed and de-duplicated against manual work
- Staging/production parity assumptions documented
- Evidence records exact model/build/environment/identity context
- Planned CLI/agentic features excluded unless explicitly enabled and approved
Suggested Deliverables
- Architecture/trust-boundary sketch updated from the kickoff diagram
- Endpoint/function inventory for Loom and AI Gateway
- Current-vs-planned capability/scope matrix
- Test-case tracker mapped to OWASP API / ASVS / WSTG / LLM categories where applicable
- Evidence log with identity, endpoint, model, prompt class, expected/observed behavior, and sanitized artifacts
- Findings report separating application/control vulnerabilities from non-security model behavior observations
- Retest record and residual-risk notes for controls still planned (for example budget/rate governance)
Final Working Principles
- Understand the current product before testing the roadmap.
- Treat VPN as one boundary, not the whole security model.
- Trace identity and policy enforcement all the way to the AI Gateway.
- Treat the client, prompts, and model output as untrusted.
- Only call prompt injection a security issue when a real protected control or asset is affected.
- Keep Vault and GEL context visible without accidentally expanding the GForge scope.
- Use Snyk to reduce duplicate work; spend manual time on runtime behavior and trust boundaries.
- Preserve model/build/environment context because AI behavior is variable.
- Test safely around model cost and availability.
- Document unknowns explicitly rather than converting them into architecture facts.
Important
Remember this. The most useful mental model for the current engagement is: authenticated internal user → Loom → AI Gateway policy → approved model route → response. The pentest should prove that every security boundary in that path is enforced as intended, while keeping future CLI/agent capabilities separate until they actually exist.
Relationship to GEL and Vault
GForge/Loom is the AI service under assessment. GEL is the platform GForge is described as deployed on — not automatically in scope. Vault is a separate internal secrets service with its own engagement.
→ GEL - Overview · Vault API - Pentest Game Plan · Genesys Security Architecture - Overview