Situational Access Control

Beyond Static Roles

Traditional RBAC (role-based access control) is static. You assign a role to a user. The role grants permissions. The permissions don't change based on what's happening. A manager can approve purchase orders regardless of whether the budget has been reviewed, the vendor has been vetted, or the request makes any sense at all.

This is a problem for any system, but it's especially dangerous for AI. When RARS executes operations autonomously, static permissions mean the AI can do anything its role allows, regardless of the business context. That's not how trust works in the real world. A manager can approve a purchase order, but only if the budget is available, the vendor is approved, and the amount is within their authority. The situation determines what's appropriate, not just the identity.

The Graph Is the Situation

In Poliglot, the knowledge graph is a live, queryable representation of your operational state. Every business object, every relationship, every status, every observation is in the graph. This means the authorization system can query the graph at the moment of evaluation to determine whether an operation should be permitted.

RARS's IAM supports SPARQL ASK conditions on policies. These conditions execute against the live graph when authorization is evaluated, not when the policy is defined. The condition asks a question about the current state of the world, and the answer determines whether access is granted.

# Only allow approving a work order if a risk assessment is completed
wo:RequiresAssessmentCondition
    a rars-iam:Condition ;
    rars-iam:scope rars-iam:Resource ;
    rars-iam:sparql [
        rars-os:ask """
            ASK {
                ?scope a wo:WorkOrder .
                ?scope wo:riskAssessment ?assessment .
                ?assessment wo:status wo:Completed .
            }
        """
    ] .

This condition queries the graph at authorization time. If the work order doesn't have a completed risk assessment, the action is denied regardless of the caller's role. The situation changed, so the permission changed.

What This Enables

Situational access control makes policies that are impossible in traditional RBAC:

Process-dependent authorization: an action is only permitted when prerequisite steps are complete. Approvals require prior review. Dispatching requires prior approval. Each step gates the next.

Data-dependent authorization: access depends on properties of the resource being accessed. Confidential records require additional clearance. High-value transactions require senior approval. The data itself determines the permission level.

Context-dependent authorization: conditions can evaluate the authorization context (who initiated the workflow, how deep in the delegation chain the operation is, what the current process state is). This enables policies like "allow only if the request originated from a direct user interaction, not from a nested automation chain."

Temporal authorization: combined with the observation model's validity tracking, conditions can evaluate time-based rules. Access windows, approval expiration, and seasonal restrictions become expressible as graph queries.

Why This Matters for AI Trust

The fundamental challenge with AI operating systems is: how do you trust the AI to make the right decisions? Static permissions are too coarse. You end up either granting too much access (and hoping the AI doesn't misuse it) or restricting too much (and breaking legitimate workflows).

Situational access control solves this by making the graph itself the authority. The AI's actions are constrained not just by identity, but by the current state of the business. If the prerequisites aren't met, the operation is denied. If the data doesn't support the action, it's blocked. If the process is in the wrong state, it can't proceed.

This means you can grant RARS broad operational capability while maintaining tight control over when that capability can actually be exercised. The permissions are contextual, responsive to the live state of your operations, and auditable through the provenance system.

Composing Conditions

Conditions can be composed. Multiple conditions on a policy are AND-ed together: all must pass. Conditions can be negated with rars-iam:not. And because conditions are SPARQL ASK queries, they can express arbitrarily complex logic by querying any data in the graph.

This means your authorization model can be as simple or as sophisticated as your business requires. A startup might use basic namespace scoping. An enterprise with regulatory requirements might build conditions that enforce multi-step approval chains, segregation of duties, and time-bounded access windows, all expressed as graph queries against the live operational state.

Summary

Static roles aren't enough: identity alone doesn't determine what's appropriate in a given situation
The graph is the authority: SPARQL conditions query live operational state at authorization time
Process-dependent access: prerequisite steps must be complete before subsequent operations are permitted
Data-dependent access: properties of the target resource influence authorization decisions
AI trust through situational constraints: broad capability with contextual control over when it can be exercised
Composable complexity: conditions can express anything from simple namespace scoping to complex regulatory requirements