1.7 KiB
1.7 KiB
Admin-Managed Feature Pattern
Use this when a tenant uses a feature whose policy, provider, key or global availability is controlled by the admin/platform.
Definition
An admin-managed feature is configured by admin/platform operators and consumed by tenants. Tenants may see enabled state and allowed options, but they do not own sensitive provider configuration.
Examples
- Tenant AI chatbot using an admin-owned AI provider key approved for the deployment region.
- Tenant integration using a platform-owned provider account.
- Tenant feature enabled only for selected plans or accounts.
- Browser automation where admin controls allowed domains and runtime policy.
Required Manifest Entries
The feature manifest must declare:
integration.ownership = "admin-managed"or"hybrid".- Admin routes that manage provider/policy.
- Tenant routes that consume the feature.
- Secrets and who owns them.
- Permissions for admin configuration and tenant usage.
- Audit events for configuration changes.
- Billing and usage impact.
- UAT checks for secret isolation and tenant enablement.
Security Rules
- Provider keys are never tenant-owned unless explicitly designed as tenant-owned.
- Provider keys must not be sent to tenant loaders, API responses, browser bundles or logs.
- Admin policy must be checked server-side.
- Tenant enablement must be checked server-side.
- Admin configuration changes must emit audit events.
Implementation Shape
- Admin settings store provider config, model/default policy, enablement and limits.
- Tenant feature state references admin-approved config.
- Tenant UI shows only allowed choices.
- API routes resolve effective configuration server-side.
- Worker jobs receive scoped IDs and load secrets server-side.