pentest gforge loom ai-gateway genai appsec scope

GForge — Current vs Planned Capabilities

Scope guard for the engagement. GForge contains substantial roadmap functionality — this note keeps live capability separate from future capability so planned features do not silently enter scope.


Capability Matrix

CapabilityStateConfidencePentest Implication
Loom / LibreChat web UICurrentConfirmedPrimary user-facing surface
AI Gateway model proxyCurrentConfirmedPrimary service under test
AWS Bedrock model routingCurrentConfirmedGLM 5 stated as enabled in production
Okta + PKCE authenticationCurrentConfirmedCurrent browser authentication flow
Internal-only VPN / VPC placementCurrentConfirmedNetwork boundary; not a substitute for app-layer controls
Vault → SSM → secret injectionCurrentConfirmedSupporting runtime configuration path
Snyk repository integrationIn progressConfirmed workstreamUse available results as testing input
Budget enforcementPlannedConfirmed futureDo not assume implemented
Rate-limit governancePlannedConfirmed futureCurrent controls must be verified rather than assumed
CLI access + separate auth flowPlannedConfirmed futureOut of current scope unless enabled for test
Agentic email / Teams / GitHub workflowsPlannedConfirmed futureExcessive-agency / tool testing becomes relevant only when implemented
Additional / self-hosted modelsPlannedConfirmed futureModel governance protocols are being defined
Direct Hugging Face enablementNot plannedConfirmedMeeting explicitly stated models would be governed/hosted through AWS rather than direct Hugging Face enablement

Scope Guardrail

Warning

Do not spend current-test time on agent tool permissions, email/Teams/GitHub connectors, CLI authentication, or budget enforcement unless those functions are actually present and approved in staging at test time.


Model Enablement

ModelStateConfidence
GLM 5Production-enabled at meeting timeConfirmed
Kimi 2.5Future / plannedConfirmed as future
Qwen 2.5Future / plannedConfirmed as future
Self-hosted / open-source routesFuture / plannedConfirmed as future

To Confirm

  • Is GLM 5 still the only production-enabled model at test time?
  • Are Kimi / Qwen / self-hosted models enabled in staging?

Residual Risk from Missing Controls

Because governance features are roadmap items, the absence of a control is itself worth documenting.

Missing / Planned ControlCurrent Residual Risk
Budget enforcementUncontrolled model spend is not prevented by design today
Rate-limit governanceRequest-volume abuse depends on whatever limits exist today — must be measured, not assumed
Broader model governance protocolsModel/provider policy scope is still being defined

Note

Report these as current residual risk with planned mitigation, not as bypassed controls. A control that does not exist cannot be bypassed.


Feature Confirmation Checklist

Run this at kickoff before writing test cases.

  • Which functions are definitely enabled in staging on day one?
  • Are uploads enabled?
  • Is retrieval / RAG enabled?
  • Are plugins enabled?
  • Is browsing enabled?
  • Are tools / connectors enabled?
  • Is code execution enabled?
  • Is CLI access enabled?
  • Are agentic workflows (email / Teams / GitHub) enabled?
  • Which budget / rate controls are actually implemented today versus roadmap?
  • Which Bedrock guardrails or model-governance controls are currently active?

Important

If a feature is not enabled, explicitly exclude it in the scope record rather than leaving it ambiguous.


Testing Priority by State

Everything marked P3 in the priority matrix is future capability and stays out of active testing by default:

P3 AreaBecomes Testable When
CLI authenticationImplemented and in scope
Agentic tool permissions / indirect prompt injectionTools, retrieval, or connectors are enabled
Budget governance bypassEnforcement actually exists

Full priority matrix and methodology → GForge - Pentest Game Plan > Priority Matrix