44 lines
1.7 KiB
Markdown
44 lines
1.7 KiB
Markdown
# 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.
|