# 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.