Reviewer A
- Role
- Supplier Account Reviewer
- Tenant
- GlobalCo
- Taxonomy scope
- Procurement / North America / US-01
- Purpose
- Account Change Verification
- Requested action
- Review ACME-204 / US-01
Eligible
Least-Privilege Architecture
Apply least privilege to the exact business scope.
Use roles to define the kind of work a person or workload may perform, then narrow that authority by tenant, legal entity, resource, taxonomy, purpose, classification, current state, and policy before information or capabilities can influence the application.
Frozion keeps that scope connected across retrieval, Context Assembly, models, tools, human approvals, outputs, durable execution, and evidence so the same role can safely serve different portfolios, products, geographies, legal entities, and data classes without becoming a broad permission grant.
A role determines the kind of work. Taxonomy scope determines where that authority applies.
See authority in contextOn this page
Start with a trusted tenant boundary
Tenant scope is the outer application boundary for many multi-tenant and multi-entity systems.
It should be derived from trusted identity, application, and resource context rather than a caller-supplied string that downstream components are expected to honor by convention.
Tenant isolation can apply to:
- operational records
- documents and chunks
- retrieval indexes
- features
- cache entries
- model sessions
- memory
- durable state
- tools and external resources
- outputs
- evidence and replay views
The tenant boundary protects more than direct disclosure. It also prevents another tenant's data, state, cache, or retrieval candidates from changing the result through indirect influence.
Benefit: Keep each tenant's information and behavior isolated even when physical infrastructure is shared.
Prevent cross-tenant influence before it changes the answer
An AI application can return no foreign rows and still allow another tenant to change the result.
If retrieval finds a global top-k and filters by tenant afterward, ineligible candidates may consume ranking, reranking, diversity, cache, or context budgets before they are removed.
The tenant boundary can therefore constrain candidate generation before unauthorized information competes for influence.
Benefit: Protect both confidentiality and decision quality by keeping other tenants outside the candidate universe, not merely outside the final display.
Use RBAC for stable job function
RBAC remains useful because job functions and broad application responsibilities tend to be more stable than the business domains over which those functions operate.
Examples include:
- Claims Reviewer
- Portfolio Analyst
- Supplier Account Reviewer
- Legal Approver
- Risk Administrator
- Data Steward
The role can answer which classes of application action are available without encoding every portfolio, geography, product, legal entity, or classification combination into a new role.
Benefit: Keep role administration understandable while delegating fine-grained business scope to the controls designed to express it.
Use ABAC for the attributes that make the business decision specific
ABAC can evaluate attributes associated with the subject, workload, resource, requested action, application, environment, and current execution.
Examples can include:
- subject department or assignment
- resource owner or legal entity
- case ownership
- document classification
- requested action
- business purpose
- assurance level
- current resource revision
- application state
- time or environment
Those attributes can be combined with RBAC rather than replacing it.
Benefit: Use broad roles for function and current attributes for the conditions that determine whether the operation is actually permitted.
Make hierarchy and inheritance explicit
Hierarchical scope is useful only when inheritance rules are clear.
A Scope Path connects a concept to broader or narrower enterprise concepts.
A Scope Closure is the explicit set of concepts included after applying declared rules for:
- inheritance direction
- maximum depth
- deny precedence
- exceptions
- multi-label combination
- missing-scope behavior
- taxonomy version
The application can then reason over the resolved set rather than assuming that every parent grant automatically includes every future descendant.
Benefit: Use hierarchy without making newly added or excluded branches silently eligible.
Keep multi-label resources and denials explicit
A resource can belong to several authorization schemes at once.
A supplier document might be:
- Procurement > Suppliers > North America
- Legal Entity > US-01
- Information Type > Bank Verification
- Classification > Restricted
One permissive match should not automatically override a restricted classification, legal entity, or explicit deny.
Policy can define whether labels are all-required, alternatives, exceptions, or deny-dominant for the current action and purpose.
Benefit: Prevent one permissive facet from widening a resource that remains restricted along another business dimension.
Apply scope before information can influence the decision
Least privilege applies to data eligibility before it applies to the final output.
For retrieval and Context Assembly, the active authority can constrain:
- documents and chunks
- graph nodes and relationships
- structured query results
- Feature Values
- cache and memory
- summaries and derived artifacts
- tool observations
Scope should survive candidate generation, ranking, transformation, aggregation, and Context Assembly rather than being reconstructed after the decision context already exists.
Benefit: Control what information may shape a machine or human decision, not only what the user may see afterward.
Carry scope into every derived artifact
A protected source can produce many secondary representations:
Source Record -> Query Result -> Feature -> Chunk -> Embedding -> Summary -> Cache -> Context Item -> Output
Each derived artifact can retain or reference the scope and provenance required to determine whether it remains eligible for the current execution.
Benefit: Prevent summaries, embeddings, features, caches, and outputs from becoming scope-free copies of protected source information.
Pass equal-or-narrower scope into agents, subgraphs, and workers
Delegation should not broaden authority merely because work moves into another agent, reusable subgraph, event consumer, queue worker, or background service.
An Invocation or Authority Envelope can carry the explicit scope available to the child boundary.
The child can receive the same scope or a narrower subset appropriate to the task.
Benefit: Compose agentic and event-driven applications without turning delegation into privilege expansion.
Apply the same scope to outputs and evidence
The authorization boundary does not end when the model produces an answer or the workflow completes.
Outputs may include:
- generated text
- citations
- download links
- notifications
- exports
- webhooks
- generated files
Evidence can contain even more sensitive material through prompt captures, retrieval snapshots, query receipts, tool payloads, screenshots, and replay views.
Permission-Aware Inspection can restrict each viewer to the evidence projection allowed by their current tenant, taxonomy, purpose, classification, and source permissions.
Benefit: Prevent the output, audit, or support plane from becoming a path around the same least-privilege controls applied during execution.
Revalidate scope when assignments, resources, or taxonomies change
Long-running executions introduce time into authorization.
While work waits:
- a person can be reassigned
- a resource can move to another business branch
- a document can be reclassified
- a taxonomy concept can split, merge, retire, or change parent
- policy can change inheritance or deny rules
- an approval can expire
- a cache or index can still carry older scope metadata
The historical execution can retain the scope and taxonomy version that governed earlier boundaries while current-state revalidation determines whether the next consequential step remains permitted.
Benefit: Keep durable work governed when the enterprise changes while the application is waiting.
Make scope continuity inspectable before publication
Visual Architecture gives least privilege a place to become explicit before runtime.
Compile-on-Publish can resolve canonical taxonomy concepts, compute declared Scope Closures, type-check mappings, bind trusted predicates, and detect paths that lose or widen scope.
Validation can flag:
- data nodes without tenant or object authorization
- resources or derived artifacts without canonical scope labels
- retrieval paths that filter only after global candidate generation
- mappings that drop tenant, legal entity, taxonomy, purpose, or classification
- cache or feature keys missing behaviorally material scope
- agents or subgraphs exporting broader scope than the parent can delegate
- tools authorized by role but not target resource / Taxonomy Scope
- outputs or evidence without scoped visibility policy
- taxonomy changes incompatible with suspended executions
Tenant, scope, purpose, resource, and policy dependencies become Optimization Fences: runtime execution can be optimized without broadening their meaning.
Benefit: Find privilege-expansion paths before publication instead of relying on reviewers to notice them after deployment.
Test least privilege as an application invariant
Authorization is vulnerable to regression because new caches, indexes, tools, mappings, models, support features, and background workers can create new cross-scope paths after an initial security review.
A least-privilege test matrix should include:
- two tenants with identical tenant-local resource identifiers
- two users with the same role but sibling Taxonomy Scopes
- parent / child hierarchy cases
- multi-label resources with one restricted facet
- explicit deny and exception cases
- permission revocation after indexing or feature calculation
- cold-cache, warm-cache, and semantic-cache cases
- long waits with reassignment or taxonomy-version changes
- agents and subgraphs receiving equal-or-narrower scope
- broad workload credentials targeting an out-of-scope object
- output, export, notification, and webhook boundaries
- support, audit, lineage, and replay views
The strongest invariant is not only 'no unauthorized row was returned.' It is that no unauthorized tenant or business branch may disclose information, influence selection or reasoning, authorize a decision, enable a capability, receive an output, or produce a business effect for the current Execution Instance.
Benefit: Test the authorization property the business actually depends on, including indirect influence and downstream effects.
Preserve scope all the way to the business effect
Scope-to-Effect Lineage can connect:
- initiating subject and workload
- role and delegated authority
- tenant and legal entity
- Taxonomy Scope assignments and version
- resource labels and provenance
- retrieval candidates and exclusions
- Context Package
- model / memory / feature / cache scope
- policy decisions and obligations
- Human Approval State
- Capability Invocation
- Business Operation Identity
- output audience
- Effect Receipt and resulting resource revision
The historical record preserves which governed business branch was allowed to shape and receive the outcome without turning historical scope into present-day authority.
Benefit: Prove not only that the right role acted, but that the complete application stayed inside the business scope where that role was valid.
See least privilege in one supplier account-change application
User enters as Supplier Account Reviewer
The role permits supplier-account review. The current authority also includes Tenant GlobalCo, Legal Entity US-01, Procurement > Suppliers > North America, purpose Account Change Verification, and the exact supplier resource ACME-204.
Operational data resolves the resource
The application binds ACME-204 to the US-01 supplier record and current account-change case rather than trusting a caller-supplied supplier label.
Retrieval applies scope before ranking
A bank-verification document from the EMEA supplier branch is semantically relevant but never enters the authorized candidate universe for this execution.
Context Assembly preserves the boundary
Eligible documents, query results, Decision Features, and memory retain tenant, legal-entity, taxonomy, classification, purpose, and provenance.
The model receives only scoped context
The reasoning step cannot use out-of-scope evidence simply because it is relevant or connected.
Policy checks the requested action
The role allows review. ABAC and Taxonomy Scope confirm that this reviewer may review ACME-204 in US-01 for the declared purpose.
Human approval checks reviewer scope
A second reviewer with the same role but EMEA-only Taxonomy Scope cannot approve the US-01 proposal.
The tool target is authorized
The capability Update Payment Instructions is available to the role, but the target object must still match US-01, ACME-204, the permitted action, purpose, and current proposal.
A wait triggers current-state revalidation
If the supplier moves legal entity, the reviewer is reassigned, or the taxonomy version changes while the case waits, the Scope Compatibility Gate determines whether to continue, narrow, reapprove, migrate, or stop.
The effect remains scoped
Business Operation Identity and Effect Receipt remain connected to the tenant, resource, role, Taxonomy Scope, purpose, policy, and approval that governed the update.
Audit remains permission-aware
An auditor can inspect proof that the scope held without automatically gaining access to every protected source artifact.
Result: the application proves that the actor had the right function, the right tenant, the right business branch, the right resource, the right purpose, and the right current authority from evidence selection through the final supplier-account effect.
RBAC, ABAC, Taxonomy Scope, and tenant isolation solve different responsibilities
| Control | Best at | Representative question | Boundary to preserve |
|---|---|---|---|
| Tenant isolation | Outer organizational / customer boundary | Which tenant or legal entity may this execution operate within? | No foreign tenant data, state, authority, artifact, or effect may influence the execution |
| RBAC | Stable job function and broad permissions | What kind of work may this actor perform? | Role membership alone does not identify the business branch or object |
| ABAC | Current subject, resource, action, purpose, environment, and state | Does this operation satisfy the attributes required now? | Attributes need authoritative sources, integrity, version, and policy |
| Taxonomy Scope | Hierarchical / faceted business domain | Which portfolio, product, geography, legal entity, document class, or classification is in scope? | Hierarchy, denials, exceptions, and versions must remain explicit |
| Object / resource authorization | Exact business resource | May this actor perform this action on this exact object? | A valid function or tool does not authorize every reachable resource |
| Purpose-bound authorization | Why the operation is occurring | May this data or capability be used for this purpose? | Access valid for one purpose may be invalid for another |
Benefit: Combine complementary controls into one effective authorization decision instead of expecting any one of them to carry the complete business meaning.
Keep role simplicity without role blindness
| Actor | Role | Tenant | Taxonomy Scope | Purpose | Supplier request | Outcome |
|---|---|---|---|---|---|---|
| Reviewer A | Supplier Account Reviewer | GlobalCo | North America > US-01 | Account Change Verification | ACME-204 / US-01 | ELIGIBLE |
| Reviewer B | Supplier Account Reviewer | GlobalCo | EMEA > DE-01 | Account Change Verification | ACME-204 / US-01 | OUT OF SCOPE |
| Reviewer C | Supplier Account Reviewer | GlobalCo | North America > US-01 | Supplier Analytics | ACME-204 / US-01 | PURPOSE MISMATCH |
| Background Worker | Workload capability | GlobalCo | Delegated US-01 subset | Commit approved change | ACME-204 / US-01 | ELIGIBLE after operation / policy checks |
Benefit: Let the same role mean the same function everywhere while current scope determines where and why that function may be exercised.
Work with the identity and policy systems you already have
Frozion does not need to replace the enterprise systems already responsible for authentication, role administration, data labels, or policy decisions.
| Existing technology | What can remain authoritative there | Frozion connects |
|---|---|---|
| Identity provider / directory | Authentication, user identity, groups, role and attribute sources | Subject identity, assignments, assurance, delegation into Continuous Authority |
| RBAC / IAM | Role membership and broad application / capability permissions | Role function into the effective authorization intersection |
| ABAC / policy engine | Subject, object, action, environment policy | Runtime policy facts, obligations, enforcement, evidence |
| Data catalog / taxonomy | Canonical business concepts, classifications, labels, ownership | Authorization Taxonomy, Taxonomy Scope, label provenance and versions |
| Operational systems | Resource identity, legal entity, current state and ownership | Object-level authorization and current-state revalidation |
| Database RLS / source ACL | Local row, object, field, or document access | Source authorization into broader application scope |
| API gateway / service IAM | Workload authentication, audience, function access | Target-resource, purpose, action, tenant, and delegated authority checks |
| Search / vector infrastructure | Indexes and retrieval execution | Permission-aware candidate generation before influence |
| SIEM / audit / GRC | Security telemetry, policy records, reviews, audit evidence | Permission-aware Scope-to-Effect Lineage |
Benefit: Preserve existing IAM and security investments while keeping their decisions connected through one application-level authority model.
Explore the connected security architecture
Identity & Security
See how subject, workload, delegation, scope, policy, assurance, waits, and effects stay connected through Continuous Authority.
Policy Builder & Governance by Construction
Turn role, attribute, taxonomy, purpose, state, and obligation facts into enforceable runtime policy.
Agent-Scoped Knowledge Graph & Tri-Hybrid Retrieval
Apply tenant, taxonomy, purpose, and source permission scope before candidates compete for ranking and Context Assembly.
Explore Knowledge Graph & Retrieval
Operational Collections & Governed Query
Bind subject, workload, tenant, legal entity, row, object, property, field, taxonomy, and purpose into structured data access.
Provenance, Lineage & Evidence
Preserve Scope-to-Effect evidence while keeping investigation itself permission-aware.
Apply least privilege to the business operation itself
Bring Frozion an AI application where tenant, role, object, taxonomy, purpose, or resource scope currently has to be reconstructed separately across data access, RAG, model context, tools, approvals, outputs, and audit views.
We will map the Tenant Isolation Contract, role model, ABAC facts, Authorization Taxonomy, Scope Paths and Closures, resource labels, purpose rules, delegation boundaries, Scope Compatibility Gates, Compile-on-Publish validation, and Scope-to-Effect evidence required to keep least privilege intact from data to effect.
FAQ
Does Least-Privilege Architecture replace Identity & Security Identity & Security?
No. Identity & Security explains the complete Continuous Authority model across identity, data, tools, people, waits, effects, and evidence. Least-Privilege Architecture is the least-privilege deep dive into tenant, RBAC, ABAC, taxonomy, purpose, resource, and current-state scope.
Is RBAC still useful for enterprise AI?
Yes. RBAC remains valuable for stable job function and broad permissions. Least-Privilege Architecture combines it with attributes and domain scope rather than treating roles as obsolete.
Why is RBAC alone often too broad?
Two users with the same role may be assigned to different portfolios, products, geographies, legal entities, resource classes, or data-classification branches. The role describes function; it does not necessarily describe where that function may be exercised.
How does ABAC complement RBAC?
ABAC evaluates current subject, workload, resource, action, purpose, application, environmental, and state attributes. Those facts can narrow or qualify the broad permission associated with the role.
What is Taxonomy-Scoped Authorization?
It is the runtime evaluation of whether a subject may perform an action on a resource by combining role permissions with versioned Taxonomy Scope, resource labels, tenant and legal-entity boundaries, purpose, state, hierarchy, exceptions, and policy obligations.
What is an Authorization Taxonomy?
It is a versioned governed concept scheme or set of concept schemes used as authorization inputs for subjects, resources, actions, purposes, and evidence.
What is Taxonomy Scope?
Taxonomy Scope is the canonical set of concept grants, restrictions, purposes, and exceptions associated with a subject, Execution Instance, resource, or capability.
What is a Scope Closure?
A Scope Closure is the explicit set of concepts included after applying declared inheritance direction, depth, exception, deny, multi-label, and version rules to one or more Scope Paths.
Can one role cover multiple business scopes?
Yes. That is one of the main reasons to separate stable role function from versioned domain scope. Users can share a role while receiving different permitted portfolio, geography, product, legal-entity, or classification scopes.
How is tenant isolation different from taxonomy scope?
Tenant isolation is usually the outer organizational or customer boundary. Taxonomy Scope narrows authority inside that boundary to specific business branches such as portfolio, geography, product, legal entity, document class, or classification.
Can another tenant influence retrieval even if its text is filtered out?
Yes if global candidate generation occurs before tenant filtering. Ineligible candidates can consume ranking or context budgets and displace eligible evidence. Permission-aware retrieval constrains candidate generation before that influence occurs.
Are source ACLs or database row-level security enough?
They remain important local controls. The complete AI application can also cross vector indexes, caches, Context Assembly, models, tools, memory, outputs, and evidence, so the same scope semantics need to remain connected beyond the original source query.
How is scope applied to tools and APIs?
A capability can be visible to a role while object-level authorization still evaluates the exact tenant, resource, action, purpose, taxonomy, current state, policy, and delegated authority before invocation.
Can child agents or subgraphs get broader access than the parent?
The architecture is designed for equal-or-narrower delegated scope. A child boundary should not gain broader authority merely because it shares a runtime, tool registry, queue, or memory service.
What happens when scope changes while a workflow waits?
The Execution Instance retains the historical scope and taxonomy semantics that governed earlier boundaries. A Scope Compatibility Gate and current-state revalidation determine whether the next step may continue, narrow, require reapproval, migrate, or stop.
Can audit and replay views reveal out-of-scope evidence?
Permission-Aware Inspection can restrict evidence and replay to the viewer's current tenant, Taxonomy Scope, purpose, classification, retention, and source permissions.
Does strong tenant isolation require dedicated infrastructure per tenant?
Not always. Dedicated resources may be appropriate for some risks or contracts, but shared infrastructure can also preserve isolation when tenant and scope semantics are explicit, enforced, tested, and evidenced at every relevant boundary.
What is Scope-to-Effect Lineage?
It is the evidence chain connecting subject and workload scope, taxonomy version, resource labels, context, decisions, approvals, capabilities, outputs, and the resulting business effect.