> For the complete documentation index, see [llms.txt](https://sestra.gitbook.io/sestra-whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sestra.gitbook.io/sestra-whitepaper/introduction/key-technologies.md).

# Key Technologies

Sestra is built on a set of core technical principles that prioritize simplicity, security, and privacy.
\
Rather than introducing new protocols or complex infrastructure, Sestra combines proven system design patterns into a focused access framework.

Below are the key technologies and design approaches that make Sestra work.

### **Session-Based Access Control**

At the core of Sestra is a session-based access model.

* **Instead of relying on**: user accounts permanent credentials long-lived API keys Sestra issues short-lived access sessions.
* **Each session**: is created only after requirements are met has a defined expiration time cannot be reused once expired.

This approach reduces risk and simplifies access management for both humans and automated systems.

### External Verification Signals

Sestra does not generate or manage verification data itself. Instead, it evaluates verification signals produced by external systems.
 These signals indicate whether predefined conditions have been fulfilled. Sestra only checks the result of verification, not the underlying data. This keeps Sestra lightweight and avoids unnecessary data handling.

### Policy-Driven Decision Engine

Access decisions in Sestra are driven by policies. A policy defines:

* what condition must be met
* how long access should last
* how many requests are allowed within a session

Policies are evaluated in real time for each request.
\
They are independent of user identity and do not require stored profiles.

### Event-Based Architecture

Sestra communicates with your backend through events. 

Key lifecycle events include:

* session created
* verification confirmed
* access granted
* session expired

This event-based model allows:

* clean integration
* asynchronous processing
* easy observability without exposing sensitive data

### Privacy by Non-Collection

Sestra achieves privacy by design, not by obfuscation.

The system is intentionally built to avoid collecting:

* user identity
* network identifiers
* behavioral history
* raw verification artifacts

By minimizing data collection, Sestra reduces both security and compliance risk.

### Stateless Middleware Design

Sestra operates as a stateless decision layer. 

It does not:

* execute workloads
* store application data
* maintain user profiles

Its responsibility is limited to:

* evaluating access conditions
* managing session lifecycle
* issuing access decisions

This design makes Sestra easy to scale and simple to audit.

### Built for Automated Systems

Sestra is designed for environments where:

* requests are generated by software
* access is programmatic
* identity is not always available or relevant

The framework supports:

* backend-to-backend communication
* autonomous agents
* machine-driven workflows

Without introducing additional friction or identity requirements.

### Why These Technologies Matter

Together, these technologies allow Sestra to remain:

* focused on access control
* lightweight to integrate
* safe for privacy-sensitive environments
* suitable for enterprise use
* adaptable to future verification methods

Sestra does not depend on any single technology choice.
\
It is designed to remain flexible as verification methods evolve.