Security Policy

Astrid handles call recordings, transcripts, notes, and matter data for law firms, much of it privileged. This page states what we actually do, with the same specificity about what we do not do. It is written for security reviewers, so where a control is partial or absent we say so rather than describing the ambition.

At a glance

Scope

This policy covers the Astrid application, its database, file storage, background processing, and the third parties listed on our Subprocessors page. Systems your firm connects at its own direction, such as your case management system, mailbox, calendar, or file storage, stay under your governance. Astrid reaches them only with credentials your firm grants. Astrid fixes the permission scopes it requests in code: your firm chooses whether to connect an account, not which scopes that connection uses.

Shared responsibilities

Astrid is responsible for the infrastructure that runs the service, isolation between firms, encryption in transit and at rest, the access controls below, vetting and disclosing the third parties that process your data, and notifying you if we confirm an incident affecting your firm.

Your firm is responsible for who holds attorney and staff seats and firm administrator rights; whether to require multi-factor authentication firm-wide, which is available but off by default; your transcript redaction policy and audio retention period; your consent posture for call recording; which accounts you connect, including any AI assistant a user connects through our MCP server; whether to mark a call privileged; and reviewing drafted notes before approving them.

One limitation worth stating because it affects your offboarding process: Astrid has no self-service way to remove a user from a firm. Seat changes are supported, removal is not. Ask us and we will do it.

Governance

Accountability for information security sits with the founder: policy ownership, access approval, vendor approval, and incident response. There is no segregation of duties between the person who writes the code, deploys it, and owns this policy, and no second reviewer. Astrid has no employees beyond the founder, so there is no personnel vetting or security awareness training programme to describe. Those controls begin when the first person is hired, not before.

This policy is reviewed at least annually and when a control it describes changes. The practice is new, and we would rather you heard this from us: an earlier version of this page described the absence of multi-factor authentication for eighteen days after it had shipped, which is what prompted the verification process behind this version. Revision history is tracked in our source repository, so every change carries an author and a date.

Where data is processed

Astrid runs on Google Cloud Platform in the us-east1 region: the application, the database, and call audio storage. Call audio is in a single-region bucket, so it is pinned to us-east1 rather than distributed across United States regions. We operate no infrastructure elsewhere and do not replicate, fail over, or back up to any region outside the United States.

Every subprocessor that handles firm content processes in the United States, and AI inference is pinned to United States infrastructure on every request. One subprocessor, one of our two marketing-site analytics providers, is a Canadian company; it runs only on the public website, never in the signed-in application, and never receives firm data. Per-provider detail is on the Subprocessors page.

Encryption

Data is encrypted in transit between your browser and Astrid and between Astrid and every provider it talks to, and at rest in our database and file storage using Google Cloud's encryption.

Several categories carry a further layer of application-level encryption above that, using an authenticated cipher (XChaCha20-Poly1305) keyed from a secret held in Google Secret Manager: access tokens for the systems your firm connects, authenticator secrets, and two-factor backup codes. Firm invitation tokens are stored only as hashes. Call recordings sit in a private bucket configured to refuse public access at the platform level, and transcription reads each recording through a short-lived signed link rather than a public URL.

Isolation and access

Astrid is multi-tenant. Every query for firm data is scoped to the requesting user's own firm and enforced on every API request rather than filtered in the interface. To be precise about the mechanism, because it matters to a reviewer: this is application-level query scoping, not database row-level security or per-tenant schemas. A user's firm is server-set and cannot be supplied by a client request. Seat role can be changed by a firm administrator at that same firm, which is the intended behaviour, and by nobody else.

Sign-in is by email and password. Multi-factor authentication is available on every account: a time-based code from an authenticator app plus single-use backup codes. Enrollment is confirmed before it takes effect, and ten consecutive failed codes lock the account for fifteen minutes. We do not offer a one-time code sent by email, because it would arrive in the same inbox that can reset the password, and we do not offer a "trust this device" option. We do not support enterprise single sign-on (SAML or SCIM directory sync).

A firm administrator can require multi-factor authentication for everyone at the firm, administrators included. One honest limitation: that requirement is enforced as a redirect when a member loads a page in the application. It is not a backend authorization boundary, so a session already open that never navigates again can continue calling the API. We would rather describe it accurately than call it a hard gate.

Within a firm, access follows attorney and staff seats, with firm administrator as a flag on either. A call, note, or transcript an attorney has marked privileged is restricted to attorney seats and firm administrators; others see that the record exists without its content. That marking is off by default, so unmarked records are visible to every seat at the firm.

Astrid's own staff hold a separate platform-administrator role used for provisioning firms. That role carries no firm identity and cannot query a firm's case data through the application. It does not eliminate vendor access absolutely: the founder administers the production database and could reach data directly there, as at any vendor of this size. What the design removes is routine access through the product.

AI processing

Astrid uses AssemblyAI to turn call audio into text, and Anthropic's Claude to draft notes, recap emails, and answers in the in-product assistant.

• Audio never reaches the drafting model. Anthropic receives text, never a recording. Recordings are stored by Astrid in Google Cloud Storage and read by AssemblyAI for transcription. A call captured by our phone bridge is also recorded by Twilio, and a meeting captured by our notetaker bot or by Astrid Desktop is recorded by Recall.ai. Astrid deletes those copies once it has stored the audio, and a Recall.ai copy that cannot be deleted then expires after seven days. Both are named on Subprocessors. A call captured from your firm's Dialpad account is also kept by Dialpad under your firm's Dialpad plan, which Astrid cannot change.
• Redaction is applied during transcription. If your firm enables redaction of categories of personal information, it happens before the transcript is written to our database and before any of it reaches the drafting model, so those values never enter our database. The audio still contains them, which is why audio retention is a separate control.
• Billable hours reads metadata, not message bodies. With the billable hours add-on, email subject lines, participants and times, and calendar and document titles, reach the drafting model so it can write time entries. Your firm's transcript redaction setting applies to call transcripts, not to these. Message bodies are not read or stored, and each timekeeper turns email capture on for themselves.
• Anthropic receives transcript text, your firm's note template, and the note and transcript content relevant to a question asked through the assistant. Not transcripts alone.
• Inference is pinned to United States infrastructure on every request. The provider default is to run in any available region; we set an explicit United States instruction in one place in our codebase, covered by a test that fails if it is removed. The API returns the region that served each request, so we can demonstrate the behaviour on demand.
• Your content is not used to train models. Contractually prohibited with our providers, not a matter of policy preference.

Connecting an AI assistant (MCP)

Astrid offers an MCP server (Model Context Protocol), so a user can connect Claude, an AI assistant from Anthropic. Other assistants, including ChatGPT, are not supported yet. The assistant can read the firm's matters and client names, the calls on them, and call transcripts, and answer questions from them. Each answer is cited to a timestamp that links back to that moment in the Astrid web app.

• Access follows the person who connects it. The assistant acts through that user's own Astrid account and can reach only what that user can already see in Astrid. Firm scoping and the privileged-record restriction described under Isolation and access apply to it exactly as they do in the product.
• It is read only. The server returns matter and call details, transcript text and citations. It cannot approve a note, file anything to a case management system, send a recap, or change a record, and it does not return recordings.
• What the assistant reads leaves Astrid for its provider. That includes client and matter names, call details and transcript text. That provider is chosen by the user and is not an Astrid subprocessor. It handles what it receives under its own terms, including its own retention, its own region and its own position on training. What this page says about United States inference and about not training on your content describes Astrid's providers and does not extend to it. Astrid cannot see what the assistant does with the text and cannot recall it once it has been sent.
• Redaction applies as stored. Transcripts are read as Astrid holds them, so any categories of personal information your firm chose to redact at transcription stay redacted.
• Connecting takes a sign-in and an approval. The user signs in to Astrid in their browser, with two-step verification if the firm requires it, and approves what the assistant can read. Astrid issues the assistant a short-lived access token and a refresh token, and stores each only as a hash.
• It is on by default, and a firm administrator controls it. A firm administrator can turn it off for the whole firm, which stops every connected assistant at its next request, can see which users have connected which assistant and when it was last used, and can disconnect any of them. Each user can also disconnect their own.
• Astrid keeps a record of use. Each request an assistant makes is logged with its time, the user, the assistant, the tool and the matter or call read. The log holds no question text and no transcript text, and entries are deleted after 13 months.

Which assistants may be used with client confidential information is your firm's decision. Because the server is on by default, we recommend that a firm administrator decide before anyone connects one, and turn it off in Settings if the firm does not want it.

Approval and the record

An attorney approves and locks a note, and that is enforced: the approval action requires an attorney seat. Approval records who approved it, the seat role held at that moment, and when, as a permanent snapshot that survives a later role change or account deletion. Reopening a locked note also requires an attorney and is logged. Action items attached to an approved note can be edited by any seat without a reopen, and those edits are not versioned.

Client recap emails are a deliberate exception, and we state it plainly because a reviewer would otherwise assume the opposite. Sending a recap does not require an attorney seat. Any member of the firm can send one, including on a call whose note has not been approved, and that send can file a memo to your case management system. This is a considered product decision: a paralegal who took the call can send its recap. Your firm controls it through who holds a seat.

Retention and deletion

We retain recordings, transcripts, notes, and matter data while the account is active, and briefly after it closes so the firm can export. A firm can set an audio retention period, after which recordings held by Astrid are purged automatically, with one exception: audio on a call marked privileged is excluded from the purge and kept indefinitely, so a litigation hold is not silently deleted. Transcripts and notes are kept regardless, because the note is the firm's record. Astrid deletes Twilio's copy of a phone bridge recording, and Recall.ai's copy of a meeting bot or Astrid Desktop recording, once Astrid has stored the audio.

Dialpad is different, because it is your firm's own phone provider rather than ours. When Astrid captures a call from Dialpad, Dialpad keeps its own recording and transcript under your firm's Dialpad plan, and Astrid cannot delete them. Your Dialpad administrator can set a data retention policy in Dialpad to remove them.

A firm may request deletion of specific content or its whole account at any time, subject to retention either of us must maintain by law or professional obligation. See our Privacy Policy.

Recordings made on a phone

An attorney can record a meeting from a phone's browser. While the recording runs, and afterwards until it has uploaded to Astrid, the audio is saved in that browser's storage on the phone, one second at a time, so a crash, a dropped connection, or a dead battery loses seconds rather than the meeting. That copy is stored under the signed-in user's account and is not shown to any other account on the same phone. It is deleted from the phone once the upload succeeds, and seven days after it was last touched whether or not it was ever uploaded. A user who signs out with a recording still on the phone is asked whether to upload it, keep it on the phone, or delete it, and an unsent recording is listed on the Calls page after the next sign-in so it is not forgotten.

Being precise about the limits: that copy is protected only by the phone's own storage protection. We add no further encryption to that copy, we cannot see what is on a person's device, and we cannot wipe or delete it remotely. A web page also cannot keep recording while a phone is locked or another app is in front of it. Astrid says so on the recording screen, and if a recording is interrupted it keeps what was captured and offers to resume, which leaves a gap in the audio for the time it was stopped.

A recording that was interrupted and resumed is uploaded in parts and joined into one file on our servers by a standard open-source media tool (ffmpeg) running inside our own application container. It has no network access, a time limit, and a size cap, and it is used only on recordings of that kind. We have not had it independently reviewed.

The Astrid app for iPhone

The Astrid app for iPhone, which is not yet generally available, records a meeting the attorney starts and uploads it to Astrid. Notes are reviewed and approved in the web application, as for any other recording.

To sign in, the app opens Astrid's own sign-in page, including two-step verification, in the phone's secure sign-in window, so the app never sees the password. It then holds a credential for that one phone, kept in the iPhone Keychain where only the Astrid app can read it. It is not synced to iCloud and not restored onto another phone. We store only a one-way hash of it. The credential can only upload recordings and list the user's own calls, and it stops working at once if the user signs out of the app, if the user or a firm administrator disconnects the phone in Settings, or if the user leaves the firm.

While a recording runs, and afterwards until it has uploaded, the audio is saved in the app's private storage on the phone, in a format that stays readable if the app is closed, crashes, or the battery runs out. Recording continues while the phone is locked. The files are protected by the iPhone's own file encryption, are excluded from iCloud and computer backups, and cannot be read by other apps. Only the signed-in user's recordings are shown in the app. A recording is deleted from the phone once Astrid confirms the call exists, and seven days after it was recorded whether or not it was ever uploaded. A recording interrupted by a crash is uploaded automatically the next time the app opens. Audio is uploaded over an encrypted connection directly to our private storage. The app contains no third-party analytics, advertising, or crash-reporting code.

Being precise about the limits: we add no encryption of our own to audio held in the app beyond the iPhone's, and we cannot see, wipe, or delete what is on a person's phone. Disconnecting a phone stops it signing in and uploading; it does not delete audio already on it. The phone's credential does not expire on a timer; it lasts until it is revoked in one of the ways above.

Logging and monitoring

Application errors are logged as structured records and captured in Google Cloud Error Reporting. Every field in a log record is an identifier or a code. The logging layer has no place to put a call's content, and the text of an error message, from our own code or from a vendor, is never written: only the error's class, a stable code and its stack frames. Password reset links are never logged in production.

Failures are also recorded in our own database, with the firm, call and step they belong to, so we can find what went wrong for a given customer without reading raw logs. Those records hold identifiers, codes and counts only, are visible only to Astrid platform administrators (not to any firm member, including an administrator of the affected firm), and are deleted after 90 days. When something fails you can see, a short reference is shown next to it, and quoting it to us takes us straight to the record.

What does not exist, stated plainly: no alerting on authentication failure patterns, no anomaly detection on outbound volume, no security information and event management system, and no on-call rotation. Alerting on operational failures is written but is still being rolled out and has not yet been verified in production. Raw application logs stay in Google Cloud Logging for the period Google sets by default, which we have not configured. Actions that are legally meaningful inside a firm are recorded, such as note approvals and seat changes, but there is no comprehensive audit log of all access.

Security incidents

On detecting a suspected incident we assess within one business day whether firm data is affected and whether the cause is still active, contain before diagnosing, and notify affected firms directly with what is and is not yet known. We do not delay notification until analysis is complete.

We do not publish a contractual notification deadline. If your firm needs one, we will agree it in your customer agreement. Suspected vulnerabilities can be reported to the address below and we will acknowledge within two business days. There is no bug bounty programme.

Resilience and continuity

The database uses Google Cloud SQL managed backups with point-in-time recovery. Call audio is in Google Cloud Storage without object versioning, so a deleted or overwritten recording is not recoverable from a backup. We have a written business continuity and disaster recovery plan, available on request, but have not yet rehearsed a full restore, so its recovery targets are unmeasured and we do not publish them.

Key-person risk is real and we will not understate it: one person holds all production access and all operational knowledge. What limits the blast radius is that Astrid runs on managed Google Cloud services rather than bespoke infrastructure, and all code and configuration is in version control. There is no documented succession plan and no code escrow. A firm for which this is material should raise it with us before signing.

Secure development

All source code is version controlled. Changes run through an automated pipeline on merge: type checking, linting, over 3,000 tests, a dependency vulnerability audit, and a production build, with deployment blocked if any step fails. Dependency advisories are also monitored continuously, outside that pipeline, because a pipeline audit only runs when something changes and an advisory can be published against a dependency set that has not. Confirmed vulnerabilities are fixed within 7 days for critical and high severity, 30 days for medium, and 90 days for low. Being precise about its limits: the repository has no branch protection rule, so the pipeline runs on merge rather than preventing one, and it applies database migrations rather than validating them. The founder can merge without review, which is the segregation-of-duties gap noted under Governance.

Inbound webhooks are signature-verified before being acted on. Most carry a timestamp and are checked against a replay window; our telephony provider's signature scheme carries no timestamp, so those endpoints are signature-verified without replay protection. Rate limiting applies to authentication and to actions with real-world effects such as sending a notetaker to a meeting, and a broader per-address ceiling sits beneath those, so an operation whose own limit was never configured still cannot be called without bound. The public forms on this site also use a decoy field and a minimum completion time to turn away routine automated submissions. Being precise about the limits of that: we run no web application firewall, no managed bot-detection service, and no CAPTCHA, so traffic reaches the application directly rather than through a filtering layer. There is no separate staging environment: changes are validated by tests and a production build rather than by exercise in a production-like environment.

Endpoint security for the single machine with production access is not formally managed. There is no device management, no enforced disk-encryption policy, and no endpoint detection tooling.

Assurance status

Astrid holds no SOC 2, no ISO 27001, and no other third-party security certification. We have not completed an independent penetration test and carry no cyber insurance.

What exists instead is an internal adversarial security review of the whole codebase, conducted in August 2026, grading twelve control areas. The four highest-priority findings were remediated the same day. Nine remain open, of which five are rated medium, the same severity band as two that were fixed. Calling the remainder low-severity would be inaccurate. We will disclose the count, severity, and status of every open finding to a firm under NDA. We do not publish the detail, because it describes unfixed weaknesses.

Our intended order of work is to remediate the open findings, commission an independent penetration test, rehearse a disaster recovery restore, then pursue SOC 2. We publish no target dates, because a date we cannot meet is worth less than an honest ordering.

Contact

Security questions, vulnerability reports, and the documentation a vendor review needs: jason@astrid.legal. Our processor obligations are in our Terms of Use rather than a separate data processing agreement. If your review needs more detail than this page carries, we are glad to go through it on a call.