Task-derived authority
Resolve actor, purpose, resource, action, route, time, environment, and request context into scoped authority.
Technology architecture
The Periscopic Access Framework defines how durable governance, worker-facing interaction, and execution near protected resources cooperate without treating interface state or connectivity as authority.
Review the responsibilitiesFull responsibility model
Owns durable identity and authorization relationships, policy, resource and Site definitions, route selection, capability derivation, lifecycle decisions, evidence relationships, and administrative metadata. It is not the normal sensitive-content path.
Owns discovery, task entry, worker-facing interaction, allowed controls, private user-facing work state where applicable, review, and publication initiation. It consumes derived authority but does not manufacture it.
Validates scoped authority at the point of use, owns native resource or runtime integration, allocates and tears down session-specific runtimes, constrains current capabilities, governs local crossings, records resource-side evidence, and reconciles closure.
Places one or more Resource Edges within a selected execution, connectivity, and operational boundary close to the protected resources they serve.
Complete request path
The person or approved AI agent enters through a User Portal. Admin resolves identity, purpose, resource, action, route, time, environment, and request context. Scoped authority travels only along the selected User Portal, Resource Edge, Site, transport, and protected-target path. The Resource Edge validates it again before use.
Scroll horizontally to follow the request path
Six core patterns
Resolve actor, purpose, resource, action, route, time, environment, and request context into scoped authority.
Do not treat UI state, network location, a bearer path, or an unverified role as sufficient authority at the point of use.
Tie each request to the User Portal, Resource Edge, execution Site, transport route, and protected target selected for that work.
Present only the application runtime, credential, view, control, transfer, tool, mount, network route, model, endpoint, and output capabilities currently allowed.
Treat clipboard, file transfer, private-content inspection, and publication as governed operations rather than ambient side effects.
Keep material request, decision, execution, crossing, publication, and closure events connected to the bounded work.
Request lifecycle
Define the actor, purpose, protected result, resources, operations, outputs, duration, and evidence needs.
Admin selects the policy, capability, User Portal, Resource Edge, Site, route, target, and bounds.
The selected enforcement points verify scoped authority, current route, context, resource, and lifecycle state.
Resource Edge and Site materialize the selected application, protocol, model, sandbox, endpoint, mounts, or tools from eligible runtime definitions and expose only the currently supported capabilities.
Transfer, clipboard, inspection, publication, and other boundary movement remain separate decisions.
Authority ends, sessions and work state close according to policy, local state is reconciled, and evidence remains connected.
SautX Fabric topology
A SautX Fabric is a deployed PAF topology with one or more User Portals and Resource Edges connected through configured routes. Distribution does not itself grant permission; every request still depends on selected authority and local validation.
Scroll horizontally to follow the request path
Four boundary rules
A visible target, enabled control, remembered role, or administrator-approved image does not authorize resource use. Eligible images, including customer-specific images where supported, define known software and a maximum capability ceiling; the selected enforcement point still validates current scoped authority.
A transport path or reachable endpoint can carry an approved request, but the route itself does not grant the requested operation.
Durable policy, resource definitions, lifecycle, and evidence relationships can remain administratively visible while sensitive content stays in the selected interaction and execution path.
Permission to transfer or publish content does not automatically grant permission to inspect private content, and inspection does not automatically grant movement.
Conceptual capability model: effective capability = image ceiling ∩ task authority ∩ session state ∩ live runtime capability ∩ crossing rules.
Data and state responsibility
User Portal owns interaction and private user-facing work state for the selected product workflow.
Resource Edge and Site own native execution and protected-resource data close to selected systems and resources.
Admin owns durable governance and evidence relationships without becoming the normal sensitive-content path.
Transfer, publication, and exceptional inspection remain explicit operations with separate authority.
Deployment qualifications
Compact and distributed placements can preserve the logical role model. Packaging, redundancy, failure behavior, scaling, and availability depend on the deployment and release.
Configured routes, Site networking, firewall policy, name resolution, egress, and transport behavior remain deployment responsibilities.
Certificate issuance, rotation, secret ownership, native credentials, and integration-specific trust require explicit operational ownership.
Target permissions, hardening, availability, data controls, protocol behavior, and resource-side logging remain part of the complete security posture.
Start with the work
Contact SautX about responsibility boundaries, routing, deployment placement, execution, crossings, lifecycle, state, and evidence. Do not include sensitive operational material.
Contact SautX