A private archive deserves
more than vague "secure" copy.
AtArchive may hold years of correspondence, attachments, files, meetings, people, and generated history. The more useful that archive becomes, the more seriously we have to treat permissions, user isolation, deletion, model processing, operational access, and the limits we tell you about.
The trust model starts before the data reaches us
Security is part of the archive workflow, not a badge added after the product is built.
Provider authorization
Supported Google and Microsoft archive flows use provider authorization rather than asking you to make your provider password an AtArchive credential. Exact scopes differ by product/source and must match the feature being used.
Least privilege
Archive workflows request only the provider access they need. The permissions for each supported source are explained with that source's archive flow.
Your archive needs hard boundaries
Email, files, calendar, People, Organizations, Search, generated intelligence, imports, usage records, and exports stay within the owning user and account boundary.
Verify the archive before you depend on it
When an account may be closed or access may end, import completion, coverage, source records, and test searches matter more than a generic "backup complete" promise.
Keep evidence underneath intelligence
Search results, histories, and interpretations should remain connected to source records. Generated prose is not a substitute for the underlying message, file, event, or evidence.
Secrets stay protected
Provider credentials and access tokens are kept separate from the archive records you use, with protected handling across the service.
How we keep the archive trustworthy
Trust is easier to understand when the service explains the permissions, storage, deletion, and processing that affect your records.
Provider permissions
Each source explains the permissions requested for Gmail, Microsoft email, Google Drive, OneDrive, and Microsoft Calendar, including how access can be refreshed or revoked.
Storage and protection
Your archive is protected in transit and at rest, with storage, backup, archive-tier, and geographic details described for the service.
Deletion and retention
Deletion information covers email, files, calendar, derived People and Organizations, indexes, generated intelligence, queues, logs, backups, and exports, including any retention windows.
AI/model processing
When a feature uses a model, its source scope, provider, region, retention terms, persistence, and user choices are explained alongside that feature.
Operational access and logging
Operational access, support, telemetry, sensitive logging, and incident response are handled as part of protecting the archive.
Trust questions change with the scenario
The same technical fact can matter differently depending on why you came to AtArchive.
Closing an old account
You need to know what was actually copied, whether the import completed, what remains at the provider, and what you can still use after disconnecting.
Close an old account safely →Leaving a job
Authorization matters as much as encryption. Technical access to employer or client records is not proof that you are allowed to retain them.
Leaving a job →Using archive intelligence
You need to know what records a feature can read, whether a model is involved, what the interpretation means, and how to get back to the evidence.
Archive Intelligence →What you should expect from us
Plain explanations
Provider scopes, processing choices, deletion behavior, and product limits should be explainable without requiring you to read our source code.
One consistent explanation
Scenario pages can use different language, but factual security statements should remain consistent and tied to the safeguards that affect your records.
Limits stated before they hurt you
Provider, format, size, model, search, and retention limitations should be visible before a user makes an irreversible account or data decision.