Secure Photo Sharing App: What AI Can Access

What makes a photo sharing app secure in 2026

Viallo is a private photo sharing platform: photos are stored at full resolution, anyone you send a link to can open the album in a browser without making an account, and you can revoke that link whenever you want. It is not end-to-end encrypted, and this page is not going to pretend otherwise - Viallo can technically read the files it stores, the same as Google Photos or Dropbox can. What it does differently is how it hands access to an AI assistant.

A secure photo sharing app in 2026 is one where an AI assistant's access is a named, separate, revocable grant rather than a single switch. Viallo does this through an MCP server with four independent scopes - profile.read, albums.read, albums.write and share_links.manage - and every call an assistant makes is written to your activity log. Google Photos takes the opposite approach: Ask Photos is a Gemini feature inside the app, Google's own privacy hub for it says "We may process your photos and videos to improve edits or make inferences", and the list of photos a query studied is attached to a feedback report you choose to send rather than shown to you as a log. If your real requirement is that the provider cannot read your files at all, neither qualifies - Proton Drive and Ente are the end-to-end encrypted options.

For most of the last decade, "secure" in photo storage meant encryption in transit, encryption at rest, and a clean breach record. All three still matter, and none of them says what an assistant you connect can read, change or delete.

What "read access" actually means

"Read access" hides at least three different powers, and a consent screen that shows one line per app does not tell you which of them it covers.

• Reading the index: album names, how many photos are in each, when they were created, when they were last touched. This is the least sensitive layer and it is usually enough to answer "which albums do I have from last summer."
• Reading the metadata attached to each file: captions, tags, filenames, capture dates, and place names derived from GPS coordinates. A timeline of where you were is a timeline of where you were, whether or not anyone looked at the pictures.
• Reading the file itself: the actual pixels. This is the only layer where a model can tell you what is in the photograph.

The distance between layer two and layer three is the entire privacy question. On Viallo's MCP server the two are different tools with different behavior. The search_photos tool matches only captions, tags, filenames and place names, with capture dates used to order the results, because there is no object detection, face recognition or content search anywhere in the pipeline. "Find photos from Rome in June" works. "Find the photo with the red balloon" cannot work, and no amount of asking nicely will make it work. view_photo is the single tool that returns actual pixels, it runs when you explicitly ask to see a photo, and the log entry for each call records which photos it handed over.

There is a second asymmetry. When a service analyzes your library to make it searchable, it builds derived data - face records, object labels - and that derived data outlives the moment of the request. Amazon's image recognition page says it will "collect, store, and use records of individual faces" and retains that data "until you turn off the applicable tagging feature or your account is closed." A grant that only ever produced request-time answers leaves nothing behind when you revoke it; a feature that tagged your library leaves its tags until you switch the feature off.

Worth separating from all of this: the "allow photo access" prompt on your phone is a different layer entirely. That one governs what an app installed on your device can read out of your camera roll. This page is about the layer above it, where one service authorizes another service over the internet, and tightening either one does nothing for the other.

Can AI see my photos?

Yes, if you grant it - but "grant it" covers two architectures that produce very different outcomes. Knowing which one you are dealing with tells you more than any privacy policy will.

Architecture A: analysis on the service's side

The service analyzes image content so it becomes searchable. Amazon Photos states that it uses "image recognition technology to analyze and apply tags to your photos and videos", which lets you search "by people, objects, actions, and scenes." Google describes Ask Photos as a way to "ask questions about your photos and albums". The tags Amazon describes exist before any assistant asks anything.

Architecture B: request-time metadata

The service answers narrow questions about your library from text that you or your camera produced, and hands over an actual photo file only when you name one. Nothing is analyzed in bulk, because there is nothing doing the analyzing. The trade-off is not small: this architecture cannot answer questions about visual content.

Architecture A is more useful. Architecture B is more private. Anyone selling you both at once is selling you something else.

The table below comes from each service's own help, developer or product pages, read on 26 October 2026; every cell is a row in the dataset with the sentence that supports it. "Not documented" means the pages read describe no such control, not that a test found it absent. Sources: Viallo MCP, Viallo privacy, Google Photos Gemini privacy hub, Google Photos Library API scopes, Amazon Photos image recognition, Dropbox OAuth guide, Dropbox file activity, Apple Intelligence, Proton Drive, Ente.

Two things stand out. The scoped grants that do exist outside Viallo, Google's Library API and Dropbox's, are built for third-party developers rather than for the AI features the services ship themselves. And no service except Viallo documents a log that tells you which photos an AI feature or connected app opened.

Securing the photo app is only half the job. Once a photo reaches an assistant, that assistant's own rules apply. Anthropic's privacy policy says "We may use your Inputs and Outputs to train and improve Anthropic AI models, unless you opt out through your account settings", and Google's Gemini Apps notice says Gemini Apps information is processed "so that we can provide, maintain, improve, and develop Google products, services, and machine learning technologies." That is a setting on the assistant vendor's side, and no photo app can turn it off for you.

Why write access should be a separate grant

Read mistakes are embarrassing. Write mistakes are permanent. If an assistant reads an album you did not intend it to read, you have a privacy problem you can at least reason about. If it deletes one, you have a data-loss problem, and reasoning about it does not bring the files back. Those two risks do not belong behind the same switch.

Viallo's connection flow uses OAuth 2.1 with PKCE - the Proof Key for Code Exchange mechanism specified in RFC 7636 - and a scoped consent screen. Four scopes exist: profile.read for your plan and storage usage, albums.read for browsing and metadata search, albums.write for organizing, and share_links.manage for creating and revoking share links, where creating one also needs albums.read for a view-only link or albums.write for contributor and admin links. The consent screen lists exactly the scopes the assistant asked for, and the token carries nothing else. An assistant connected read-only is structurally unable to change anything, because the access token does not carry the scope and the call is rejected at Viallo's server. A read-only token is a server-side guarantee, not an instruction you are hoping the model follows.

The reason to mean it when you approve albums.write is what sits at the bottom of that scope. Deleting through it is permanent: delete_album and remove_photo_from_album remove the files from storage, and there is no undelete - not through MCP, and not in the app either. Compare that with Google Photos, whose help page says deleted items "will stay in your trash for 30 days before they are permanently deleted", or with Dropbox, whose plans page lists 30 days to restore deleted files on the individual plan and 180 days on the team plan. A trash window is a safety net for a careless grant. Viallo has no such net, and the consequence of that design is that read-only is the correct default for an assistant.

Sharing is separated out for the same reason. share_links.manage is its own scope because the ability to publish is a different power from the ability to organize, and it still needs album access on top - albums.read for a view-only link, albums.write for contributor and admin. An assistant that can create share links can make an album reachable by anyone holding the URL. That may be exactly what you want when you ask it to send your parents a link that expires in 30 days - but it should be a thing you granted on purpose. The full tool list and what each scope covers is documented on the Viallo MCP page: 18 tools in total, grouped by the scope that unlocks them.

For context on the standard itself: MCP, the Model Context Protocol, is an open standard Anthropic published on 25 November 2024 that lets AI assistants call tools in other services. It is not a Viallo invention and it is not proprietary. What varies between services is how finely the consent is sliced, and what the defaults are.

What an activity log is actually for

A permission list tells you what could happen. An activity log tells you what did. You need both.

A useful log answers three questions per entry: when, which connection, and which resource."An app accessed your account on 3 August" answers none of them. On Viallo, every tool call an assistant makes is written to the user's activity log with the connection that made it, a view_photo call - the only call that hands over actual pixels - is refused if its log entry cannot be written, and security activity entries are kept for 90 days. That retention window is long enough that you can look back after you notice something odd, rather than only while you are already watching.

Among the other services in the table, Dropbox is the one whose help pages describe a user-readable activity record: its file activity list shows "who performed an action and when the action happened", file by file. Even a good log is after the fact. It cannot undo a grant that was too wide at the start.

How to audit what you already connected

Do it in this order.

1. List every assistant you have linked to a photo service. Check Claude, ChatGPT, Gemini, Copilot, and any IDE or desktop client you have configured with connectors.
2. Open the photo service's own connected-apps page, not the assistant's. The assistant lists what it believes it has. The service lists what it actually issued tokens for. When those two disagree, the service is right.
3. Read the granted scopes line by line. Anything containing write, delete, manage or full - ask yourself whether you consciously agreed to it, or whether it was pre-checked and you clicked through.
4. Check the grant date and the last-used date. A connection you set up once out of curiosity and never used again is pure liability with no upside.
5. Read the activity log for the period since the grant. You are looking for reads of albums you would never have asked about, and for activity at times you were not working.
6. Revoke anything you do not recognize or no longer use. On Viallo that is /settings/connected-apps, which deletes the tokens immediately, so the assistant loses access on its very next call. Access tokens also expire on their own after an hour, and the security activity entries stay for 90 days after revocation so you can still review what happened.
7. Reconnect read-only if you still want the integration. Grant write later, deliberately, at the moment you actually need the assistant to organize something - not preemptively because the screen offered it.
8. Fix the assistant side too. Open its data controls. Anthropic trains on consumer Claude conversations unless you opt out, and Google uses Gemini Apps information to develop its machine learning technologies; that is a switch on the assistant vendor, not on your photo app.

Picking a private photo sharing app that does not train AI on your photos

Three questions separate the options. Does the service analyze image content on its servers? Is an AI connection scoped and revocable, or a single switch? And can the provider read your files at all?

On the last question the answer is the same for Viallo as it is for Google Photos. Viallo is not zero-knowledge and not end-to-end encrypted, and it can technically decrypt what it stores. Proton Drive says it encrypts files "right on your device before they're uploaded to the cloud, so only you hold the keys to unlock them", and Ente runs its face detection on the device. That is a stronger guarantee than scoped access. It also does not cost you account-free viewing: Proton's shareable link page says recipients "don't need a Proton Account to open a public link", and Ente's public links open "without an app or account", with the decryption keys embedded in the link. Sharing an Ente album directly with a person, rather than by link, does need an Ente account.

On an iPhone, Advanced Data Protection gives iCloud Photos the same property without changing apps. Apple's support page calls it "an optional setting", says that with it on "Apple doesn't have the encryption keys needed to help you recover your end-to-end encrypted data", and lists "the Shared Albums feature in Photos, and sharing content with "anyone with the link,"" among the things it does not cover. For a page about sharing, that last exception is the one that matters: the albums you share sit outside the encryption.

On training, Viallo's privacy policy says it "never uses your photos for AI training", Ente's home page lists "No Training", and Google says "We don't train any generative AI models outside of Google Photos with your personal data in Google Photos."

Where Viallo lands is a middle position. You do not get cryptographic impossibility. You get full-resolution storage, photos served from the link you created, and AI access sliced into four scopes you can grant, inspect and revoke one at a time. MCP access is included on every plan, including the free one - 2 albums, 200 photos, 10 GB, no card - and your plan limits still apply to whatever an assistant does, so asking it to create a third album on a free account fails exactly the way it fails in the app. The plan comparison spells out where the ceilings are.

If you want one test to apply to any secure photo sharing app you are evaluating, make it this: the default is the policy. What a service lets you turn off matters far less than what it turned on for you before you read the screen.

How was this checked?

On 26 October 2026 we fetched the help, developer and product pages of Viallo, Google Photos, Amazon Photos, Dropbox, Apple, Proton Drive and Ente with curl and Python, and kept, for every value on this page, the sentence that supports it and its URL. Viallo's own claims were also read in its source code. The results are in dataset.csv, and check.py re-fetches every page and reports whether each quote is still there. Dropbox's AI help page returned a bot challenge, so whether Dropbox analyzes image content is marked not checked.

Frequently Asked Questions