# Attestor

The **Attestor** is the cryptographic heart of the KRNL Protocol. While executors run workflow logic, the attestor ensures that every step is secure, verifiable, and policy-compliant. It acts as the developer’s private guardian, responsible for attesting to the integrity of execution and safeguarding master secrets, without ever becoming a centralized point of trust.

### Role in the Protocol

At a high level:

* **Executor** = runs the workflow logic (open-source, community-audited).
* **Attestor** = enforces trust boundaries and signs off on the results (developer-controlled, security-hardened).

***

### Core Responsibilities

1. **Cryptographic Signing**
   * Generates execution signatures using **ephemeral keys** derived from a master secret.
   * Guarantees that every workflow run is uniquely bound to its execution context, preventing replay or forgery.
   * Signs both raw execution outputs and the **network attestation hash**, producing end-to-end verifiable proofs.
2. **Network Monitoring**
   * Acts as a **transparent interceptor** for all network traffic (HTTP, HTTPS, DNS).
   * Detects tampering, MITM attempts, or injection by monitoring every request and response.
   * Produces cryptographically sealed logs that provide forensic-grade auditability.
3. **Secret Management**
   * Safely holds the developer’s master key material.
   * Derives one-time-use ephemeral keys per execution, minimizing exposure.
   * Optionally integrates with external **Remote Signers** or hardware-based Trusted Execution Environments (TEEs) for heightened security.
4. **Execution Environment Validation**
   * Verifies that executors run in correct, reproducibly built sandbox environments (e.g., gVisor containers).
   * Enforces policies on which executors are authorized and under what conditions.
   * Provides an auditable chain of custody for every workflow step.

{% hint style="info" %}
Every attestor is anchored by a **developer-controlled master key**.

* **Who generates it?** The dApp developer (or organization) creates the master key when setting up their attestor.
* **How is it used?**
  * Never directly for signing.
  * Instead, it serves as the cryptographic seed from which **ephemeral execution keys** are derived per workflow run.
* **Where is it stored?**
  * Typically compiled into the attestor binary with advanced protections against reverse engineering.
  * Optionally isolated in a **Remote Signer** or **TEE (Intel SGX, AMD SEV, ARM TrustZone)** for hardware-backed security.

This means the master key never leaves the attestor environment, never appears on-chain, and is never reused. It exists purely as a local root of trust, bound to the developer’s attestor deployment.
{% endhint %}

***

### Attestation Data Structures

The attestor doesn’t just sign results, it builds a **multi-layered proof system**:

* **Request Attestation:** Every outbound API call is logged with full method, endpoint, headers, payload, and a timestamp.
* **DNS Attestation:** All DNS queries and responses are cryptographically recorded, ensuring transparency at the lowest layer.
* **Response Attestation:** Each inbound response (status, headers, payload, TLS metadata) is bound to its request and signed.
* **Network Summary:** A cryptographic digest of the entire execution session, aggregating request/response patterns into a compact verifiable proof.

Together, these structures transform the “black box” of off-chain execution into a **glass box,** anyone can independently verify exactly what happened, when, and under which conditions.

***

### Security Model

* **Isolation:** Attestors run in isolated gVisor environments, with optional TEE deployment for hardware-backed guarantees.
* **Ephemeral Keying:** No key reuse, no persistent signing keys exposed; every run is cryptographically unique.
* **Developer Authority:** dApp developers own their attestor, meaning only they define the policies, whitelists, and trust boundaries.
* **Auditability:** The attestor’s signed outputs can be verified both **on-chain** (via standard signature recovery) and **off-chain** (via forensic inspection of attestation logs).

***

### Why It Matters

Traditional oracles or middleware rely on trust in third-party operators. The attestor eliminates that dependency by giving developers full control over verification. This unlocks:

* **Regulatory-grade compliance** – produce audit-ready reports of every API call and signature.
* **User confidence** – end users can see verifiable evidence, not just promises.
* **Security resilience** – even if an executor is compromised, the attestor prevents forged results from entering the workflow.

In short: **Executors compute, attestors prove.** This clear division of responsibility is what makes KRNL’s architecture uniquely trustworthy.

### What's next?

{% content-ref url="vault" %}
[vault](https://docs.krnl.xyz/core-concepts/vault)
{% endcontent-ref %}