How Starchild helps manage your agent's data and security

One of the biggest concerns users have when running agents and AI systems is security. Managing infrastructure, access controls, encryption, and audit trails at a high standard is difficult for even the most advanced of users. Starchild handles this so you don't have to, but does so in a transparent way so you know exactly what is accessed, when, and why.

Starchild's approach is grounded in a core principle: decentralization and privacy shape how we build from the start. We minimize unnecessary access and keep critical actions traceable. At the same time, we are actively researching and developing options for verifiably private hosting so users can choose even stronger decentralization over time.

Access Only When You Request It

Starchild runs your agents inside isolated containers on managed infrastructure. Each container holds your agent's memories, your files, and other materials your agent works with. Starchild handles the container itself (creating it, recovering it if it crashes, scaling resources), but does not read what is inside unless you ask.

It is important to distinguish between two things. Your Starchild agent runs inside the container and has full access to everything in it, as you intend. The Starchild team, however, does not access the contents of your containers by default.

Access to the contents of a container by the Starchild team occurs only when you explicitly request support. When you request support, access follows the principle of least privilege. It is limited to what is necessary to resolve the issue and should remain traceable.

Model Training Policy

Starchild does not use user code, logs, business content, or runtime data to train models. This holds unless a user explicitly authorizes it through a separate agreement, which we may choose to offer later as we scale our open economy and allow users to monetize their activities.

Infrastructure Layer

Starchild runs on Fly.io infrastructure. Fly.io operates a single SOC 2-compliant platform used by all customers. The controls include SSO for internal access, phishing-resistant 2FA, default-deny role-based access, WireGuard mesh networking, mutual TLS between services, Linux LUKS encryption at rest, Firecracker virtualization for compute isolation, and certificate-based SSH with audit trails.

SOC 2 status confirms that audited controls exist around access management and security processes. It indicates that access, when it occurs, should follow documented and auditable paths.

Despite all these protections, we still recommend that for high-sensitivity material (private keys, seed phrases, long-lived production credentials, customer records, or confidential source code), users should apply additional protections rather than rely solely on platform encryption.

Time Machine Snapshots

Starchild treats user data safety as a shared responsibility. We encourage users to keep their own independent backups of important data, especially for business-critical files, code, credentials, trading strategies, automation scripts, or other high-value assets.

In addition to user-side backups, Starchild provides a safety net through the Time Machine feature. Time Machine automatically creates daily snapshots of user data disks and keeps a default snapshot history for the most recent 5 days. These snapshots are designed to provide a recovery option when a user needs to restore or rescue data after accidental deletion, corruption, runtime failure, or other unexpected issues.

This feature is part of Starchild’s broader approach to data safety: reduce the chance of irreversible data loss, provide practical recovery options, and make user environments more resilient when unexpected failures happen.

User-Side Protections That Still Matter

Platform controls and user practices work together. Recommended steps for sensitive workloads include:

• Avoid storing private keys, seed phrases, or high-privilege credentials in plaintext for extended periods.

• Use short-lived tokens or rotatable credentials where feasible.

• Store secrets in a dedicated secrets manager.

• Rotate API keys on a regular schedule.

• Use separate, limited-permission credentials for different agents and environments.

• Maintain independent backups.

Continuing Work on Verifiable Privacy

Our current model relies on policy, access controls, and infrastructure-level encryption. We are actively researching and developing options that would allow users to choose verifiably private hosting, where even platform operators cannot access the environment under defined conditions.

This work is ongoing and adds some interesting narratives to future iterations of Starchild. We intend to be on the leading edge of decentralization and adoption of AI technologies, giving additional utilities to WOO token holders.

Originally published on X: https://x.com/StarchildOnX/status/2059248951145251208