Does Aiden Store Your Data?

Aiden’s current development-board architecture has no Aiden-hosted backend — but that doesn’t mean no data is ever stored in every Aiden deployment, and we want to be precise about the difference.

The key distinction is between data we collect, data retained locally in your deployment, and data sent to a model or speech provider you choose. Aiden is a physical mobile AI agent device built to interact with real smartphone and computer interfaces. That job can involve screen content, voice input, prompts, preferences, and action context, so we want to separate what we’ve confirmed from what we haven’t fully documented yet.

How Aiden data storage works in the current development-board architecture

We built Aiden on a bring-your-own-provider architecture. The current development board captures a connected device display through HDMI capture, sends screenshots to a multimodal model endpoint you configure, and controls the target device through USB HID input such as keyboard, pointer, or touch commands.

For voice interactions, the board records audio, performs voice activity detection on the device, and uses the speech-to-text, language-model, and text-to-speech endpoints you’ve selected in your configuration.

Here’s what we can say plainly:

• We don’t run an Aiden-hosted backend in the current development-board architecture.
• Screenshots, audio, and text go to the endpoints you configure — not to us.
• You can configure external services, local models, or your own deployment.
• Our firmware is open source, so you can inspect it yourself.
• Self-hosting changes the route your task content takes, depending on how you set up your deployment.

This is a deliberate departure from earlier generations of cloud-centered AI software. In many connected systems, the product provider, storage layer, and model provider are tightly coupled. We’ve split those roles apart: you choose the model and speech-service endpoints, rather than your task content routing through infrastructure we operate.

That doesn’t mean every bit of information stays transient, and we’re not going to pretend otherwise. Aiden also supports persistent device-specific context, user preferences, and skill optimization. That means Aiden data storage can include deployment-level context or preferences — we just haven’t yet published the exact storage location, format, duration, or deletion process, and we’d rather tell you that directly than leave it vague.

For builders, the practical takeaway is clear: your configuration matters as much as the device itself. A cloud model endpoint, a self-hosted model, and a local model can create materially different data flows.

What Aiden data storage may include during a real-device task

A real-device AI agent encounters information differently than a conventional chatbot does. It may operate around visible interfaces, spoken instructions, application windows, and task history. We designed Aiden to see a connected device screen through HDMI capture and interact through USB HID, rather than relying on an app installed on the target device.

That mechanism is worth understanding, because it shapes what content can enter a task flow.

Screen and interface content

A screenshot can contain far more than the immediate task. Notifications, conversations, documents, open tabs, contact details, authentication prompts, and enterprise content may all be visible. We send screenshots to the multimodal endpoint you select.

That means screen content can leave the board when you configure a remote endpoint. We won’t claim that all screenshots are permanently stored, never cached, or never retained — we haven’t yet published a complete account of screenshot buffering, caching, or how each provider handles retention on their side.

Voice, prompts, and task instructions

Voice mode involves recorded audio and the STT, LLM, and TTS services you’ve configured. Written prompts and task instructions also go to your configured endpoints. This is central to how Aiden handles data: whichever provider you select becomes part of your task’s data path.

For sensitive work, don’t treat your provider configuration as a minor implementation detail. Its policies, regional options, logging controls, training settings, and retention practices directly affect your privacy outcome.

Context, preferences, and skills

Aiden supports persistent memory, device-specific context, user preferences, and skill optimization. These capabilities make repeated interaction more useful, but they also raise fair questions about local persistence that we want to answer honestly.

We haven’t yet published:

• The precise data schema we use for memory or preferences.
• Whether you can inspect, disable, export, or clear stored context.
• How long context or skill-related information persists.
• Whether backups, traces, or diagnostic records exist in a given deployment.

That’s why our answer to "does Aiden store your data" is precise rather than absolute. We don’t run a backend for the current architecture — but persistent context means a deployment may still retain certain information locally, and we’re not going to gloss over that.

Aiden data storage questions we haven’t answered publicly yet

We don’t think a technical repository alone fully covers Aiden privacy. Open-source firmware makes our architecture inspectable, but inspectable code isn’t the same as the complete disclosure you need to evaluate personal information, logs, deletion, or security operations.

We don’t yet have an official privacy-policy page live on the aidenai.io domain. If you come across a similarly named policy on another domain, don’t treat it as ours without direct confirmation from us.

Here’s what we haven’t documented publicly yet:

We’d rather you not read this list in either direction. The absence of a published disclosure doesn’t prove we collect that information, and it doesn’t prove we don’t. We just haven’t documented it publicly yet, and we’d rather say so than let you assume either way.

Our repository includes a deploy/langfuse area related to observability and tracing. It’s a useful thing for you to review technically, but its presence doesn’t mean tracing is enabled by default, used in every deployment, or receiving personal information.

Aiden security deserves the same precision. Our firmware is public and inspectable, and our current architecture has no backend — but neither fact alone establishes our encryption standards, secure update process, penetration testing, incident response plan, or freedom from vulnerabilities. We haven’t published a complete security architecture yet either.

How Aiden data storage depends on your configured providers

Our bring-your-own-model approach gives technically literate users real choice, but it also puts real responsibility in your hands. The same Aiden task can have different data implications depending on whether your configured endpoint is a cloud provider, a locally run model, or infrastructure you operate yourself.

Ask yourself these questions before sharing sensitive material:

Our position is specific: screenshots, audio, and text go to the model and speech-service endpoints you configure, not to a backend we operate. That’s designed to support a deployment built around infrastructure you control.

Still, local processing isn’t automatically a complete privacy guarantee. Local files, device access, backups, configuration secrets, and operational logs need their own controls regardless. Cloud processing isn’t automatically unsuitable either, as long as the provider you pick has safeguards, terms, and retention options that fit your task.

For more general guidance, the NIST Privacy Framework covers privacy risk management, while the OWASP AI Security and Privacy Guide covers risks like sensitive-data exposure and prompt injection. These are general frameworks we’re pointing you to, not claims about our own implementation.

Aiden data storage, human control, and the practical bottom line

Human control matters when an agent interacts with real interfaces, but control over an action isn’t the same as control over data. You can interrupt, redirect, or confirm a task while screenshots, prompts, voice input, or outputs are still being transmitted to your configured endpoint.

We built Aiden around visible human control, interruption, redirection, and meaningful confirmation. Those are valuable boundaries for a physical mobile AI agent working with actual phone and computer interfaces. But we want you to see them as one layer in a larger privacy and security practice, not the whole picture.

Here’s where we stand, plainly:

• The current development-board architecture has no Aiden-hosted backend.
• You configure the model, STT, and TTS endpoints that receive your screenshots, audio, and text.
• Our self-hostable, open-source firmware gives builders a real path to review and shape their own deployment.
• We support persistent context, preferences, and skill optimization, so claiming that no data is ever stored would be misleading, and we won’t claim it.
• We haven’t yet published complete details on data retention, deletion, logs, security controls, storage locations, or provider processing terms.

Before you use a real-device AI agent with private screens, voice data, credentials, or sensitive personal information, check our latest materials and review the privacy controls of every endpoint you configure.

Technical readers can explore the Aiden firmware to inspect our current open-source development-board runtime. You can also visit the Aiden GitHub organization to follow ongoing development.

Join the Aiden Discord community to discuss physical AI agents, real-device automation, and the engineering behind Aiden. Our engineers are active in the community and welcome technical questions.

Explore and star Aiden on GitHub. If you find a reproducible issue, a compatibility gap, a documentation gap, or have a technical proposal, open an Issue — we’d like to hear it.

Aiden data storage FAQ

Does Aiden store your data?

Our development-board architecture has no Aiden-hosted backend. Screenshots, audio, and text go to endpoints you configure. That said, we support persistent context, preferences, and skill optimization, and we haven’t yet published their retention or deletion behavior. So it would be too broad for us to say that no data is ever stored in any Aiden deployment — we don’t want to claim that.

What personal information does Aiden collect?

We haven’t yet published a complete personal information inventory covering accounts, contact forms, website analytics, support communications, or community services. What we’ve documented so far focuses on task-related data flows, not a full privacy disclosure.

What is Aiden’s privacy policy?

We don’t have an official privacy policy live on the aidenai.io domain yet. Check our official site for the latest documentation before relying on any privacy or legal statement.

How long is Aiden data retention?

We haven’t published a data retention period yet. We support persistent context and preferences, but we haven’t specified storage duration, location, or deletion controls.

Does Aiden send screenshots to the cloud?

We send screenshots to the multimodal model endpoint you configure. If you configure a cloud provider, screenshots go to that provider. We also support local-model and self-hosted approaches — the resulting data flow depends entirely on how you set up your deployment.

Is Aiden secure?

Our firmware is open source, so you can inspect it yourself, and our current development-board architecture has no backend. But we haven’t yet published a complete security architecture, encryption specification, certification, penetration-test report, or vulnerability-disclosure policy.