Proposed specificationSource-located exemplarH2

Scope-based authorization and profiles

Bind capabilities to explicit scopes.

JOIN POINTcapability_resolutionRECORD STATUSCandidate · v0.1.0

UML class view

The proposed contract drawn as participant roles, received calls, and numbered dependencies.

Object interactions

The same roles and calls as a class collaboration and a numbered message sequence.

Object interaction diagram for Scope-based authorization and profiles, showing role collaboration and a numbered message sequence — FIG. P25 / OBJECT INTERACTIONS
Open full SVG Download PDF

Pointcut

Where the mechanism applies. All four dimensions belong to the proposed match, not just its vocabulary.

Context: A caller invokes a method or service with an operator, session, or agent identity.
Trigger: Capability is checked against a requested scope.
Structure: Scope identity, profile, grant and revocation state, and resolution function.
Effect: The call is permitted only if the principal currently holds a covering scope.

Protected contract

The obligation that clients, operators, and auditors should be able to rely on.

Requires: Principal identity and requested capability are explicit.
Ensures: Authorization is evaluated at the call boundary and records the covering scope.
Invariant: Scopes are not inherited beyond declared containment or lifetime.
Violation: Missing, expired, revoked, or cross-scope capabilities are denied explicitly.

Negative control

A boolean admin flag is not a scope model.

Variation & lifecycle

The hot spot is admitted only where the protected semantics survive.

Permitted variation

Method scopes, roles, session grants, profiles, and delegated identities.

Test obligation

Test widening, revocation, expiration, child agent, and cross-tenant access.

Evolution question

Did coarse permissions become composable capability scopes?

Prompt + code design

An illustrative prompt and a small design sketch for the proposed contract. Names and APIs are invented; this is not a repository excerpt.

PROMPT SKETCH

Resolve capabilities at the call boundary using the principal, requested scope, and active profile. Record the covering scope that authorized the call, or deny with the missing scope.

CODE DESIGN / PYTHON

def authorize_call(principal, capability, registry):
    scopes = registry.scopes_for(principal)
    covering = [scope for scope in scopes if scope.covers(capability)]
    if not covering:
        return Denied(capability, missing=capability.required_scope)
    decision = max(covering, key=lambda scope: scope.specificity)
    return Allowed(capability, scope=decision.id)

Illustrative design sketch. A session grant is not a blanket capability; the covering scope belongs in the record. This example is a teaching aid, not implementation evidence or a conformance claim.

Detection & matching

The frozen rule that retrieves this record, the canonical source exemplar, and the control that should stay unmatched.

Join point: capability_resolution
Source locator: Barbaste et al., §10.4, p. 37 (OpenClaw, “Scope-Based Authorization”); §10.6, p. 38 (Mistral Vibe agent-profile gates); merged label
Lexical cue: (?i)\b(?:scope[sd]?|capabilit(?:y|ies)|authorization[_-]?profile|permission[_-]?scope)\bFrozen expression, v0.1.0. A match is a retrieval cue, not a confirmed implementation.
Aliases: None
Canonical exemplar: openclaw/openclawsrc/gateway/method-scopes.ts:215Support: src/shared/operator-scope-compat.test.ts:64
Negative control: A boolean admin flag is not a scope model.

Scope-anchored review. pohe-agent analyze <repo> --pattern P25 anchors the cue to its enclosing declaration and checks a separate operational signature for all four pointcut dimensions. Missing roles and negative-control risks remain visible; a structural match is not E2/E3. Calibration report ↗

Repository files

Up to five public files retrieved by the frozen cue and pinned to the audited commit. A match is a place to inspect, not a confirmed implementation.

01openclaw/openclawsrc/gateway/method-scopes.ts:215CANONICAL SOURCE 02aaif-goose/goosecrates/goose/src/acp/common.rs:69RETRIEVAL CUE 03affaan-m/ECCskills/agent-self-evaluation/scripts/evaluate.py:112RETRIEVAL CUE 04agno-agi/agnolibs/agno/agno/db/singlestore/utils.py:157RETRIEVAL CUE 05Aider-AI/aideraider/args.py:420RETRIEVAL CUE

Evidence & provenance

Each layer answers a different question. Do not substitute retrieval for review.

Source-located exemplar

A concrete source anchor is available for this proposed record. It is one exemplar, not evidence that all repositories—or every contract field—conform.

Review boundary: this candidate and its specification come from an AI-assisted study. Independent human validation remains open.

ANY-EVIDENCE FAMILY COVERAGE36/36

100.0% of repository families in the frozen panel have at least one current cue, historical cue, or canonical source layer. This is not confirmed prevalence.

Current lexical-cue repositories: 41 / 41

Canonical source anchoropenclaw/openclaw 60a2e23d5422src/gateway/method-scopes.ts:215

Supporting surfacesrc/shared/operator-scope-compat.test.ts:64

Least-privilege operator scopes per method.

Exploratory retrieval cue Regex / v0.1.0

(?i)\b(?:scope[sd]?|capabilit(?:y|ies)|authorization[_-]?profile|permission[_-]?scope)\b

This expression is a discovery instrument only. A match is a retrieval cue—not a confirmed implementation, pointcut match, or contract proof.