Proposed cybersecurity category · Lorasis
What is RTEP?
Runtime Trust Enforcement Platform
Lorasis is introducing Runtime Trust Enforcement Platform (RTEP) as a proposed cybersecurity category.
Runtime Trust Enforcement Platforms (RTEP) are a proposed class of cybersecurity solutions designed to continuously establish, verify, and enforce the trustworthiness of running workloads using independently verifiable integrity evidence.
Don’t assume trust. Verify it. Enforce it.
RTEP is designed to complement EDR, CNAPP, CWPP and runtime security solutions, not replace them: it addresses the distinct problem of trust verification and evidence-based enforcement.
This is a category proposal and design direction, not a claim of industry acceptance or a complete shipped Lorasis platform.
Why runtime trust needs more than a snapshot
A workload can change after admission, boot or deployment. Point-in-time attestation describes selected measurements at a particular time; it does not establish that later execution remains within an expected state. Continuous runtime trust needs a stated evidence scope, freshness requirements and a policy for re-evaluation.
Runtime integrity monitoring can inform workload trust verification, but events and measurements must be appraised, not simply collected. Missing, stale or conflicting evidence must remain visible. A prior pass does not permanently authorize a new action.
Conceptual evidence-to-action relationship. The diagram is not a claim of end-to-end delivery; Lorasis capability status is stated below.
Hardware-rooted trust and independent verification
A hardware root of trust can provide a reference for selected attestation claims. Cryptographic workload verification checks evidence provenance and integrity against known reference information; it does not prove that all relevant behavior was measured or that the workload's purpose is safe.
Lorasis Anchor: VISION. Intended path. Not current customer coverage. No processor, cloud or integration support is claimed here.
Evidence-based runtime security enforcement
The IETF RATS architecture separates the attester producing evidence, the verifier appraising it and the relying party making a decision. RTEP uses this distinction to explain how integrity evidence could inform bounded security policy, rather than allowing a measurement or AI recommendation to act as authority on its own.
Lorasis Decide / Enforce: NOT SHIPPED. Deterministic controls and authorised humans decide. AI may discover, explain and propose.
RTEP alongside EDR, XDR, CNAPP and CWPP
Detection and trust verification are related, not interchangeable. Established controls may include integrity features; the distinction below explains the proposed category's emphasis, not an exclusive capability claim.
| Control | Typical emphasis | Proposed RTEP focus |
|---|---|---|
| EDR / XDR | Detect, investigate and respond to suspicious activity across endpoints and other telemetry sources. | RTEP asks whether a workload's measured state meets an explicit trust policy, and how that evidence should constrain action. |
| CNAPP | Bring together cloud-security posture, risk and workload-protection capabilities. | RTEP proposes evidence-based runtime trust evaluation alongside those controls; it does not replace their broader risk context. |
| CWPP | Protect workloads using controls that can include vulnerability assessment, hardening and runtime detection. | RTEP focuses on independently checkable integrity evidence and its relationship to enforcement authority. |
| Runtime monitoring | Observe behavior, events and changes during execution. | RTEP adds an explicit question: what evidence supports a trust decision, how fresh is it, and who may enforce that decision? |
Questions for critical workloads and AI infrastructure
Critical infrastructure
What runtime evidence would support an authorized change to a consequential workload, and what remains outside observation? This is a validation question, not a deployment claim.
Enterprise workloads
Can infrastructure integrity assurance relate observed state to declared policy and authority? Zero Trust workload security still requires explicit scope and independent appraisal.
AI environments
Can an organization assess AI infrastructure integrity before a consequential action? Workload integrity does not establish that a model's answer or decision is correct.
Lorasis: current foundation and intended paths
Lorasis is introducing RTEP to make the connection between bounded evidence, trust evaluation and enforcement authority explicit. The cybersecurity Trust Operating System remains the long-term vision, not a currently complete product.
- Sense
- Current foundation
- Selected runtime-evidence paths. Shown in named, controlled internal workflows. Proof point being hardened. Not a production deployment and not an external demo.
- Anchor
- VISION
- Selected attestation and silicon-rooted evidence paths. VISION. Intended path. Not current customer coverage.
- Decide
- NOT SHIPPED
- Deterministic policy and authorised humans retain decision authority.
- Enforce
- NOT SHIPPED
- Bounded customer-local action remains subject to release and validation gates.
- Observe
- Proposed customer validation
- Independent observation and complete evidence-to-outcome linkage require customer validation.
- Prove
- Current foundation
- Provenant signed records cover named evidence slices. The broader end-to-end proof direction is not a current capability.
Signed and hash-linked records do not by themselves prove completeness, semantic correctness, absence of compromise, overall security, regulatory compliance or that an event occurred freshly.
Technical questions about runtime trust
Is RTEP an established industry standard?
No. Runtime Trust Enforcement Platform (RTEP) is a proposed cybersecurity category introduced by Lorasis. It is not presented as an accepted industry standard or an established Gartner or Forrester category.
Does hardware-rooted attestation prove that a workload is secure?
No. A hardware root of trust can support provenance and integrity checks for specific measurements. A verifier still needs relevant reference values, policy, freshness and declared scope. Evidence does not by itself establish correct behavior, absence of compromise or overall security. Lorasis's Anchor path remains VISION. Intended path. Not current customer coverage.
Why is point-in-time attestation insufficient for continuous trust?
A result describes measured state within its time and scope. Workload state, dependencies or policy may change afterwards. Continuous evaluation needs fresh evidence and explicit handling of stale, missing or conflicting information; a previous pass is not a permanent authorization.
How would runtime integrity evidence inform enforcement?
A verifier appraises evidence against policy. A relying party determines whether the result satisfies the requirements for a bounded action. Lorasis's proposed Decide and Enforce controls remain NOT SHIPPED. Deterministic controls and authorised humans retain decision authority; AI may discover, explain and propose.
Does RTEP replace EDR, XDR, CNAPP or CWPP?
No. These controls can address overlapping security concerns, but RTEP is proposed as complementary: a distinct focus on workload trust verification and evidence-based enforcement. It does not remove the need for threat detection, patching, vulnerability management or incident response.
Does Lorasis support particular CPUs, clouds or workload integrations?
This category explanation does not establish support for any processor, cloud, trusted execution environment or integration. CPU-based attestation is one technical approach within the broader attestation field, not a compatibility claim for Lorasis.
What can be established today?
Sense is Current foundation: selected runtime-evidence paths shown in named, controlled internal workflows. Proof point being hardened. Not a production deployment and not an external demo. Anchor is VISION; Decide and Enforce are NOT SHIPPED; Observe is Proposed customer validation. Provenant signed records cover named evidence slices, not complete end-to-end coverage.
Technical reference
IETF RFC 9334: Remote ATtestation procedureS (RATS) Architecture explains attestation roles, evidence appraisal and freshness. It is an informational architecture reference, not evidence that Lorasis implements or is certified against a particular standard.