GSoC 2026 – Interactive Security Policy & Sandbox Wizard: Policy Engine + Guided CLI Architecture Proposal

[Karman580]

Hi everyone,

I’m Karman Singh Talwar, a second-year Computer Engineering student at Thapar Institute of Engineering & Technology (India). I’ve been exploring the Gemini CLI repository over the past few days and I’m very interested in contributing to Idea #9 – Interactive Security Policy / Sandbox Wizard.

After studying the sandbox system, policy discussions, and recent issues/PRs, I tried to approach the problem from a systems architecture perspective. The current workflow requires developers to manually configure Seatbelt profiles and Docker mounts, which exposes low-level sandbox primitives directly to users. This can easily lead to over-permissive configurations or difficult debugging when policies fail.

To explore a structured solution, I prepared a detailed technical proposal for this project.

Proposal:
https://drive.google.com/file/d/17TF9aNlaPpPTVEpv6JE7YWq_nL5Sp4wg/view?usp=sharing

The proposal focuses on introducing a policy abstraction layer and guided configuration workflow, including:
• A structured .gemini/policy.json schema as the canonical project-level sandbox policy
• An interactive Ink-based wizard (gemini sandbox-setup) implemented as a finite-state workflow
• Real-time validation and conflict detection for filesystem, network, and execution permissions
• Deterministic synthesis of Seatbelt profiles and Docker sandbox configurations
• A terminal audit dashboard (gemini sandbox-audit) for reviewing active sandbox permissions
• CI-friendly policy validation via gemini sandbox-validate

The architecture separates the system into four independent layers:
1. CLI command layer
2. Wizard UI layer (React + Ink FSM)
3. Policy engine (validation, minimization, risk scoring)
4. Sandbox synthesis layer (Seatbelt + Docker config generation)

This separation ensures the policy engine remains UI-agnostic, testable, and reusable, allowing future sandbox backends to be added without modifying the wizard itself. 

Questions for mentors (especially @galz10 )

I would really appreciate guidance on a few architectural points while refining the proposal:

1. Policy as the canonical abstraction
   Should .gemini/policy.json become the single source of truth for sandbox configuration, allowing additional backends in the future (e.g., seccomp or Landlock), or should the wizard remain tightly coupled to the current Seatbelt + Docker setup?

2. Conflict handling for nested permissions
   When a parent directory and a child directory define different permission sets, would you prefer:
   • automatic policy minimization / dominance resolution, or
   • requiring explicit user intervention inside the wizard to resolve conflicts?

3. Scope of the sandbox audit dashboard
   For gemini sandbox-audit, should the dashboard remain a pure permission inspection tool, or would it be useful to include derived metrics such as policy risk scoring or template deviation indicators?

Looking forward to contributing to Gemini CLI and learning more about the sandbox and policy system as I continue exploring the codebase.

Thank you for taking the time to review my proposal and for any guidance you may have.

I’ve also already signed the Google CLA.

Karman Singh Talwar
Computer Engineering – Thapar Institute of Engineering & Technology
ktalwar_be24@thapar.edu
flyingoffkarmansinghtalwar@gmail.com

[aniruddhaadak80]

From my point of view, the strongest part of this proposal is separating the policy engine from the wizard UI. If policy.json becomes the canonical layer, I would keep the first audit view very explainable before adding heavier scoring features, because users need to understand why a permission is risky before they trust any derived risk number. Explicit conflict resolution with clear explanations would probably matter more than automatic minimization in the first version.