Privacy Policy

Last updated: 2026-04-07

Silo is operated by Diego Sens. This page explains, at a high level, what data Silo processes, why it is processed, and how to request support or deletion.

Authentication and access requests

The sens.legal portal is gated. To request access to the technical data room, you sign in via Google or GitHub OAuth. When you sign in, Silo receives:

• your email address (verified by the OAuth provider);
• your display name and avatar URL as provided by the OAuth provider;
• your provider identity (Google account ID or GitHub user handle);
• a session cookie that keeps you signed in to sens.legal.

This data is stored in a row in the access_requests table on Silo's Supabase project. Diego reviews each request manually and either approves or leaves it pending.

Data room view tracking

When you visit a page under /inside/* (the data room), Silo logs a row in the dd_views table containing your user ID, email, the page path, your IP address, your user-agent, and a timestamp. This is used to understand how reviewers engage with the data room. It is not shared with third parties.

What data Silo may process

Depending on the feature you use, Silo may process:

• access and integration data, such as API keys, scope information, client identifiers, and marketplace auth metadata when enabled for a deployment;
• request telemetry, such as timestamps, IP address, user agent, route or tool name, latency, and trace_id;
• user-submitted content, such as search queries, prompts, uploaded PDFs, workflow payloads, memories, and conversation content;
• generated workflow artifacts, such as extracted text, structured analysis outputs, and review records;
• operational and security events, such as authentication failures, rate-limit events, and audit records.

Why this data is processed

Silo processes data to:

• authenticate and authorize access to the service;
• execute API, MCP, chat, and workflow features;
• store and retrieve workflow state and artifacts;
• detect abuse, investigate incidents, and protect the service;
• debug failures and improve reliability;
• comply with legal, contractual, and security obligations.

Sharing and subprocessors

Silo may rely on infrastructure and storage providers to run the service, including hosting, databases, object storage, and observability tooling. Data is shared only to the extent needed to operate the service and fulfill the purposes above.

Security summary

Silo is designed to run with access controls and auditability enabled in production, including:

• authenticated access for protected API and remote MCP surfaces;
• scope-based authorization for sensitive operations;
• rate limiting and abuse controls;
• structured logs with trace_id for incident investigation;
• protected operational endpoints such as /metrics.

No internet-facing system is perfectly secure, so please avoid sending secrets or unnecessary personal data unless your use case requires it.

Retention

Retention depends on the kind of data and the deployment context. A separate page describes the operational retention model:

• Data Retention Policy

Examples:

• session memories use explicit TTLs chosen by the caller;
• conversations can be deleted through product controls where available;
• workflow artifacts and audit records may persist while they are needed for operation, support, or compliance.

Requesting deletion

To delete your access_requests and dd_views rows, write to diego@sens.legal with the subject "Silo data deletion".

Changes

This policy may be updated as Silo's product surface, infrastructure, or compliance posture evolves. The latest version will be published at this URL.