Security Model

The security model of Ollm is designed around explicit trust boundaries and minimized assumptions. Rather than relying on policies or access controls alone, Ollm uses hardware-enforced isolation and cryptographic verification to reduce reliance on intermediaries.

This section defines what Ollm is designed to protect against and what it intentionally does not.

Threats Ollm is designed to mitigate

Ollm is built to mitigate the following classes of risk:

• Unauthorized access to prompts and outputs

  Prompts and responses are processed exclusively inside Trusted Execution Environments (TEEs). They are never exposed to Ollm services, operators, or underlying infrastructure outside the enclave.

• Infrastructure-level compromise

  Host operating systems, hypervisors, and cloud administrators cannot inspect inference data due to hardware-enforced memory isolation.

• Malicious or curious insiders

  Ollm operators and provider personnel do not have access to plaintext inference data, reducing insider risk to the control plane only.

• Unverifiable provider behavior

  Hardware attestation provides cryptographic proof that inference was executed in a trusted environment, removing blind reliance on provider claims.

• Post-hoc trust failures

  Each request produces verifiable artifacts, enabling after-the-fact audits and independent validation.

Threats outside Ollm’s scope

Ollm does not attempt to solve or guarantee protection against:

• Compromised client environments or API key leakage
• Malicious prompts or unsafe model behavior
• Data exposure before requests are sent or after responses are received
• Vulnerabilities inside model weights or training data
• Non-attested execution paths outside supported TEEs

These exclusions are intentional and allow security teams to reason clearly about shared responsibility.

Insider, provider, and infrastructure risks

Encryption & Key Management

Ollm’s claim of “military-grade encryption” maps to specific, verifiable protections across the request lifecycle.

Encryption in transit

• All communication between clients, Ollm, and model providers uses industry-standard encrypted transport (TLS).
• Requests, responses, and attestation artifacts are protected from network-level interception.

Encryption in use (TEE)

• Prompts and responses are encrypted in memory while being processed inside TEEs.
• Data remains inaccessible to the host OS, hypervisor, and control plane services.
• Decryption occurs only inside the trusted execution boundary.

Control plane protections

The Ollm control plane handles:

• Authentication and authorization
• Request routing to the user-selected model
• Metadata and verification coordination

It does not process or store plaintext prompts or outputs. Control-plane access is restricted and auditable.

Key ownership and handling

• Encryption and attestation keys are hardware-backed and managed by the underlying TEE platforms.
• Signing keys used for attestation are rooted in vendor-specific hardware trust anchors.
• Ollm does not manage or rotate keys that can decrypt customer inference data.

This design removes Ollm as a key custody risk.

Data Handling & Retention

Ollm follows a strict zero-retention model for inference data.

Prompts and responses

• Prompts are not stored
• Responses are not stored
• No prompt or output content is logged
• No replayable inference data is retained

Once a request completes, plaintext inference data exists only transiently inside the TEE and is then discarded.

Logging behavior

Ollm logs non-sensitive operational metadata only, such as:

• Request identifiers
• Model name
• Provider
• Execution status
• Latency and token counts
• Attestation and verification status

This metadata is sufficient for observability and auditing without exposing content.

Public dashboards and visibility

Ollm dashboards may display:

• Aggregate request counts
• Model and provider usage
• Latency and cost metrics
• Attestation status (e.g., Verified, Pending, Failed)
• Cryptographic hashes and signatures for verification

They never display prompts or responses. Anyone viewing the dashboard can see verification outcomes and attestation artifacts, but cannot reconstruct or infer the underlying data.

Retention defaults and controls

• Inference data: not retained
• Attestation artifacts: retained for verification and audit purposes
• Operational metadata: retained for monitoring and billing

This separation enables transparency and auditability without compromising confidentiality.

By combining zero data retention, hardware-backed encryption, and verifiable execution, Ollm provides a security model that is auditable, defensible, and suitable for regulated or high-risk environments without requiring customers to trust the platform blindly.