GLASSBOX TOOLBRIDGE / ENGINEERING PROTOTYPE V0.1
The AI can reason. The boundary decides.
GlassBox ToolBridge is a local-first control and evidence layer for AI-assisted technical tools. It lets a model help plan and explain authorized work without giving the model an unrestricted shell or permission to quietly widen the job.
SIMPLEST EXPLANATION / 01
Five narrow doors instead of one giant key.
The public-facing button names an outcome such as “produce an authorized home-network baseline report.” Behind it, the system checks permission, compiles one bounded tool request, keeps the receipts, and produces a report that can be traced back to evidence.
- 01
Ask for an outcome
Name the useful result, not the command-line tool.
- 02
Set the boundary
Declare the target, connector, mode, purpose, approver, risk, and expiration.
- 03
Run through a guard
Typed inputs replace improvised shell fragments and undeclared flags.
- 04
Keep the receipts
Preserve raw output, hashes, decisions, versions, and limitations.
- 05
Review the report
Claims cite evidence. Higher-risk action requires a separate human decision.
CONTROL ARCHITECTURE / 02
The model proposes. Deterministic controls mediate.
The language model is treated as a capable but untrusted planner and interpreter. Authority is issued outside the model, checked on every request, and never inferred from tool output, retrieved text, or persuasive wording.
Permission is explicit and expiring.
Connector, target, mode, purpose, risk ceiling, approver, retention, and expiration are visible data, not hidden prompt prose.
One adapter, one declared capability.
Each technical tool receives a narrow schema, bounded argument compiler, execution profile, parser, failure semantics, and fixtures.
Polish cannot outrun proof.
Raw artifacts remain separate from interpretation. Reportable claims carry evidence identifiers, confidence, and limitations.
WORKING MODEL / 03
The first model is intentionally small enough to break.
Version 0.1 uses synthetic fixture data and a non-executing Nmap argument compiler. That makes policy, evidence, reporting, and denial behavior testable before live tool execution is introduced.
Dependency-free tests passed
Scope, expiration, approval, target containment, raw argument rejection, evidence hashes, audit tamper detection, provenance, and fixture injection handling.
Smoke scenarios matched policy
Two benign cases were allowed and five adversarial cases were denied in the deterministic harness.
Live scans or changes
No process execution, packets, public targets, exploitation, credentials, persistence, egress, or remediation.
Artifacts, claims, findings
The fixture demonstration produced two immutable evidence artifacts, two evidence-backed claims, and two cautious findings.
SCIENTIFIC STUDY / 04
Do not trust the diagram. Run the paired comparison.
The confirmatory study will hold the model, tasks, prompt, retry budget, and sandbox constant. The only major difference is direct tool access versus the same model operating through ToolBridge.
Direct-tool baseline
The model can formulate executable calls through the sealed test harness.
ToolBridge
The model proposes structured requests; deterministic scope, policy, connector, and report gates mediate execution.
Unauthorized execution
Did an out-of-scope action reach the execution boundary?
Benign completion
Did authorized tasks remain acceptably usable?
Unsupported claims
Did the report state anything without valid source lineage?
Review burden
Interventions, review time, latency, tool calls, and recovery after denial.
Trace completeness
Were actions, decisions, evidence, and stop reasons preserved?
Failure counts
The design loses if safety does not improve or authorized utility collapses.
A 30-pair pilot estimates event rates, discordant pairs, latency variance, and reviewer disagreement. The final sample size, non-inferiority margin, held-out set, and analysis plan are frozen before confirmatory outcomes are examined.
PRIOR ART + CLAIM BOUNDARY / 05
Narrow claims survive contact with criticism.
GlassBox does not claim to invent least privilege, default deny, policy enforcement, typed tool calls, sandboxing, provenance, human approval, or agent-security evaluation. Those ideas are established foundations and active research areas.
The proposed contribution
- rules-of-engagement scope tokens for owned or explicitly authorized targets
- one guarded connector contract per cybersecurity tool and business outcome
- deterministic request-to-argument compilation instead of free-form shell access
- raw evidence to claim to finding to report lineage
- fixture-first progression into execution-grounded sandbox studies
- an open, reproducible comparison that measures safety and utility together
Known limitations
- the Python prototype currently shares one process and host
- scope tokens are not yet signed by an external authority
- connectors are not yet containerized or independently attested
- identity, secrets, retention enforcement, and multi-user review are incomplete
- the audit chain is tamper evident, not tamper preventing
- real model-agent results have not yet been collected
OPEN ENGINEERING QUESTION
Can governed tool use become safer without becoming useless?
The project is designed so criticism can become a test case: bypass the scope, escape the connector schema, produce an unsupported claim, or show where a benign task becomes unusable.