Set release boundaries for the tool registry runtime

Operational risks for the calculator + knowledge lookup tool registry center on registering shell-exec as a 'helper' tool, plus the earlier failure mode (string-eval calculator, or lookup that returns entire DB on missing id). Safety lives in executable gates, allowlists, redaction, and a named owner—not in a warning paragraph under an unsafe function.

function authorize(ctx: Context, action: Action) {
  if (!ctx.permissions.has(action.permission)) {
    throw new SafeError("forbidden");
  }
  if (action.risk === "write" && !ctx.approvalToken) {
    throw new SafeError("approval_required");
  }
}

Expected evidence: duplicate names, stale schemas, timeouts, oversized results, and unsafe side effects. A failed assertion means stop, investigate, and do not publish the tool registry runtime.

Name who can disable the feature, what data is retained, and how to roll back to the last known good artifact. Pin the reviewed configuration (versions, thresholds, allowlists) so “what shipped” is reconstructable for tools-in-code.

Write the release blocker as a predicate, not a feeling: “Do not ship the tool registry runtime if registering shell-exec as a 'helper' tool.” Pair it with a passing control that shows the reviewed configuration still works for registry with calc and kb.lookup. Name an owner and a rollback handle (git tag, docs_version, previous image).

Security pages must not paste the happy-path demo. If your gate code looks like the implementation page, replace it with a deny/allow check aimed at registering shell-exec as a 'helper' tool.

State the data retention rule in one line (what is stored, for how long, who can read it). Then state the kill switch (env flag, config pin, or feature owner). The tool registry runtime is not shippable without both, even when allowlist reject count; schema validation failures; successful typed results looks healthy.

At the safety and operations stage for tools-in-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about registry with calc and kb.lookup that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: inline if/else tool routing without schemas.

For this page specifically, success looks like an executable deny gate for the lab-specific threat while still centering the user decision to route model tool requests through a registry that validates names and args. If you cannot point to a file, command, or assertion that proves that for the tool registry runtime, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Previous · Next