Privacy Policy

Last updated: 2026-05-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.

Public data room and admin sign-in

The technical data room at /inside is public. Reading it does not require Google, GitHub, Supabase, or any other third-party OAuth provider.

The /sign-in route is now an operator-only admin login. If you use that admin workflow, Silo processes:

• the submitted admin password for verification only;
• a signed, HTTP-only session cookie that keeps the admin browser signed in;
• standard request metadata such as IP address, user agent, route, timestamp, and errors if the hosting platform logs the request.

The admin password is not stored in browser-readable storage, and the current portal runtime no longer uses Supabase for authentication or access management.

Retired gated data-room records

Public visits to /inside/* are served without per-user data room view logging. Legacy access_requests and dd_views rows from the earlier gated data-room period may remain in archived or retired infrastructure until they are exported, deleted, or expire under the retention policy.

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 any legacy gated-data-room rows associated with you, 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.