Capability without ambient authority.

Assurance status

Windlord is in private beta. The statuses below distinguish implemented and tested controls from launch gates. “Implemented” is not a certification claim.

Architecture and data flow

1. Google is the source of truth. Gmail and Calendar retain authoritative records.
2. The device is the working system. Windlord downloads authorized records directly, stores them in an encrypted local database, computes the attention projection, and writes user/agent actions back to Google.
3. The hosted plane is content-free by contract. It handles opaque account/device trust, encrypted sync relay, content-free notifications, entitlements, deletion receipts, and optional closed-schema analytics.
4. Agents cross a controlled local boundary. They authenticate as a registered client, receive only grant-authorized reads, and submit typed requests rather than raw provider calls.

Google OAuth and token custody

• Google shows and owns the authorization screen; Windlord never receives the Google password.
• iOS uses the dedicated client bound to com.windlord.mobile and Apple Team 3UF3AM9C7M.
• App Attest/App Check binds production requests to authentic app instances. Enforcement follows observation, canary, and rollback evidence.
• Multi-account Google authorization archives each credential separately in device-only Keychain custody; the Google Sign-In singleton is signed out after each flow.
• Credential identity is checked against Google subject, account email, granted scopes, exact client ID, and Windlord connection ID.
• Access credentials are short-lived and scope-bound. External agents never receive Google OAuth tokens.
• Disconnect/revocation removes local custody and causes future refresh to fail closed.

Device storage and identity

• Mailbox, calendar, attention, operation, receipt, and analytics state is stored in SQLCipher with integrity checks and future-schema rejection.
• Wrapping keys and OAuth credentials are not stored in the database; supported platforms use protected credential storage.
• iOS credentials use data-protection Keychain access, device-only non-synchronizing storage, and after-first-unlock availability needed for background sync.
• Native device sessions use a private hardware-backed signing key where available. Server sessions are short-lived, method/URL/token-bound, and replay-rejected.
• Lost-device revocation closes derived sessions and push registration without requiring access to mailbox content.

Agent identity and finite authority

Windlord’s agent boundary separates identity, authority, data, and execution:

• one-time challenge-response authenticates the exact registered client and operating-system peer;
• the grant defines accounts, resource classes, actions, risk ceiling, approval mode, destinations, content ceiling, rate limits, and expiration;
• renewal cannot widen authority; a broader request requires a new user-approved grant;
• prompt or mailbox content never grants authority and cannot override the policy engine;
• revocation is checked through operation creation and execution so a race cannot consume stale authority;
• the MCP adapter has no direct database, token, provider, key, grant, or executor access.

Accountable execution

Windlord does not equate “the agent asked” with “Google changed.” The operation state machine derives risk and identity, binds the exact canonical request, verifies approval or standing grant, creates a stable provider plan, and preserves idempotency.

After dispatch, Windlord reports success only when the provider confirms the intended effect. A crash or ambiguous network response enters outcome unknown; recovery performs read-only reconciliation and does not blindly replay. Each request, authority decision, approval, attempt, reconciliation observation, and final outcome is added to a tamper-evident receipt chain.

Hosted control plane

The production design uses a dedicated Google Cloud project, private networking, least-privilege service accounts, Secret Manager containers, customer-managed database trust, regional high availability, cross-region recovery, Cloud Armor, managed TLS, disabled default service URLs, HSM-backed image attestation, Binary Authorization, digest-pinned releases, explicit migrations, canaries, bounded logs, and paging.

The service rejects mailbox bodies, headers, calendar content, OAuth tokens, prompts, agent commands, and plaintext local state. Encrypted sync relay records have per-device signed chains, quotas, stable pagination, exact retry, epoch rotation, and no semantic plaintext claim.

Analytics without conversations

The native product-evidence type system cannot represent message content, participants, subjects, prompts, model responses, account/provider IDs, URLs, attachment names, or arbitrary errors. Dimensions are closed enums and bounded buckets. Sharing is opt-in; consent changes purge, rotate pseudonyms, and create remote deletion duties. Analytics failures are isolated from product actions.

The public website uses a separate consent gate: no Google Analytics or Microsoft Clarity request occurs before a global opt-in. Google advertising features and Signals are disabled; Clarity cookies are off until consent, all text is strictly masked, and no identity API is used. The browser policy permits only the exact first-party loader and the two analytics endpoints. These website tools are not included in the native inbox or calendar apps.

Deletion and recovery

• Removing one Google connection cascades its local content and credential without affecting other accounts.
• Hosted account deletion is a fresh authenticated two-step device ceremony.
• Deletion revokes devices and agents, removes account-scoped hosted rows, and preserves only a minimum content-free replay tombstone.
• A dedicated online key signs the deletion receipt; an offline-root-signed public manifest governs key rotation so the service cannot bless its own replacement key.
• Late device, relay, invitation, or merchant replay cannot recreate a deleted account.

Provider and subprocessor posture

Vulnerability and incident response

Report security issues privately to team@supertrained.ai. Include a synthetic-data reproduction, affected component/version, impact, and safe contact method. Do not include live credentials or third-party data.

Windlord’s launch gates include a public vulnerability-disclosure policy, named incident owner, key/token revocation procedures, customer-notification path, forensic-log bounds, provider/OAuth containment, and tested backup/restore and region-failover runbooks. Completion status will be published here rather than implied.