feat(agent): enforce GPT-OSS safeguard decisions

[AnthonyRonning]

Summary

• quarantine flagged, incomplete, or indeterminate untrusted ToolResponse content before it reaches the primary model, replacing it with a fixed protocol-level warning
• classify ordinary model-proposed tool and MCP calls synchronously; only explicit auto-execute clearance preserves current automation, while risky or unresolved calls use the existing Maple approval prompt regardless of Auto, readOnlyHint, or classifier shortcuts
• use the attested Tinfoil Rust client with versioned policies, strict structured responses, bounded preprocessing/request work, and payload-free latency telemetry
• pin the single reviewed Goose support commit from Harden guarded tool execution boundaries goose#1, based on the independently synchronized fork main
• add a credential-safe build-then-launch runner and document privacy, coverage, fail-closed behavior, operating limits, and initial live observations

Enforcement boundaries

This remains an opt-in proof-of-concept experiment. It covers the normal Maple provider/tool loop. Guarded sessions disable Goose compaction and delegation so raw tool history cannot bypass the classifier through those paths. Unsupported binary/image output, incomplete coverage, classifier failure, malformed responses, and missing credentials fail closed: tool output is withheld and proposed actions require explicit approval.

The model never grants authority. Deterministic Maple and Goose policy can still deny an action, and GPT-OSS can only preserve current automation or tighten it to explicit approval.

Validation

• repository pre-commit hook: frontend build, 587 frontend tests, and Rust tests passed
• locked Maple library suite: 382 passed, 2 ignored
• focused safeguard suite against final Goose pin: 63 passed
• just rust-lint
• git diff --check
• Goose support remains exactly one commit atop synchronized fork main: 8362ed49ff8a8fcbbbfdaa3b28dc6eb1da13a0b5

Initial live experiment

The VM-provisioned Tinfoil credential was found and used through the documented shared-secret runner. Individual observations, not a benchmark:

• benign pwd: auto-cleared as read-only; 3,075 ms cold total, followed by a benign output verdict in 1,161 ms
• file write while Maple displayed Allow all: classified require_approval in 856 ms; Maple showed the existing prompt, denial prevented the write
• hostile file read: action auto-cleared as read-only in 1,194 ms; output classified as injection/instruction override in 1,198 ms and raw content was withheld

That run exposed a false positive on Goose's synthetic user-denial response. The final Goose pin adds typed, exact-shape control provenance so canonical Goose denial/cancellation responses bypass the untrusted-output lane while identical tool/MCP text remains untrusted. Unit coverage is green; a post-fix exact-app rerun is intentionally left as follow-up rather than expanding this POC further.

Research background: OpenSecretCloud/master#39.

Scope

Draft proof of concept. Thorough production review, broader coverage work, latency evaluation, and rollout policy remain follow-ups.

[cloudflare-workers-and-pages]

Deploying maple with    Cloudflare Pages

Latest commit:	ba1715c
Status:	✅  Deploy successful!
Preview URL:	https://d4d39616.maple-ca8.pages.dev
Branch Preview URL:	https://codex-maple-safeguard-maple.maple-ca8.pages.dev

View logs