Admin-shared tools and skills with per-user auth

[serrrfirat]

Problem

A company can run one multi-tenant IronClaw instance, but admins need a way to provision shared tools and skills so members start productive without every user repeating the same setup.

The desired model is:

• Admins configure built-in tools and skills once and make them available to all users.
• Admins can create or publish custom tools and skills for all users in the tenant.
• Users inherit admin-managed configuration, such as a shared Slack app or shared MCP/package configuration.
• Users may still need to authenticate individually for a shared integration, such as connecting their own account to an admin-configured Slack/Google/Notion app.
• Users can add their own private tools and skills on top of the admin-managed surface.
• Users cannot modify admin-created tools or skills in the initial phase.

The main open design question is how per-user auth binds to an admin-configured tool: for example, whether an admin-managed tool config references a provider/app installation while each member owns a separate OAuth account/token selected at runtime.

Status

Partially implemented foundation exists on main as of 2026-06-09, and #4544 is the active open PR for the scoped lifecycle admin foundation. The full tenant-wide admin-published tool/skill product surface is still missing.

Landed on main or adjacent:

• feat: DB-backed user management, admin secrets provisioning, and multi-tenant isolation #1626: DB-backed users, admin APIs, role-based access control, per-user secrets provisioning, and multi-tenant isolation foundations.
• [Reborn] Migrate secrets, OAuth, and auth setup product flows #3289: Reborn product-facing secrets, OAuth, and auth setup flows are closed/completed, establishing the credential/account/auth interaction direction this issue should compose with.
• Wire Reborn extension lifecycle registry #4066: Reborn extension lifecycle registry exists for local single-user/local-dev composition, with available-extension catalog/materialization and active-extension registry plumbing.
• Track production and multi-tenant extension lifecycle wiring #4091: Production and multi-tenant extension lifecycle wiring remains explicitly open as the scoped lifecycle backend follow-up from Wire Reborn extension lifecycle registry #4066.
• Reborn: hosted MCP negotiation + Notion/GSuite OAuth credential reuse #4354: Hosted MCP and Notion/GSuite product-auth credential reliability fixes landed, including account-scoped credential staging and most-recently-used runtime credential selection.
• [codex] Add user-scoped skills settings UI #4527: Users can manage their own user-scoped skills in Settings; system/workspace skills remain read-only and multi-tenant user skill storage is isolated from shared scan roots.
• Reborn: production/scoped capability lifecycle admin parity #3288: Broader Reborn lifecycle/admin parity issue tracks extension, skill, MCP, and WASM lifecycle product surfaces.

Open implementation PR:

• feat(reborn): scoped-lifecycle admin install store (#3288) — availability foundation for #5261 #4544: Adds the scoped lifecycle ownership model and durable storage foundation for admin-shared and user-private Reborn package installations. It represents admin-shared installs, user-private installs, mutation authority, persistence across libSQL/PostgreSQL-backed stores, and effective package-set resolution. WebUI/API endpoints and adapter activation against this store remain follow-up work.

Still open / closeout:

• Tenant/admin-owned publish storage is in progress in feat(reborn): scoped-lifecycle admin install store (#3288) — availability foundation for #5261 #4544, but there is still no complete WebUI/API publish surface that makes a tool or skill available to all users while preserving per-user private overlays.
• Production/multi-tenant extension lifecycle needs scoped storage and ownership wiring (Track production and multi-tenant extension lifecycle wiring #4091 / feat(reborn): scoped-lifecycle admin install store (#3288) — availability foundation for #5261 #4544).
• Shared admin-managed tool configuration needs an explicit relationship to per-user credential accounts/grants.
• Admin-created custom skill/tool publishing needs trust, ownership, update, rollback, and visibility semantics.
• Benchmark coverage depends on Simulate non-LLM vault state benchmarks#59 because these flows require non-LLM state mutation, such as vault/secret entries appearing through OAuth/UI/CLI rather than through the model loop.

Current state

Already present or adjacent:

• Multi-tenant identity/admin/secrets foundations exist from feat: DB-backed user management, admin secrets provisioning, and multi-tenant isolation #1626.
• Reborn auth/product-auth flows provide credential setup, recovery, refresh, and redacted credential account projections through [Reborn] Migrate secrets, OAuth, and auth setup product flows #3289 and follow-up auth work.
• User-scoped skill management exists from [codex] Add user-scoped skills settings UI #4527.
• Local-dev Reborn extension lifecycle exists from Wire Reborn extension lifecycle registry #4066.
• Scoped lifecycle admin storage/foundation is actively in progress in feat(reborn): scoped-lifecycle admin install store (#3288) — availability foundation for #5261 #4544.
• Production/multi-tenant lifecycle wiring is tracked by Track production and multi-tenant extension lifecycle wiring #4091.
• Credential profile/multiple account concerns are related to support credential profiles for multiple accounts per service #2642.
• Hosted multi-tenant security concerns are related to Architecture Review: Security Model for Hosted Multi-Tenant Deployment #557.

Known gaps:

• No complete canonical tenant-level tool/skill publication product surface yet.
• No explicit precedence model exposed to product callers for system, tenant/admin, workspace/project, and user-private tools/skills, beyond the storage/effective-resolution foundation proposed in feat(reborn): scoped-lifecycle admin install store (#3288) — availability foundation for #5261 #4544.
• No admin-managed shared tool config object that can be inherited by users without sharing user credentials.
• No policy for binding user-owned credential accounts to admin-owned tool configuration.
• No product/API surface for admins to publish, update, disable, or revoke custom tools/skills tenant-wide.
• No tests proving the end-to-end product path where a user cannot modify admin-published tools/skills.
• No benchmark harness support yet for non-LLM secret/vault state needed to validate per-user auth completion flows.

User/operator outcome

An admin can prepare an IronClaw tenant with the standard tools and skills the company expects members to use. A new member signs in and immediately sees the admin-published capability surface, only needing to complete their own auth when a shared integration requires a user-owned credential.

A member can also add private tools and skills for themselves. Those private additions do not alter the tenant-wide admin surface and cannot weaken or replace admin-managed tool policy for other users.

Canonical interface

• Admin-shared tools and skills should be modeled through Reborn lifecycle/config/package/trust services, not through process-global registries or shared filesystem scan roots.
• Tenant/admin configuration should define shared package/config authority; per-user credential accounts should remain user-owned and selected/granted through product-auth/credential services.
• Tool/capability visibility should be computed through CapabilityCatalog / ToolSurfaceService style boundaries, not by mutating model-visible tools directly from UI or route handlers.
• User-private tools and skills should be layered as an overlay on top of system and tenant/admin surfaces with deterministic precedence.
• Admin and user product routes should adapt requests and call shared services; they should not own package trust, credential binding, capability visibility, or runtime injection policy.

Scope

Included:

• Tenant/admin-published built-in tools and skills.
• Tenant/admin-published custom tools and skills.
• Inherited admin-managed tool configuration for all users in a tenant.
• Per-user authentication for admin-configured integrations.
• User-private tools and skills as an overlay on top of shared/admin capabilities.
• Read-only treatment of admin-created tools/skills for non-admin users.
• Admin update/disable/remove behavior with clear effect on user-visible capability surfaces.
• Trust/provenance/audit metadata for admin-published custom tools and skills.
• Redacted setup/auth/readiness states for inherited tools that still need per-user auth.
• Tests for cross-user isolation, non-admin mutation denial, credential isolation, and no secret leakage.

Out of scope / deferred:

• Letting users modify admin-created tools or skills.
• Marketplace/community publishing beyond the tenant.
• Fine-grained per-team policy UX beyond tenant/admin publish and user-private overlay.
• Full credential profile UX for multiple accounts per provider; coordinate with support credential profiles for multiple accounts per service #2642 instead of solving the whole profile problem here.
• Benchmark harness implementation itself; that is tracked in Simulate non-LLM vault state benchmarks#59.

User stories

• As an admin, I can add built-in tools and skills and make them available to all users.
• As an admin, I can configure a shared tool, such as one Slack app, and users inherit that configuration.
• As an admin, I can create and publish custom tools/skills to all users.
• As a user, I can use admin-published tools and skills without repeating admin setup.
• As a user, I can authenticate my own account for a shared admin-configured tool when required.
• As a user, I can add my own private tools and skills on top of admin-published ones.
• As a non-admin user, I cannot modify admin-created tools and skills.

Acceptance criteria

• A tenant/admin-scoped package/config record can make a built-in tool or skill visible to all users in that tenant.
• A tenant/admin-scoped package/config record can make a custom tool or skill visible to all users in that tenant after trust/provenance checks.
• User-visible tool/skill inventory deterministically merges system, tenant/admin, workspace/project if applicable, and user-private sources.
• User-private tools/skills do not mutate or shadow admin-published entries in a way that affects other users.
• Non-admin attempts to edit, delete, disable, or reconfigure admin-published tools/skills fail closed and leave no partial state behind.
• Admin-published tool config can reference shared provider/app setup without storing user-owned OAuth tokens or secrets in the shared config record.
• Per-user auth completion binds a user-owned credential account/grant to the inherited admin-managed tool config.
• Runtime credential injection uses the authenticated user's credential account or an explicit admin-shared grant; it never falls back to another user's credential.
• Missing, expired, ambiguous, or revoked user credentials for a shared tool produce stable auth-required/setup-required states.
• Admin updates or disables a shared tool/skill update user-visible capability surfaces without requiring process restart.
• Admin deletion/revocation removes inherited visibility while preserving user-private tools/skills and handling extension-owned credential cleanup correctly.
• Audit/projection output records admin publish/update/disable/delete and user auth-binding events with redacted metadata only.
• Product DTOs, logs, audit events, and benchmark traces do not expose raw tokens, client secrets, refresh tokens, host paths, backend diagnostics, or private skill/tool bodies across users.

Required validation

• Service/facade tests for tenant/admin publish, update, disable, remove, and inventory listing.
• Caller-level WebUI/API tests for admin-only publish/configure paths and non-admin mutation denial.
• User inventory tests proving deterministic merge/precedence across system, tenant/admin, and user-private tools/skills.
• Cross-tenant and cross-user isolation tests for shared config visibility and user-private overlays.
• Product-auth integration tests proving per-user credentials bind to inherited admin-managed tool config and cannot use another user's credential.
• Runtime/capability tests proving inherited tools appear only through the canonical capability surface and credential injection remains scoped.
• Redaction/no-exposure tests for setup/auth/readiness DTOs, audit events, logs, errors, and benchmark traces.
• Benchmark evidence once Simulate non-LLM vault state benchmarks#59 can model vault/secret state changes outside the LLM loop.

Close criteria

This issue can close when admins can publish built-in and custom tools/skills tenant-wide, users can inherit that surface while keeping private overlays, per-user auth binds safely to admin-configured tools, non-admins cannot modify admin-owned entries, and caller-level tests plus benchmark evidence prove isolation, credential scoping, and no-exposure behavior. If #4544 lands first, this issue should remain open until the product/API/WebUI and per-user auth-binding follow-ups are either completed or split into narrower linked issues.

Related context

• Active implementation PR: feat(reborn): scoped-lifecycle admin install store (#3288) — availability foundation for #5261 #4544
• Benchmark dependency: Simulate non-LLM vault state benchmarks#59
• Reborn product surface migration: [EPIC] Reborn product surface migration #3031
• Capability lifecycle/admin parity: Reborn: production/scoped capability lifecycle admin parity #3288
• Production/multi-tenant extension lifecycle follow-up: Track production and multi-tenant extension lifecycle wiring #4091
• Secrets, OAuth, and auth setup product flows: [Reborn] Migrate secrets, OAuth, and auth setup product flows #3289
• User-scoped skills Settings UI: [codex] Add user-scoped skills settings UI #4527
• Reborn extension lifecycle registry: Wire Reborn extension lifecycle registry #4066
• DB-backed user management and admin secrets provisioning: feat: DB-backed user management, admin secrets provisioning, and multi-tenant isolation #1626
• Hosted MCP / product-auth credential reuse: Reborn: hosted MCP negotiation + Notion/GSuite OAuth credential reuse #4354
• Credential profiles / multiple accounts per service: support credential profiles for multiple accounts per service #2642
• Hosted multi-tenant security review: Architecture Review: Security Model for Hosted Multi-Tenant Deployment #557