pentest gforge loom ai-gateway genai prompt-injection okta aws appsec api-security
GForge — Security Model
Trust boundaries, identity, authorization, model-routing policy, secret handling, and AI-specific security principles for GForge / Loom.
Component detail → GForge - Architecture. Test execution → GForge - Test Cases.
Trust Boundaries
| Boundary | Intended Control | Confidence |
|---|---|---|
| Corporate VPN / VPC | Restricts reachability to internal network paths | Confirmed placement; enforcement to verify |
| Loom UI session | Browser session established after Okta login | Confirmed flow |
| Okta / PKCE | Establishes user identity | Confirmed |
| Token validation at the AI Gateway | Gateway must validate the correct identity context | To Confirm where enforced |
| Loom object authorization | Ownership of chats, projects, history | To Confirm — model unknown |
| AI Gateway policy | Approved models, providers, routes, request policy | Confirmed as the intended enforcement point |
| Model context | Secrets and system context must stay out of prompts | Principle; implementation to verify |
| Secret injection | Runtime secrets must not reach browser, responses, logs, or model context | Path confirmed; exposure to verify |
| Environment separation | Staging vs production isolation and parity | Staging confirmed to exist |
Important
The AI Gateway — not the client — must remain the authoritative enforcement point for approved models, routes, providers, and request policy.
Warning
“Internal-only” is not equivalent to “trusted user”. VPN placement is one boundary. Application controls must still enforce identity and permissions independently.
Authentication — Okta / PKCE
Confirmed
Okta with PKCE is the current browser authentication flow. The gateway receives / validates user token context.
Areas requiring validation:
- Which Okta token the gateway validates, and the expected issuer, audience, scopes, and claims
- Where PKCE is terminated versus where token validation is actually enforced
- Token acceptance rules, session lifecycle, logout and expiration behavior
- Token exposure in URLs, logs, or browser storage
- Whether tokens are accidentally forwarded to model or provider layers
To Confirm
The exact token type and validation point. Do not assume the UI-level login implies gateway-level enforcement.
Note
A separate CLI authentication flow was described as planned. It is out of current scope unless enabled for test — see GForge - Current vs Planned Capabilities.
Authorization and User-Data Isolation
Warning
The role and ownership model is unknown. The demo visibly included Projects and Chat History, but their sharing semantics were not established.
Required order of work:
- Determine the actual user / role / project / chat ownership model.
- Establish whether conversations and projects are private, shared, team-scoped, or administrative objects.
- Only then validate object-level and function-level boundaries using approved test identities.
Important
Do not label a cross-user behavior as a vulnerability until the expected sharing model is confirmed. A shared-by-design project is not an IDOR.
Open items → GForge - Kickoff Questions > Authentication and Authorization
AI Gateway and Model-Routing Policy
The gateway’s central purpose is to govern model access. Security depends on server-side policy, not UI options.
What to establish:
| Question | Why It Matters |
|---|---|
| Which request fields can the client influence? (model, provider, route, timeout, generation parameters, metadata, tenant/user context) | Defines the client-controlled attack surface |
| Can only approved models and routes be reached? | Core gateway control |
| Can modified client requests override server-side policy? | Policy bypass risk |
| Are upstream credentials or provider internals ever returned to the client? | Credential and internal-detail disclosure |
| Are failures safe? | Errors should not disclose upstream credentials, internal hosts, or provider details unnecessarily |
Warning
Budget enforcement and rate-limit governance were described as future capability. Document the control model that exists today rather than testing features that do not yet exist.
Secrets and Runtime Configuration
Confirmed path: Internal Vault → AWS SSM Parameter Store → External Secrets Operator → application environment variables.
Security expectations to validate:
- Environment-injected secrets must not be exposed to client-side bundles, API responses, debug endpoints, model prompts, or logs
- Service identities reaching Bedrock, SSM, or related services should follow least privilege
- Only approved application-facing portions of the path should be traced
Warning
Do not expand this into a standalone Vault pentest unless explicitly scoped. Vault is a separate engagement — Vault API - Pentest Game Plan.
Path detail → GForge - Architecture > Supporting Secret and Configuration Path
Environment Separation and Staging Parity
| Requirement | Detail |
|---|---|
| Parity | Staging should be representative of production for authentication, gateway routing, model configuration, network policy, and secret structure |
| Data safety | Staging should use safe / synthetic data and should not inherit production credentials unnecessarily |
| Production testing | If approved, keep it minimal, low-volume, and specific to confirming a staging finding |
AI-Specific Security Principles
Source guidelines and their security meaning.
| Guideline | Security Meaning |
|---|---|
| Prompt is data, not authority | User/model text must not be able to modify gateway policy, model allowlists, credentials, identity, or control-plane configuration |
| Model output is untrusted | Loom should render and consume output safely; future agents must not automatically turn arbitrary model output into privileged actions |
| No secrets in model context by default | Operational credentials and environment secrets should never become prompt context unless there is an explicit, controlled need |
| Identity must survive the full path | Authentication at the UI is insufficient if downstream gateway policy cannot reliably associate requests with the authenticated user/context |
| Server-side model governance | Allowed providers / models / routes should be decided by trusted server policy, not merely UI options |
| Bounded consumption | Even internal users can create accidental or intentional cost/availability pressure; enforce practical limits and observability |
| Audit important decisions | Model/route selection, authentication failures, policy denials, administrative changes, and unusually costly use should be traceable — without logging sensitive prompt content unnecessarily |
| Future agents require a new threat model | When email, Teams, GitHub, or other tools are connected, reassess indirect prompt injection, tool authorization, excessive agency, data exfiltration, and human approval boundaries |
Current Controls — Status Summary
| Control Area | Status | Note |
|---|---|---|
| Network exposure restriction | Confirmed placement | Enforcement to verify |
| Okta / PKCE authentication | Confirmed | Validation point to verify |
| Gateway model allowlist / policy | Intended | Implementation to verify |
| Authorization / object ownership | Unknown | Model must be confirmed first |
| Rate limits / quotas | Unknown | Governance described as future |
| Budget enforcement | Planned | Not implemented — residual risk today |
| Bedrock guardrails | Unknown | To confirm at test time |
| Secret injection isolation | Path confirmed | Exposure to verify |
| Audit / logging coverage | Unknown | Tester-accessible logs to confirm |
Note
Where a planned control does not yet exist, record it as current residual risk rather than assuming future controls already protect the service.