Skip to content

secureide-workbench.boundary-model.md

Latest commit

 

History

History
83 lines (59 loc) · 3.65 KB

secureide-workbench.boundary-model.md

File metadata and controls

83 lines (59 loc) · 3.65 KB
Raw

Secure AI Coding Tool Boundary Model

Purpose

This document closes public issue #3: Document safe tool execution boundaries for an AI coding workbench and add a local proof path.

It provides concrete agentic-enterprise evidence for SecureIDE Workbench. The repo remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

AI-assisted code execution, file mutation, package installation, terminal command execution, and workspace export.

Actors

Actor Responsibility
Developer Owns the workspace session and approves changes before they leave the sandbox.
AI coding assistant Can propose edits, commands, and explanations but cannot be treated as an authorized deployer.
Workspace runtime Executes approved commands inside a bounded development environment.
Maintainer Reviews pull requests, evidence, and security-sensitive changes.

Identity Boundary

  • Every workspace session must be associated with a human developer identity.
  • The AI assistant never owns credentials; it only operates through scoped session capabilities.
  • Export, publish, or deploy actions require explicit human ownership and review.

Tool And Action Boundary

Action Boundary
read_file Allowed inside the repository unless the path is documented as secret-bearing.
write_file Allowed for issue-scoped product files; must be visible in Git diff.
run_command Allowed only for documented local validation commands and package-manager actions approved by the human operator.
install_dependency Requires package purpose, license consideration, and lockfile review.
export_workspace Requires maintainer approval and secret scan before sharing.

Human Approval Gates

  • Before installing or upgrading dependencies.
  • Before running commands that mutate databases, credentials, git history, or deployment state.
  • Before exporting generated code outside the sandbox.
  • Before opening a PR that changes security, auth, runtime isolation, or provider behavior.

Audit Event Model

Event Minimum Evidence
workspace.session_started developer id, repo, branch, runtime image, timestamp
agent.proposed_action action type, files or command, stated intent, risk class
human.approved_action approver, action id, approval note
runtime.command_completed command, exit code, duration, sanitized output pointer
workspace.export_requested target, files included, secret scan status

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint to prove static project health.
  • npm run test when available for workflow-level assertions.
  • npm run build to prove the application compiles.
  • Record any missing provider, sandbox, or secret dependency as a blocker instead of claiming production readiness.

OSS And Self-Hosted Fallbacks

  • Use local Docker sandboxing before paid remote execution providers.
  • Use Ollama or vLLM adapters for local model experimentation where feasible.
  • Use PostgreSQL event/audit tables instead of a hosted-only realtime audit store.
  • Keep WebContainer, Convex, or hosted deployment providers behind explicit adapters.

Contributor Follow-Up

Add a small policy fixture that classifies proposed actions as read, write, command, dependency, export, or deploy.

Issue Closure Evidence

This document satisfies the issue checklist by separating:

  • identity or actor boundary
  • tool/provider/action boundary
  • human approval or escalation point
  • audit or observability events
  • OSS/self-hosted fallback direction
  • validation and static inspection path