Technology architecture

Derive authority centrally. Validate it where work runs.

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 responsibilities

Full responsibility model

Separate interaction from execution. Keep governance explicit.

Admin

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.

User Portal

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.

Resource Edge

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.

Site

Places one or more Resource Edges within a selected execution, connectivity, and operational boundary close to the protected resources they serve.

Complete request path

Resolve the request. Carry one selected route.

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

From the user browser through the User Portal and Resource Edge to a protected targetA person starts approved work in a user browser. The request enters through the SautX User Portal and follows one selected route to a Resource Edge and protected target. Admin manages the User Portal and governs durable identity, policy, routing, and scoped authority for the Resource Edge. The Resource Edge records execution evidence and returns it to Admin.User browsertask requestUser Portalpolicy-shaped experienceResource Edgevalidate + executeProtected targetAdmindurable authorityscoped authorityevidence return

Six core patterns

Six patterns turn policy into bounded work.

01

Task-derived authority

Resolve actor, purpose, resource, action, route, time, environment, and request context into scoped authority.

02

Resource-side validation

Do not treat UI state, network location, a bearer path, or an unverified role as sufficient authority at the point of use.

03

Selected request route

Tie each request to the User Portal, Resource Edge, execution Site, transport route, and protected target selected for that work.

04

Capability-shaped interaction

Present only the application runtime, credential, view, control, transfer, tool, mount, network route, model, endpoint, and output capabilities currently allowed.

05

Explicit crossings

Treat clipboard, file transfer, private-content inspection, and publication as governed operations rather than ambient side effects.

06

Lifecycle-linked evidence

Keep material request, decision, execution, crossing, publication, and closure events connected to the bounded work.

Request lifecycle

Carry authority from intent to expiry.

  1. 01

    Compose

    Define the actor, purpose, protected result, resources, operations, outputs, duration, and evidence needs.

  2. 02

    Resolve

    Admin selects the policy, capability, User Portal, Resource Edge, Site, route, target, and bounds.

  3. 03

    Validate

    The selected enforcement points verify scoped authority, current route, context, resource, and lifecycle state.

  4. 04

    Materialize

    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.

  5. 05

    Govern crossings

    Transfer, clipboard, inspection, publication, and other boundary movement remain separate decisions.

  6. 06

    Expire and reconcile

    Authority ends, sessions and work state close according to policy, local state is reconciled, and evidence remains connected.

SautX Fabric topology

Apply one model across selected Sites.

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

User browsers enter through managed User Portals and connect to selected Resource EdgesTwo user browsers enter through authenticated and authorized User Portals. One Admin control point manages both User Portals and governs identity, policy, routing, and scoped authority for Resource Edges in a data center, cloud, and branch. The highlighted request follows one selected path from a user browser through its User Portal to a Resource Edge and protected target.USEREXPERIENCEGOVERNANCEEXECUTIONTARGETSUser browserworkforce userUser browserpartner userUser Portalworkforce entryUser Portalpartner entryAdminidentity · policy · routingPORTAL MANAGEMENTSCOPED AUTHORITYResource Edgedata centerResource EdgecloudResource EdgebranchSystemsData + modelsTools + endpointseach request · user browser → User Portal → Resource Edge → protected target

Four boundary rules

Do not confuse reachability with authority.

Interface or image eligibility is not authority

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.

Connectivity is not permission

A transport path or reachable endpoint can carry an approved request, but the route itself does not grant the requested operation.

Admin governs without becoming the normal content path

Durable policy, resource definitions, lifecycle, and evidence relationships can remain administratively visible while sensitive content stays in the selected interaction and execution path.

Movement and inspection remain separate decisions

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

Place each kind of state with its owner.

User-facing state

User Portal owns interaction and private user-facing work state for the selected product workflow.

Protected-resource data

Resource Edge and Site own native execution and protected-resource data close to selected systems and resources.

Governance metadata

Admin owns durable governance and evidence relationships without becoming the normal sensitive-content path.

Explicit movement

Transfer, publication, and exceptional inspection remain explicit operations with separate authority.

Deployment qualifications

Logical boundaries stay stable. Operational responsibility varies.

Placement and availability

Compact and distributed placements can preserve the logical role model. Packaging, redundancy, failure behavior, scaling, and availability depend on the deployment and release.

Transport and networking

Configured routes, Site networking, firewall policy, name resolution, egress, and transport behavior remain deployment responsibilities.

Certificates and secrets

Certificate issuance, rotation, secret ownership, native credentials, and integration-specific trust require explicit operational ownership.

Protected targets

Target permissions, hardening, availability, data controls, protocol behavior, and resource-side logging remain part of the complete security posture.

Start with the work

Bring the architecture question. Trace the request path.

Contact SautX about responsibility boundaries, routing, deployment placement, execution, crossings, lifecycle, state, and evidence. Do not include sensitive operational material.

Contact SautX