Scope And ACL

Every agentic platform has to answer “what can this agent see?” The usual answer is a blanket OAuth grant: connect your inbox, and the platform sees every message. Connect your calendar, and it sees every event. Stallari refuses this shape. Instead, it decomposes the user’s data into named scopes that the user owns and the platform consults on every routing decision.

Why Blanket Grants Fail

Blanket grants are convenient at the moment of consent and irreversible in practice. Once a vendor has read access to the entire inbox, the user cannot say “you may classify mail from work but not from family” without revoking the grant entirely. The platform either has everything or nothing.

The cost shows up everywhere. A mail-classification agent that was given the whole inbox has no signal about which mail the user wants it to act on. A calendar agent given every event spends inference budget on personal events it should never have seen. A model routed for a sensitive thread sees an inbox-wide context window because the platform has no way to scope down without breaking.

Worse, the routing question becomes unanswerable. The user wants to use a cloud provider for general-purpose tasks but keep family correspondence on-device. With blanket grants, the platform cannot honour both preferences on the same inbox.

Scope Tags As The Primitive

Stallari’s substrate is the scope tag: a named label the user owns, applied to data the user controls. Scope tags are typed values declared in the vault and surfaced everywhere the platform makes a routing decision.

Example scope	Applies to	What it controls (example)
work	Mail from work contacts; work calendar; work documents.	Cloud provider routing allowed; HITL gate for outbound mail.
family	Mail from family; family calendar; family notes.	On-device inference only; no third-party blade access.
infrastructure	Devops-related notes and threads.	Trusted to call build / deploy tools under two-gate authorisation.
bizops	Financial threads; billing; invoices.	HITL gate required for any action; cloud provider allowed for redacted bodies only.
private	Anything explicitly marked private.	No inference; no indexing for cloud-routed jobs.

Scope tags are not bolted on. They are part of the platform’s user-owned content model. A person card carries scopes. An organisation card carries scopes. An inbox classifier can derive scopes from sender, subject, headers, and human correction history. Once a scope is assigned, every downstream surface honours it.

Dual-Layer ACL

Permissions in Stallari decompose into two layers:

1. Capability — what kind of action a skill can take. “Read mail”, “draft outbound mail”, “edit vault note frontmatter”, “call a third-party API endpoint”. Capabilities are declared in the skill’s manifest and consented to once.

2. Scope — what data class the capability applies to. “Read mail tagged work”, “draft outbound mail in scope family”, “edit vault notes in the bizops scope”.

A skill cannot exercise a capability outside its granted scope set. A classification skill granted “read mail in any scope” can read everything but cannot draft a reply unless it is also granted “draft outbound mail in scope X”. A summarisation skill granted “read mail in scope work” cannot summarise family mail even if it asks the model nicely.

This is what lets the user say “this third-party pack may read work mail to file invoices, but it may not read anything else, and it may not send mail at all”. The substrate enforces this deterministically at the dispatch layer, not by trusting the language model to behave: the pack’s declared capabilities determine which tools the runtime exposes to the agent, the scope tag determines which arguments those tools accept, and tools the pack did not declare (such as send_mail) are simply absent from the agent’s tool catalogue. The model cannot “choose” to send mail any more than it can call tools that do not exist for it. On-device MLX models help find relevant content within a scope (retrieval); they are not the enforcement layer for what content is permitted (restriction).

Live Scope Derivation

The user does not pre-tag every piece of data. Scopes are derived live from heuristics that the user can inspect and correct.

When a new inbox item arrives, the classifier runs on its envelope (sender, recipients, subject, headers) and proposes a scope. If confidence is high, the scope is applied and the item flows through normally. If confidence is low, the item lands on the Classifications surface — a single user-facing inbox for “the platform was not sure; please decide”. The user accepts the proposal, overrides it, or pins a new rule for next time.

The derivation pipeline includes a learning loop. Each correction is recorded; the classifier biases future decisions on similar envelopes; the loop runs locally and never sees data that has not already been routed to it under existing scopes. There is no central training signal collected across users.

Contract Namespacing And Domains

Scopes live within contract namespaces. The first-party namespace ships with the platform: mail, calendar, vault, fleet, packs. Community packs declare their own contract namespaces — a third-party pack that adds, say, a CRM contract can publish crm/account, crm/opportunity, crm/contact without colliding with any first-party contract.

Domain tags ride alongside scopes for organisational separation. A user can have multiple domains active at once — personal, work, side-hustle, family-office — and scope tags are interpreted within the active domain. The same scope name in two different domains is two different surfaces. This is how a single Stallari instance serves a single human’s whole life without conflating which inbox a draft belongs to.

The Classifications Surface

When the substrate cannot decide, it does not guess. Every kind of routing the platform is unsure about — uncertain scope assignments, novel sender patterns, unclassified attachments, undisclosed-recipient threads — lands on the Classifications page. The page is the single point of human review for routing decisions, regardless of which workflow surfaced them.

A user who works through Classifications is teaching the platform their own taxonomy. The corrections feed the classifier. The classifier proposes higher-confidence scopes the next day. The Classifications backlog shrinks as the user’s taxonomy stabilises. The substrate is designed to make the backlog approach zero, not to grow indefinitely on backlog-as-business-model.

What Scope ACL Buys

The decomposition has practical consequences:

• A user can say “no cloud provider sees family threads” and the routing layer enforces it.
• A user can grant a pack narrow access — just one scope, just one capability — without granting it the inbox.
• A user can rotate scopes when relationships change. Tagging an organisation as archived quietly removes it from active routing without losing the data.
• A user can audit. “Show every dispatch that touched scope bizops in the last month” answers from the audit trail.

This is the substrate that makes the platform safe to give consequential work to. Blanket grants are theatre. Scope ACL is mechanism.

Related concepts

• Agency model — how scope ACL gates tool surfaces at runtime.
• Context and memory — how scope tags filter the context an agent assembles.
• Local vs cloud — how scope drives provider routing.
• Packs and trust — how third-party packs declare and receive scope-bounded access.