Osprey in a Multi-Tenant Platform: Dynamic Tenant Policies, Scoped State, and Mandatory Instance Rules

[amirakrari]

Written by AI (Artificial Intelligence) ! warning !

Thank you for the explanations about the different origins and goals of Coop and Osprey.

I understand the distinction clearly:

• Coop retained multi-tenancy because it originated as a SaaS human-review product.
• Osprey was designed as an internal rules engine operated by one organization or safety team.
• Adding a complete Coop-style tenancy model to Osprey would introduce substantial complexity and may not fit the project’s intended architecture.

We are therefore not asking Osprey to become a SaaS control plane, manage tenant users, provide tenant dashboards, or reproduce Coop’s workspace model.

Our question is narrower:

Can one Osprey deployment safely evaluate mandatory platform policies together with dynamically managed tenant policies, or should each independently managed policy scope use a separate Osprey deployment?

This matters for ISLAMU Event because our moderation model has two policy levels with different ownership and lifecycle requirements.

---

1. Our moderation and policy model

ISLAMU Event is a self-hostable event platform that can operate in either:

• single-tenant mode for one community, or
• multi-tenant mode where one platform instance hosts multiple isolated communities.

The platform has two relevant administrative scopes.

Instance-level policy

The instance administrator defines the minimum safety requirements for the complete deployment.

These rules are mandatory and tenants cannot weaken or disable them.

Examples include:

• illegal content must be rejected,
• sexual exploitation content must be rejected,
• credible threats must be escalated,
• confirmed fraud or malicious spam must be blocked,
• legally required restrictions must always be enforced.

These policies are controlled by the platform operator and, for the standard ISLAMU distribution, maintained by trusted ISLAMU developers.

Tenant-level policy

Each tenant can add stricter community rules.

For example:

• one tenant may prohibit strong profanity,
• another may reject music-related events,
• a youth community may use lower thresholds for sexual or violent content,
• one tenant may prohibit political events while another allows them,
• different tenants may choose different thresholds for when content requires human review.

Tenant policies may add restrictions, but they must never make the final result more permissive than the instance baseline.

The effective rule is:

If the instance policy rejects content:
    the final result is reject.

If the instance policy allows content
but the tenant policy rejects it:
    the final result is reject.

Content is allowed only when both policy levels allow it.

The instance policy is therefore a mandatory base policy, while the tenant policy is a restrictive overlay.

---

2. Instance policies and tenant policies have different storage requirements

This is an important distinction in our design.

Instance policies may originate from the repository

The standard instance policies can be maintained as reviewed files in the ISLAMU Event repository.

Only trusted ISLAMU developers or the self-hoster operating the deployment would modify those files.

A simple self-hoster should be able to run with policies loaded directly from the filesystem.

A more advanced deployment should also be able to publish those trusted policy files into a database-backed policy store.

We already use a similar model with Cerbos:

• trusted default policies exist as YAML in the repository,
• a self-hoster can use the filesystem policy store,
• or the policies can be published to a PostgreSQL store using the Cerbos tooling.

The filesystem is therefore a valid distribution and bootstrap mechanism for trusted instance policies.

Tenant policies must never depend on repository files

Tenant policies have a completely different lifecycle.

A tenant administrator should manage them through the ISLAMU Event administration UI.

The expected flow is:

Tenant administrator edits policy in ISLAMU Event UI
    ↓
ISLAMU Event API validates the policy
    ↓
Policy is saved in the database
    ↓
Policy is versioned and audited
    ↓
The new version is activated or tested
    ↓
Future Osprey evaluations use the updated tenant policy

There should be no tenant policy file committed to the repository.

Changing a tenant policy must not require:

• editing the Osprey image,
• rebuilding a container,
• creating a pull request,
• writing a new file into a shared filesystem,
• or restarting the complete Osprey deployment.

This is not only a convenience requirement. It is fundamental to the ownership model.

ISLAMU developers own the standard instance policy files.

Tenant administrators own their tenant policy configuration through the product UI.

---

3. Where ISLAMU Event and Osprey should each be authoritative

ISLAMU Event already has local moderation and remains the canonical system for:

• tenant identity,
• authentication and authorization,
• instance and tenant administration,
• policy ownership,
• policy inheritance,
• instance-level locks,
• policy versioning,
• auditing,
• moderation cases,
• human escalation,
• final enforcement actions,
• and combining results from different providers.

Osprey would be the execution engine for:

• automated safety rules,
• event-stream processing,
• machine-assisted moderation signals,
• Osprey-specific rules and integrations,
• and stateful detection where the state boundary is safe.

This means Osprey would not need to know how a tenant administrator logs in or how the ISLAMU Event UI works.

However, a shared Osprey deployment would need some way to execute the correct effective policy for a request.

Conceptually, ISLAMU Event would send:

Content to evaluate
Trusted policy scope
Mandatory instance policy version
Tenant overlay policy version
Relevant entity identifiers

Osprey would then evaluate the mandatory base and the selected tenant overlay.

The caller would be the trusted ISLAMU Event backend, not the tenant’s browser.

A tenant administrator would never call Osprey directly and would never be allowed to submit an arbitrary tenant identifier or disable the instance policy in an evaluation request.

---

4. The deployment models we are considering

We currently see three realistic models.

Model A: One Osprey deployment per tenant

The instance administrator has one Osprey deployment for mandatory platform policy.

Every tenant that wants custom Osprey policies receives or connects its own Osprey deployment.

The evaluation flow becomes:

ISLAMU Event local rules
    ↓
Instance Osprey
    ↓
Optional tenant Osprey
    ↓
ISLAMU Event combines results

This provides strong isolation.

Each tenant can have:

• its own rule set,
• its own labels and reputation state,
• its own custom Python or integrations,
• its own release lifecycle,
• and its own failure boundary.

However, the operational cost becomes significant.

A platform with many tenants may need to provision, monitor, upgrade, back up, and troubleshoot many Osprey deployments.

This may still be the correct design if an Osprey deployment is intentionally equivalent to one trusted organization or one independently managed policy domain.

Model B: One shared Osprey for instance policies only

The platform runs one Osprey deployment controlled by the instance operator.

It evaluates:

• mandatory instance rules,
• platform-wide classifiers,
• shared abuse detection,
• and platform-owned integrations.

Tenant-specific policies remain entirely inside ISLAMU Event.

This is operationally simple and preserves a clear Osprey trust boundary.

It is likely our safest default if Osprey cannot dynamically isolate tenant policy and state.

The limitation is that tenants would only be able to use the policy features implemented by ISLAMU Event itself. They could not benefit from the full Osprey rules environment unless they connected a separate Osprey deployment.

Model C: One shared Osprey with isolated dynamic policy scopes

This would provide the best default experience for a hosted multi-tenant platform.

The shared deployment would have:

• one mandatory instance policy,
• one dynamically managed policy scope per tenant,
• one independently validated and versioned compiled policy per scope,
• and tenant-scoped state where stateful rules are used.

A request for Tenant A would evaluate only:

Mandatory instance policy
+
Tenant A restrictive policy

It would not load or evaluate the policies of Tenant B or Tenant C.

Tenant policies would be created through the ISLAMU Event UI and API, stored in a database, and propagated to Osprey dynamically.

This model would not require Osprey to manage tenant accounts or provide a SaaS administration interface. ISLAMU Event would remain responsible for all administration.

The question is whether Osprey’s architecture can or should support this kind of isolated policy execution.

---

5. The main challenges with a shared Osprey deployment

A. Dynamic policy loading and isolation

The most important requirement is not simply adding a tenant_id field.

The shared engine would need to treat each tenant policy as an independently managed policy unit.

A tenant policy update should be:

• validated independently,
• compiled independently,
• versioned independently,
• activated independently,
• cached independently,
• and rolled back independently.

A syntax or configuration error in Tenant A’s policy must not prevent Tenant B’s policy from running.

Updating Tenant A’s policy should not require recompiling every other tenant’s rules.

The mandatory instance policy should also remain separate from tenant overlays so that a tenant can never replace or disable it.

A useful conceptual model would be:

Instance base policy
    ├── Tenant A restrictive overlay
    ├── Tenant B restrictive overlay
    └── Tenant C restrictive overlay

The effective policy is composed at evaluation time or from independently cached compiled policy sets.

This is closer to policy scoping and inheritance than to full SaaS multi-tenancy.

B. Stateful labels and reputation

Osprey’s stateful capabilities are useful for detecting patterns across multiple events.

Examples include:

• repeated spam,
• escalating risk,
• known malicious entities,
• previous warnings,
• or reputation accumulated over time.

The difficulty is that not all reputation is global.

For example, Tenant A may label a user because that user violated Tenant A’s local community policy.

That should not automatically cause the same user to be blocked in Tenant B.

At the same time, some labels may legitimately be platform-wide, such as a confirmed fraud or security threat.

A shared state model therefore needs to distinguish between:

Global platform state
Tenant A state
Tenant B state
Tenant C state

A possible lookup model would be:

entity identifier
+
state namespace

For example:

global:user:123
tenant-a:user:123
tenant-b:user:123

Whether this should be implemented inside Osprey, through its labels-service interface, or entirely inside ISLAMU Event is one of the areas where we would appreciate guidance.

Without explicit scoping, we would keep tenant-local reputation in ISLAMU Event and use Osprey state only for globally owned platform signals.

C. Trusted policy-scope selection

Because ISLAMU Event owns the tenant context, its backend can resolve:

• which tenant owns the content,
• which instance policy version is mandatory,
• which tenant policy version is active,
• and which policy scope may be used.

Only the trusted backend would communicate with the shared Osprey service.

This means we do not necessarily need Osprey to implement a complete tenant authentication system.

However, the policy scope must still be bound to the caller in a safe way.

A tenant should never be able to request:

• another tenant’s policy,
• a more permissive policy,
• no instance policy,
• an inactive policy version,
• or a policy payload modified directly by the browser.

This could be handled by:

• keeping Osprey on a private network reachable only by ISLAMU Event,
• placing an authenticated gateway in front of it,
• using separate credentials per policy scope,
• or adding a trusted scope-selection mechanism to Osprey.

We would like to understand what trust boundary Osprey expects for this kind of internal service integration.

D. Tenant-provided custom Python code

Tenant-authored declarative policies and tenant-authored arbitrary Python code should probably be treated differently.

It may be safe for a shared Osprey deployment to execute isolated declarative tenant rules.

It is much more dangerous to allow multiple untrusted tenants to upload arbitrary Python or custom plugins into one shared process.

Our likely position is:

• shared Osprey may be suitable for declarative tenant policies if scopes are isolated,
• platform-owned Python integrations may run in the shared deployment,
• tenants requiring custom Python or deeply customized integrations should use a dedicated Osprey deployment.

That separation would preserve the security and operational boundary without requiring every basic tenant policy to receive its own complete Osprey stack.

---

6. The smaller capabilities we are asking about

We are not requesting that Osprey implement tenant users, billing, tenant dashboards, tenant invitations, or a Coop-style workspace product.

The capabilities that would help our use case are smaller:

Named policy scopes

A way to identify independently managed policy sets, such as:

instance-default
tenant-a
tenant-b

Mandatory base plus restrictive overlay

A way to guarantee that the base instance policy is always evaluated and that a tenant overlay may only produce an equally strict or stricter result.

Dynamic policy storage and activation

A way to:

• submit a tenant policy through an API or policy store,
• validate it,
• compile it,
• activate a specific version,
• test it in shadow mode,
• and roll it back,

without rebuilding the Osprey image.

Per-scope failure isolation

A broken tenant policy should fail only that policy scope, not the complete shared deployment.

Namespace-aware state

The labels or state interface should make it possible to distinguish platform state from tenant-local state.

Clear trust-boundary guidance

Documentation should clarify whether Osprey expects:

• one deployment per trusted policy owner,
• or whether one trusted application may safely operate several isolated policy scopes in one deployment.

---

7. Questions for the Osprey team

With that context, we would appreciate guidance on the following.

1. Is one Osprey deployment intended to represent one trusted organization or one independently managed policy domain?

2. For a multi-tenant application, is the recommended architecture today one Osprey deployment per tenant that needs custom Osprey policies?

3. Would using one shared Osprey for platform-owned instance rules, while keeping tenant policies in the parent application, be considered a good supported pattern?

4. Does Osprey currently have, or plan to have, a database-backed API for dynamically creating, validating, versioning, and activating policy sets?

5. Could policy sets be isolated by a generic scope or namespace without Osprey introducing a complete SaaS tenancy model?

6. Could Osprey support a mandatory base policy plus a selected restrictive overlay?

7. Can separately managed policy scopes be compiled and cached independently so that updating or breaking one scope does not affect all other scopes?

8. For labels and stateful reputation, is the intended pattern to namespace entity keys in the application, provide a custom scoped labels backend, or deploy separate Osprey instances?

9. Does Osprey assume it is called only by trusted internal services, or is there an intended mechanism for binding a request to an authorized policy scope?

10. Would declarative tenant policies in a shared deployment fit Osprey’s direction, while tenants requiring arbitrary Python or custom integrations use dedicated deployments?

A clear answer that Osprey intentionally expects one deployment per trusted policy owner would also be valuable. We can design around that boundary if it is the recommended architecture.

---

8. Our current likely direction

Unless Osprey supports isolated dynamic policy scopes, our likely design is:

1. ISLAMU Event remains the canonical moderation and policy authority.
2. Trusted instance policies may be distributed as repository files.
3. A self-hoster may load those instance policies from the filesystem or publish them to a database-backed store.
4. Tenant policies are created exclusively through the ISLAMU Event UI and API.
5. Tenant policies are stored, validated, versioned, audited, and activated in the ISLAMU Event database.
6. One shared Osprey deployment evaluates platform-owned instance policies and shared safety signals.
7. Basic tenant policy logic is evaluated inside ISLAMU Event.
8. Tenant-local reputation remains inside ISLAMU Event unless Osprey state can be safely namespaced.
9. Advanced tenants may connect their own Osprey deployment.
10. Tenants requiring custom Python or plugins use an isolated Osprey deployment.
11. ISLAMU Event combines instance and tenant results so tenant policy can make the final result stricter but can never bypass the instance baseline.
12. Coop remains a separate human-review integration, with tenant review queues and escalation to the instance safety team.

The main architectural decision is therefore not whether Osprey should reproduce Coop’s tenancy model.

It is whether Osprey can provide isolated, dynamically managed policy scopes under one trusted application, or whether each policy owner should operate a separate Osprey deployment.

Thank you again for the explanations and for maintaining the project. We want to integrate Osprey in a way that respects its intended design while still preserving strict tenant isolation and practical policy administration.

[amirakrari]

Oh and my platform is fully in development no release at all so I just wanted to address that to see what you though but it can be deffered for later I can come back in months cause my use case is only effective in months from now cause I know osprey is in its early phases and has bigger priorities