Security & Trust

Ashley is designed for data minimization, transparency, and control. This page explains exactly what Ashley can access, what Ashley stores (and never stores), and how we protect your data.

Our principles

No email access
No email storage
No calendar body storage
Explainable actions
Executive-in-the-loop controls

Data minimization

  • Ashley does not request permissions for reading email.
  • Ashley does not store email bodies.
  • Ashley does not store calendar event bodies/details.

Transparency & control

  • Ashley shows you what it intends to do before it acts (Human-in-the-Loop).
  • You can edit proposed meeting details, constraints, and outcomes before confirmation.
  • You can override decisions and teach Ashley your preferences over time.

Secure-by-default operations

  • Production runs on Microsoft Azure App Service.
  • Primary datastore is Cosmos DB for MongoDB.
  • Backups run nightly with a two-week retention window; restores are tested monthly.
Plain-English summary: Ashley uses calendar access to help with scheduling, but it aims to avoid copying or retaining the content of your calendar or email. What Ashley retains is primarily operational metadata (requests/responses) and authentication tokens needed to connect to your calendar.

What Ashley stores vs. never stores

Category Stored? Notes
Email bodies / mailbox content No Ashley does not request email read permissions and does not ingest mailbox content.
Calendar event bodies/details No Ashley may read event metadata for scheduling decisions, but does not persist event bodies/details in the database.
Contact lists Not by default Contacts access is used only for contact-related features (e.g., when you ask Ashley to help find/suggest a person). Ashley does not “download your address book” as a background process.
OAuth access tokens & refresh tokens Yes Stored to enable ongoing calendar connectivity. Currently stored as provided; protected by cloud controls and encryption at rest. Application-layer encryption is planned.
Request/response records (HITL) Yes Stored to support the Human-in-the-Loop experience and debugging. Current retention is indefinite; retention controls are on the roadmap.
Operational logs (service logs) Yes Standard service logs (warnings/errors). Sensitive fields (like tokens) are not logged.

Questions? If you’re a customer doing vendor security review, email us and we can walk through a current architecture/data-flow diagram under NDA.

Permissions Ashley requests (OAuth scopes)

We believe trust starts with clarity. Here are the exact permissions Ashley requests for Google and Microsoft integrations. (Notice: no email read scopes.)

Google OAuth scopes
Google - https://www.googleapis.com/auth/userinfo.email - https://www.googleapis.com/auth/userinfo.profile - openid - https://www.googleapis.com/auth/calendar.events - https://www.googleapis.com/auth/calendar.calendarlist.readonly - https://www.googleapis.com/auth/contacts.readonly - https://www.googleapis.com/auth/contacts.other.readonly
Microsoft OAuth scopes
Microsoft - openid - profile - email - offline_access - User.Read - ProfilePhoto.Read.All - https://graph.microsoft.com/Calendars.ReadWrite - https://graph.microsoft.com/Calendars.Read - https://graph.microsoft.com/Contacts.Read - Calendars.Read - Calendars.ReadWrite - Contacts.Read
Important: Ashley does not request Gmail “read mail” scopes or Microsoft Graph “Mail.Read” scopes. If you ever see those requested, treat it as a bug and contact us immediately.

Explainable & controllable AI

Ashley is built around the idea of Executive-in-the-Loop: the system can propose actions, but you stay in control. This approach reduces hallucination risk, prevents “excessive agency,” and makes behavior auditable.

Explainable decisions

  • Ashley explains the “why” behind recommendations (constraints, preferences, conflicts, and tradeoffs).
  • Ashley surfaces what data sources were used (e.g., calendar availability) to arrive at a proposal.

Controllable actions

  • You can edit proposed meeting time/participants/location before anything is booked.
  • You can deny actions or adjust constraints (working hours, buffer time, travel, priority rules).

AI attack considerations

  • Prompt injection defense: Ashley treats untrusted input (like attendee text) as untrusted and routes risky actions to HITL review.
  • Least agency by default: no silent “do-anything” automation for sensitive actions.
  • Auditable logs: actions are traceable to requests and approvals.

We can provide an “AI Security & Governance” addendum on request (threat model, mitigations, and incident handling for AI-related events).

Security controls (high-level)

Identity & access

  • Production access is restricted (single-founder operation).
  • GitHub requires MFA.
  • Separate environments (prod / dev / PPE) are isolated in distinct Azure subscriptions/tenants.

Backups & recovery

  • Nightly backups with a two-week retention window.
  • Restore tests performed monthly with outcomes recorded.

Monitoring & logging

  • Application logs capture operational warnings/errors.
  • Tokens and other sensitive secrets are not logged.
  • Centralized security alerting (e.g., Azure Monitor/Log Analytics) is being formalized.

SOC 2 readiness snapshot

Ashley is actively pursuing SOC 2. Some controls are already in place through engineering workflows and cloud practices; others are in progress.

Change management (CC8): strong
Access controls (CC6): partial
Monitoring (CC4/CC7): in progress
Formal policies & IR/BCDR: in progress
Trust Services Criteria Status Notes
CC1 – Control environment In progress Core policy set being formalized for a single-founder company (lean but auditable).
CC2 – Communication & information In progress Customer-facing transparency pages (like this) + internal procedures are being finalized.
CC3 – Risk assessment In progress Formal annual risk assessment + vendor review process being documented.
CC4 – Monitoring In progress Centralized monitoring/alerting is being configured; operational logs exist today.
CC5 – Control activities In progress Controls exist (PR reviews/testing), mapping controls-to-risks is being formalized.
CC6 – Logical/physical access Partial MFA and environment isolation are in place; access review + token encryption improvements are planned.
CC7 – System operations Partial Backups/restores exist; formal incident response + monitoring playbooks are being finalized.
CC8 – Change management Strong Structured SDLC + PR reviews + CI/CD are established and auditable.

If your organization requires a formal SOC 2 report before adoption, we can share our roadmap and current evidence package under NDA.

Subprocessors

Ashley relies on best-in-class infrastructure and APIs to deliver core functionality. The set below is intentionally small.

Microsoft Azure

Hosting (App Service) and primary datastore (Cosmos DB for MongoDB). Physical security and datacenter controls are provided by Azure.

Google APIs

Calendar + identity (and optional contacts read-only for contact-related features).

Microsoft Graph

Calendar + identity (and optional contacts read-only for contact-related features).

OpenAI API

LLM inference for natural-language planning/interpretation. (Direct OpenAI API, not Azure OpenAI.)

Security contact

For security questions, vendor assessments, or to report a vulnerability, contact: security@wellnessatwork.me (or reply to your existing thread with us).

We’re happy to provide: architecture overview, data-flow diagram, scope list, and current SOC 2 evidence package under NDA.