Media processing involves parsing files supplied by users. A malformed image or video can exercise complex decoder behavior, so where that processing runs and which credentials it holds matter.
This article describes the separation and limits of 5AM's media services. It is not a security certification or a claim that a compromise is impossible.
Processing is separated, with exceptions
Video processing and several image-processing tasks run in dedicated services or workers. Moving those jobs away from account and billing request handlers reduces the amount of application state exposed to those particular processing paths.
Every file that reaches us is treated as hostile until proven boring. The practical consequence: decoding never happens in the API server.
The relevant question for each route is which bytes it accepts, how it validates and limits them, where decoding runs, and what that process can access. A diagram of a video pipeline alone does not answer those questions for avatar uploads or other image features.
Direct uploads reduce one data path
Large-file uploads can use a presigned flow: the API checks authorization and quota, then issues a time-limited URL for a particular storage object. The client sends the media to storage, and subsequent processing runs separately.
This avoids buffering that upload body through the API. It does not mean that every upload uses the same route or that files have no limits. Supported formats, storage quota, and route-specific limits still apply; Camera to Cloud, for example, has its own file restrictions.
Internal authentication is part of the boundary
Signed requests and callbacks help services check who sent work or reported its completion. The processing integrations use mechanisms such as HMAC signatures and timestamps, alongside deployment-level access controls where configured.
These controls have to be checked per integration. A signature protects the authenticated message; it does not validate the media's contents, remove parser vulnerabilities, or establish that every internal hop uses identical credentials or checks.
Different automation features have different permissions
Two kinds of generated-code execution should not be confused:
- The computational executor applies code restrictions, resource/time limits, and an allowlisted outbound-network path for its supported tasks.
- Managed Workflows run programs that operate on your library through scoped credentials and can contact external services. Their network access is open by design. Read the plan, code, and review findings before starting a workflow. Workflow permissions and limits.
Restrictions reduce exposure, but a sandbox is not proof that arbitrary generated code is safe. The permissions and data available to the particular job determine what it can do.
Scope credentials to the job
Use a read-only CLI token when a task only needs to read. Grant write or admin access only when the task requires it. AI character skills and token scopes work together; instructions in a prompt do not replace permission checks.
A camera credential targets one chosen album and is intended for uploading, not general library browsing or deletion. Revoke it when a camera is lost, returned, or no longer needs access. Check revocation and session-expiry behavior rather than assuming every active connection stops at the instant you click.
For server agents, a read-only 5AM token limits access to the 5AM library. Local custom commands run with the operating-system permissions you give the agent; those are a separate boundary. Server Agent setup and data flow.
Review sharing and AI data flows separately
Private library access, a public share, and an AI request are different operations. Review album permissions before sending a link and revoke access when the engagement ends. A recipient's ability to access a file depends on the sharing settings, not simply possession of the owner's album URL.
AI tools may send images, audio, summaries, or video proxies to a provider. Supported credit-backed requests pass through 5AM's proxy; BYOK uses your provider credential. Projects and outputs saved to your library remain stored in 5AM. Local rendering does not make all of those other steps local.
Questions or a suspected problem
Use 5AM support or email support@5am.app with the affected feature and a description. Do not include API keys, passwords, private client files, or a public exploit demonstration. We can arrange the information needed to investigate through the support conversation.
Keep an independent copy of originals you cannot replace, confirm upload completion, and review sharing settings deliberately. These operational checks complement the service controls; they do not depend on any single layer being infallible.
