Tools & packages administration

Two separate things an administrator controls: which platform tools agents may reach and which packages are installed.

Platform tools

Admin → Tools lists the tools discovered from Kamiwaza Core's authenticated OpenAPI and MCP Guard plus Kaizen's closed direct-SDK adapters, grouped by the backend-authored hierarchy Kamiwaza → source → surface → endpoint. The source layer separates Core API, SDK, MCP, and the independently gated external API family. Core surfaces include applications, connectors, skills, workrooms, Context Service, and future authenticated tags; Kaizen does not maintain a catalog of their operation names.

Each change uses the current allow-list version. The screen refreshes that version after a successful change, so consecutive toggles remain safe; if another administrator changes the policy first, Kaizen reports the conflict and reloads the newer selection instead of overwriting it.

The checkboxes on this screen control the global allow-list. Enabling an ordinary platform tool makes it available to be granted. It does not grant it — an agent still has to name the tool in its capability set, and the member running that agent still has to have the underlying permission.

For ordinary platform tools, three gates must all allow a call:

the deployment has the tool enabled,
the agent's capability ceiling includes it,
the member's own permissions allow what it does.

A reviewed public-web binding with "general_enabled": true is a narrow exception for General. Its approval appears separately above the tool tree and may be policy-eligible while the same tool's global checkbox is off. Block this operation for all profiles writes an exact denial while keeping the binding stored; a root, source, or server denial also blocks General. See Configuration for the binding shape and safe revocation order. Existing bindings without that flag show Needs General approval and do not grant General access; their exact operations remain reserved from ordinary MCP catalogs. Unbound Serper operations keep ordinary global-selection behavior for Personal and default assistants, while Data blocks unreviewed raw queries. Approve one by editing its value in Configuration after reviewing its exact provider, operation, schema, and workroom. If the reviewed operation belongs to another workroom, this screen cannot verify its live availability from the administrator's current workroom. It still offers the exact denial for that stored binding; turning an unavailable operation on requires discovery in the administrator's current workroom.

Dynamic tools are discovered again for each run under the signed-in member's forwarded workroom envelope. The underlying Kamiwaza root and source selectors are hard ceilings: turning one off blocks every descendant while preserving the child selection, and turning it back on restores that narrower state. Turning a root or source on does not grant every present or future descendant. Core, MCP, and external sources still require a selected child surface or exact endpoint.

The checkbox at each parent is intentionally an all descendants control, not a raw selector editor. One CAS-protected cascade resolves the subtree on the server. Turning it on clears narrower endpoint exceptions and selects the current surfaces, so all child boxes become checked and future endpoints on those surfaces inherit the choice. Turning it off applies the parent ceiling, so all child boxes become unchecked. Select individual children afterward to create narrower exceptions.

The two closed SDK adapters preserve their compatibility default while the Kamiwaza root, SDK source, SDK surface, and exact adapter remain allowed. They are available to every selected chat agent rather than granted in each agent definition. The agent's read/write capability ceiling and the member's conversation selection can only narrow that inventory; stale names simply disappear rather than becoming an implicit grant. Enabling a surface admits future operations published under that tag, SDK surface, external source, or MCP server. Disable a specific tool afterward to keep it as an exception. Disabling a surface is a hard ceiling over all its current and future operations. For example, disabling Context does not affect Skills, Workrooms, applications, MCP servers, or the SDK source.

Members can narrow the admitted Core, SDK, and MCP inventory per conversation from the composer's Tools menu. Large inventories remain behind runtime tool search: only matching authorized descriptors enter a model step. Discovery caches only bounded shared schema metadata. It does not cache member responses or preload Context Service records, documents, connector data, or skill packages. Broad inventory questions use the metadata-only parent-surface view. Confirm that it reports the SDK/Core parents and truncation count without advertising their endpoint schemas; a later action search should expose only its bounded exact matches.

Treat POST-based reads conservatively. Until a Core operation declares x-kamiwaza-effect: read, Kaizen classifies it as a write and applies the normal confirmation policy. Public routes never enter the catalog. A generated call always forwards the initiating member and current workroom, and Core's live role and resource authorization remains final.

Core writes with generic non-secret config objects remain available for future connector types. Verify that safe settings reach Core under the member envelope and approval gate. Credential-shaped nested keys or credential-bearing URLs must fail before dispatch; explicit authentication and connection-config containers remain absent and use a trusted credential ceremony instead.

External schema sources

External OpenAPI sites appear under the External APIs source only while the separate external-capability feature is enabled. The source switch is a ceiling, not permission for general sandbox egress. Select Source management to let eligible agents manage uncredentialed schema pointers, then select each registered API source independently. Each API source is a surface, so its switch admits current and future endpoints from that schema while exact endpoint exceptions remain available underneath it.

Schema fetch and execution still require the signed sandbox-egress policy. Keep cross-origin schemas, query-string authentication, and credential persistence off unless their separate risk ceilings have been reviewed. Revoking the Kamiwaza root, External APIs source, registered source surface, or exact endpoint invalidates outstanding credential forms without changing unrelated sources.

Direct SDK platform capability

Platform inspection and bounded demo seeding do not require an MCP server. Kaizen exact-pins kamiwaza-sdk==1.2.0 and supplies two first-party tools whenever the Kamiwaza SDK source and exact adapter remain enabled and the member's validated request carries a platform API base, forwarded identity headers, and workroom. Every selected chat agent can use this family; read-only agents receive only its inspection adapter. The SDK source is default-on for compatibility and can be disabled as one unit in Admin → Tools. Verify the envelope by signing in through the normal Kamiwaza app route as a real staff member; do not add a PAT or service credential for this workflow.

inspect_kamiwaza reads bounded workroom, catalog-app deployment, Kaizen-agent, model, model-config, deployment, dataset, extension, and connector inventory. manage_kamiwaza_demo previews or applies only workroom, catalog-extension, model-download, model-deployment, catalog-dataset, and Kaizen-agent ensures. Apply carries the Blueprint digest and the exact environment and preview digests from the preceding preview as deterministic drift checks; those values are not approval credentials. The apply call uses the conversation approval item, then commits with a one-shot receipt only after rechecking the actor, staged request, live environment, and digests. The adapter lists before create and stops when matching state is ambiguous. An existing compatible workroom changes only when the reviewed request explicitly allows its description/label update. Extension versions are exact, and Kaizen/model endpoints are resolved internally. It exposes no cleanup/delete operation, raw SDK method, arbitrary body, CLI argument, endpoint, or credential field. Unsupported apply or cleanup work remains an operator plan or uses a separately governed capability.

The exact apply record uses Kaizen's shared Valkey service, scoped by a hash of the validated actor and exact turn and bounded by the approval lifetime. A member can therefore preview and approve through different Kaizen API replicas. If the record expires or Valkey is unavailable during commit preflight, Kaizen fails closed before invoking the SDK and the member must preview again. If Valkey becomes unavailable only after the SDK has answered, Kaizen reports an ambiguous failure instead of claiming success; inspect the exact platform state before previewing or retrying.

Kaizen reuses the exact-pinned SDK's seeding primitives in-process. Do not install or configure kamiwaza-cli for Demo Builder: CLI contexts, cached OIDC tokens, and subprocess credentials are outside this request-scoped application path.

If the tools are missing, confirm the request arrived through Kamiwaza with a workroom envelope and that Demo Builder's source-controlled bundle loaded. If a call is denied, inspect the member's current platform permission. An apply call that has not received and consumed a generic approval has no platform effect. A timeout during the confirmed commit is an ambiguous effect: inspect exact state before retrying.

Built-in tools

Kaizen's own tools are a closed registry, asserted by a boundary test that walks the source. They are not administered individually; they are gated by feature flags:

Tool family	Gated by
`search`, `conversation_history_search`	Always available to eligible agents
`list_available_agents`	Always available to eligible agents
`run_code`	`SANDBOX_ENABLED` and an explicit agent grant
`create_artifact`, `update_artifact`, `show_widget`	Artifact surfaces
`inspect_tasks`, `manage_tasks`	`TASKS_ENABLED` (off by default) plus platform readiness
Studio tools	`AGENT_STUDIO_ENABLED`, and only for the authoring agents
`invoke_agent`	`AGENT_ORCHESTRATION_ENABLED`, plus member opt-in

run_code deserves attention: it is built only when the sandbox is enabled and offered only to an agent whose grant explicitly names it. It is not on by default for every agent.

Packages

Packages bundle additional tools and may include third-party code. Manage them under the agents hub and the ops package routes: install, list, inspect, upgrade, disable, delete.

The security property

Packaged code runs in the package-tool-runner — a separate, secretless process, deliberately without the tokens or keys the trusted backend holds.

An untrusted package that executes successfully still cannot reach anything sensitive, because there is nothing sensitive in its process to reach. Containment does not depend on the package behaving well.

That said, a package still runs code you did not write. Review what you install, prefer disabling over deleting while you evaluate, and keep the catalog small enough that someone can actually reason about it.

Proposals

Members can propose agents and packages. Administrators review, approve, or reject proposals from the ops surface.

Note the asymmetry: creating an agent for yourself needs no approval — Agent Studio makes it live and private immediately. Publishing to all members is the admin action. Package proposals are reviewed because packages carry code.

Reviewing native Pi proposals

A local proposal marked package_format=pi targets the Pi runtime already locked into this Kaizen release. There is no administrator or author version selector. The review must show a current passing receipt with the exact artifact hash, reviewed-contract digest, observed runtime version, discovered surface, and empty error diagnostics. Changing the ref, manifest, posture, format, or any authored byte clears that evidence. Both member submission and administrator approval recheck it even when AGENT_PACKAGES_SCAN_POLICY=warn.

Skill-only packages may correctly report that no Node tests ran; they still must pass Pi's real skill discovery. Extension packages must report passing node:test execution followed by a successful Pi loader check. Kaizen admits tools, skills, prompts, and themes. Reject commands, flags, events, shortcuts, custom renderers, declaration drift, unsafe resource paths, lifecycle scripts, host packages bundled as ordinary dependencies, and non-exact ordinary dependency versions.

When validation fails:

Read the bounded diagnostic code, path, message, and repair hint on the proposal; do not infer success from console output alone.
Confirm the sandbox worker image was built from the current sidecar Pi lock and reports an observed runtime version.
Confirm the deployment-selected sandbox pool is available. Standard Kubernetes runtime and operator-configured gVisor are both supported.
Have Package Creator patch only the affected contract or file, reload the new proposal version, and run test_package again.

Do not work around an unavailable worker or loader by running authored content in the backend or package runner. Kaizen deliberately has no such fallback.

MCP is one platform source

Pi package manifests may record MCP descriptors, but Kaizen does not host or execute those package-declared servers. Do not make a package depend on its own recorded descriptor becoming callable.

Administrator-installed Kamiwaza MCP Guard servers are different: Kaizen can discover and invoke their enabled tools per request under the current member's forwarded platform envelope. Keep the deployment selection narrow, review the live schemas and read/write annotations, and remove a server from selection if its contract or ownership is unclear.

Applications, connectors, skills, workrooms, Context Service, and other Core services do not route through MCP Guard. Their normal authenticated OpenAPI operations use the generic Core broker described above.

A2A

Remote agent registration is administered under the A2A ops routes: validate configuration, set the public base URL, rotate the shared secret, and manage inbound agents.

A2A is a proof of concept intended for isolated deployments. See A2A & remote agents.

Review checklist

Periodically confirm:

Platform tools​

External schema sources​

Direct SDK platform capability​

Built-in tools​

Packages​

The security property​

Proposals​

Reviewing native Pi proposals​

MCP is one platform source​

A2A​

Review checklist​

Related​