Skip to content

Subject-Scoped Governance

Preloop can evaluate governance against the specific subject using the platform, not just against the parent account.

This is what lets one account support broad automation overall while keeping one specific runtime or token on a tighter leash.

What "Subject-Scoped" Means

A subject is the concrete actor currently using Preloop.

Examples include:

  • an account-level default policy context
  • a managed agent representing one enrolled runtime
  • an API key representing one tokenized access path

Subject-scoped governance means Preloop can resolve policy and access rules using the most specific subject that applies to the current request.

Scope Resolution Order

At a high level, Preloop resolves scope from most specific to least specific.

  1. API key scope
  2. Managed-agent scope
  3. Account defaults

This lets one token be narrower than its parent managed agent, and one managed agent be narrower than the parent account.

What Can Be Scoped

Subject-scoped governance can influence several parts of the control plane.

Tool Visibility and Tool Rules

A subject can have its own tool policy behavior, including:

  • allow rules
  • deny rules
  • require-approval rules
  • explicit tool enable/disable overrides

This affects which tools are listed to the runtime and how tool calls are evaluated.

Allowed Models

A subject can also restrict which models it is allowed to use.

This is important for managed model traffic because it means:

  • one team account can allow a broad model catalog overall
  • one enrolled runtime can be limited to a smaller safe subset
  • one API key can be restricted even further for a specific integration path

Some subject-specific configuration can also shape how model traffic is evaluated before it reaches the upstream provider.

Where Enforcement Happens

Subject-scoped governance is valuable because it is applied consistently across multiple surfaces.

MCP Tool Listing

The runtime should only see the tools it is actually allowed to use.

Tool Invocation

If a tool call is attempted, Preloop evaluates the applicable rules for that subject and decides whether to allow, deny, or require approval.

Model Gateway Access

When the runtime sends model traffic through the Preloop gateway, the same subject context can be used to enforce allowed-model restrictions and related checks.

Example

Imagine one engineering account with broad defaults:

  • many MCP tools available
  • several hosted and BYOK models configured
  • standard approval workflows for risky tools

Now imagine one enrolled OpenClaw runtime used for a narrower purpose.

Managed-agent scope can reduce that runtime to:

  • a limited MCP tool subset
  • one or two approved coding models
  • a more restrictive approval posture

If that runtime later uses a dedicated API key, the API-key scope can narrow the behavior even further.

Why This Matters

Without subject-scoped governance, the main choice is often between:

  • overly broad account-wide access
  • or duplicated accounts and fragmented administration

Subject-scoped governance gives you a middle ground:

  • centralized administration at the account level
  • narrower controls for specific runtimes and tokens
  • shared observability and auditability across those scopes

Relationship to Other Concepts

Subject scope is closely tied to the rest of the managed runtime control plane.

  • AI Model Gateway uses subject scope to decide which models are allowed before forwarding traffic upstream
  • Runtime Sessions give operators a way to inspect what one scoped runtime actually did over time
  • Managed agent onboarding makes these scoped controls practical for desktop and CLI runtimes such as OpenClaw

Where to Explore It Next