Security

Connect your bank, inbox, and till. The credentials stay in the vault.

The question that decides if Stillpost is wired up at all: before an autonomous agent touches a checking account, a shared inbox, and a POS feed, the owner wants to know how the data is handled, what is encrypted, where the credentials sit, and what Stillpost does, or does not do, with what it pulls. The trust signals below answer the first round of objections, and the buyer-questions below walk the second round — read-only OAuth, credential vault isolation, no staff access, one-click revoke, encryption in transit and at rest, and the four-category partner list tied to each of those controls. For the partner list itself, see the integrations cluster; for the tier the credentials sit behind, see the pricing grid.

Bank connection

Read-only OAuth. Tokens in the vault. The bank never sees an outbound mutation from Stillpost.
The bank walk-through — the one the buyer weighs first because the credential behind it is the most sensitive: read-only OAuth, isolation in the credential vault, no money-movement scope, and a vendor relationship that does not require Stillpost to invent a custom credential-scraping layer. For the partner list itself, see the sub-processor card below; for the broader connectivity model, see the integrations cluster.

Read-only OAuth is the only scope the platform asks for. The long tail of U.S. institutions connects through Plaid, and Mercury, Stripe Banking, Square, and Brex connect natively on top. The OAuth scope the token carries reads transactions, balances, and account metadata only — payments, refunds, transfers, and ACH issuance are not in the scope, and the platform never requests them because the bookkeeping loop does not need them. The source-of-truth system stays exactly the way it was the day before the operator wired Stillpost into it.

The token lands in the credential vault behind the same isolation boundary the rest of the platform’s secrets live behind. Every hop on the credential flow runs over TLS 1.2 or higher — the bank’s OAuth redirect, the loop’s read into the platform, and the operator’s dashboard session — and no token sits in plaintext on a row, in a log line, or in operator-facing telemetry. AES-256 in the vault, TLS on the wire, HSTS on the deployed origin so a browser-side downgrade attempt fails at the browser layer. The rotation cadence, the rotation-on-revoke flow, and the per-credential key boundary are written into the security questionnaire.

The vendor relationship is a real one, not a custom layer — Plaid plus the four native partners, each with a public security posture the operator can read ahead of procurement. The full four-category list — OAuth brokers, inbox, infrastructure, native financial partners — is on the sub-processors card below; the per-partner detail (the loop a partner unlocks, the tagline, the vendor URL) is on the integrations cluster.

Human and AI access: no staff reads the books without the operator’s session. Support-side action against the operator’s tenant is brokered, scoped to a ticket, recorded in the operator’s audit trail, and never a free-form staff read. The AI layer — the receipt OCR and the invoice line-item extraction — runs against the receipts and invoices the loop has already ingested, not against the bank feed itself. For the second half of that data path, see the AI proxy seam below.

  • Read-only OAuthScope reads transactions, balances, and account metadata only — no payments, no refunds, no transfers, no ACH. The bank never sees an outbound mutation from Stillpost.
  • TLS in transit, AES-256 at restTLS 1.2+ on the bank’s OAuth redirect and the loop’s read; AES-256 in the credential vault. No plaintext token on a row, in a log, or in telemetry.
  • No money-movement scopeThe bookkeeping loop’s outbound side runs against the dashboard and the operator’s inbox — overdue chasers, period closes — never against the originating bank account.
  • Vendor: Plaid + native partnersPlaid plus Mercury, Stripe Banking, Square, and Brex native connectors — public security postures the operator can read before procurement signs off.
  • No staff readsNo staff reads the books without the operator’s session; support actions are brokered, scoped to a ticket, and recorded in the audit trail.
  • AI access scoped to receiptsThe AI layer runs OCR and line-item extraction against receipts and invoices — never against the bank feed. The proxy seam is listed below.

Email connection

Scope-limited Gmail / Microsoft 365 OAuth. Receipts and replies only. No contact-list pull, no send-on-own.
The inbox walk-through — the connection the buyer weighs second because the credential carries both the receipts the loop reconciles against and the reply threads the overdue-chaser beat threads onto. Scope-limited OAuth on Gmail / Microsoft 365, vault-isolated token, AI access scoped to OCR and line-item extraction through the Polsia AI proxy, never a contact-list pull, never a send-on-own. For the AI proxy posture, see the infrastructure row of the sub-processors card.

Scope-limited OAuth on Gmail and Microsoft 365. The token Stillpost holds carries the narrow scope the bookkeeping loop needs: invoice PDFs and receipts that reconcile against the bank feed, plus the reply-thread context the overdue-chaser beat threads onto. The token does not request send-on-own, does not request inbox-filter modification, does not request unrelated-folder reads, and does not request contact-list pulls. The chaser beat’s outbound mail leaves the loop on the operator’s behalf — but it leaves from the operator’s own domain, not from a Stillpost-controlled inbox.

TLS on every hop on the credential flow — the inbox provider’s OAuth redirect, the loop’s read into the platform, and the operator’s dashboard session — and the token sits behind AES-256 in the vault, isolated per connector, scoped to the loop that uses it. No plaintext token in an application log, no plaintext token in the operator-facing telemetry, and no plaintext token in any environment file the operator can reach. The rotation cadence and the rotation-on-revoke flow are written into the security questionnaire.

AI access is scoped. The receipt OCR and the invoice line-item extraction route through the Polsia AI proxy — the platform never imports a model provider SDK, never holds a model provider key in-repo, and never makes an outbound model call directly. The proxy seam carries the audit-trail entry the operator sees against the connection, and the model never sees anything outside the receipt or invoice the loop already ingested. The proxy is listed on the infrastructure row of the sub-processors card below; the broader connectivity model is on the integrations cluster.

Human access: no staff reads the receipts or the invoices without the operator’s session. Support-side action against the operator’s tenant is brokered, scoped to a ticket, and recorded in the audit trail — never a free-form staff read. A revoke from the dashboard removes the token from the active set on the next scheduled pull, the loop stops reading from the inbox at that point, and the audit-trail entry carries the credential type, the source, and the timestamp.

  • Scope-limited OAuthReceipts, invoices, and reply-thread context only — no send-on-own, no inbox-filter mods, no unrelated-folder reads, no contact-list pulls.
  • TLS in transit, AES-256 at restTLS 1.2+ on the inbox provider’s OAuth redirect and the loop’s read; AES-256 in the credential vault, isolated per connector.
  • AI: OCR + line-item extraction via the AI proxyReceipt OCR and invoice line-item extraction route through the Polsia AI proxy — no provider SDK in-repo, no provider key held in-repo, scoped to the receipt or invoice the loop already ingested.
  • Chaser beat leaves the operator’s domainThe overdue chaser leaves from the operator’s own domain — not from a Stillpost-controlled inbox. The reply threading stays in the operator’s audit trail.
  • No staff readsNo staff reads receipts or invoices without the operator’s session; support actions are brokered, scoped to a ticket, and recorded.
  • One-click revokeA dashboard disconnect removes the token from the active set on the next scheduled pull; the audit-trail entry carries the credential type, the source, and the timestamp.

POS connection

Square OAuth plus Square and Stripe native. Per-day settlement batch. Ledger read only — no menu, no inventory, no payout.
The point-of-sale walk-through — the connector the buyer weighs third because the credential sits behind the till, not behind the checkbook. Square OAuth plus Square and Stripe native, per-day settlement batch into the ledger, vault-isolated token, ledger-only read — no menu mutation, no inventory mutation, no payout mutation. For the partner relationships, see the native-partners row of the sub-processors card.

Per-day settlement batch is the operational shape the loop reads. The POS ledger posts a settlement report at the end of each business day — gross sales, refunds, fees, net deposit — and the loop reads that batch report into the per-account ledger the platform maintains. The bucket the loop pulls does not include menu state, inventory state, drawer counts, loyalty state, or payout state; the loop reads the financial settle only, and the source-of-truth POS stays exactly the way the operator left it.

Square OAuth is the primary path, with Square and Stripe native on top. The platform’s Square native connector reads the settlement batch through Square’s reporting API under the same read-only scope the rest of the platform’s token scope uses. The Stripe native connector reads the equivalent Stripe settlement object for Stripe-issued POS accounts. No connector in the loop holds a write-back scope; the token Stillpost holds cannot (and does not request to) push a menu change, post an inventory adjustment, or fire a payout. The partner list is on the native-partners rows of the sub-processors card below; the per-partner detail is on the integrations cluster.

TLS on every hop on the credential flow — the POS provider’s OAuth redirect, the loop’s per-day batch pull, and the operator’s dashboard session — and the token sits behind AES-256 in the credential vault, isolated per connector, scoped to the settlement batch the loop reads. No plaintext token in a log line, no plaintext token in operator-facing telemetry, and no plaintext token in any environment file the operator can read. The rotation cadence, the rotation-on-revoke flow, and the per-credential key boundary are written into the security questionnaire.

Human and AI access: no staff reads the settlement batch or the per-account ledger without the operator’s session. Support-side action against the operator’s tenant is brokered, scoped to a ticket, and recorded in the audit trail. The AI layer — the receipt OCR and the line-item extraction — runs against the documents the loop has already ingested, not against the POS feed itself. A revoke from the dashboard stops the next scheduled pull against the POS source; the audit-trail entry carries the credential type, the source, and the timestamp.

  • Per-day settlement batchGross sales, refunds, fees, net deposit — the LOOP reads the per-day settlement report, not menu state, not inventory state, not payout state.
  • Square OAuth + Square / Stripe nativeSquare OAuth is the primary path; Square and Stripe native read the equivalent ledger entry on Stripe-issued POS accounts. No write-back scope on any connector.
  • No menu / inventory / payout mutationThe token Stillpost holds cannot push a menu change, post an inventory adjustment, or fire a payout. The source-of-truth POS stays exactly as the operator left it.
  • TLS in transit, AES-256 at restTLS 1.2+ on the POS provider’s OAuth redirect and the per-day batch pull; AES-256 in the credential vault, isolated per connector.
  • No staff readsNo staff reads the settlement batch or the per-account ledger without the operator’s session; support actions are brokered, scoped, and recorded.
  • One-click revokeA dashboard disconnect removes the token from the active set on the next scheduled pull; the audit-trail entry carries the credential type, the source, and the timestamp.
Trust signals
The headline answers a buyer weighs first — the read-only scope, the vault, the one-click revoke, the encryption posture. The long-form answers to the buyer-objection questions live below.
  • Read-only OAuthStillpost pulls the feed; it never writes back. The bank, the inbox, and the POS see no outbound mutation from the loop.
  • Credential vault isolationTokens sit behind the same isolation boundary the rest of the app’s tokens live in. Nothing in plaintext at rest, nothing in logs.
  • No staff accessNo analyst eyes your books without your session. The loop is the loop; no one reads the books for you on the side.
  • One-click revokeDisconnect from the dashboard and the next scheduled pull stops using the credential. Nothing runs against a stale token.
  • No vendor nestPlaid plus native connectors (Mercury, Stripe, Square, Brex) instead of a custom credential-scraping layer that the operator would have to audit on every release.
  • Encryption in transit and at restTLS on every hop, AES-256 at rest, never http:// on a credential flow — the wire stays TLS, the vault stays encrypted.

Encryption

Wire stays TLS, vault stays AES-256, no plaintext in the credential flow.
The two halves of encryption the buyer wants to see written down: in transit (the wire between the bank, the inbox, the POS, the platform, and the operator’s dashboard) and at rest (the vault the token sits in, plus the database the operator’s books live in). Both halves are operating controls the team maintains, and both halves are written into the security questionnaire.

In transit: every hop on the credential flow runs over TLS 1.2 or higher — the bank’s OAuth redirect, the inbox provider’s API, the POS provider’s per-day batch pull, the loop’s read into the platform, and the operator’s dashboard session. There is no http:// leg in the flow that holds a token, and there is no credential fetch the platform makes against a non-TLS endpoint. The HSTS header is set on the deployed origin so a downgrade attempt against the operator’s browser session fails at the browser layer.

At rest: tokens, secrets, and the operator’s books sit behind AES-256 in the credential vault and the application database — neither in plaintext on a row, nor in plaintext on a log line, nor in plaintext on the operator-facing telemetry. Vendor keys for outbound connectors (Plaid, the inbox OAuth brokers, the POS per-day feeds) live in the same vault, isolated per connector, scoped to the loop that uses them. The key boundary the platform speaks for in the questionnaire matches the boundary the platform actually enforces — no separate “production key vs. customer key” path.

Rotation: keys rotate on a fixed cadence and on a per-credential trigger — a revoke from the dashboard issues a fresh OAuth grant against the same vault boundary the next scheduled pull picks up, and an incident on a vendor partner rotates the platform-side material without touching the operator’s session. No token sits longer than the rotation window the team writes down in the questionnaire (same window the team reports against in the SOC 2 evidence bundle).

  • In transitTLS 1.2+ on every credential-leg hop — bank OAuth, inbox API, POS batch pull, dashboard session. No http:// leg in the flow.
  • At restAES-256 in the credential vault and the application database — tokens, secrets, and the operator’s books, no plaintext rows, no plaintext logs.
  • Key rotationKeys rotate on a fixed cadence and on a revoke — a one-click disconnect issues a new grant against the same vault boundary.
  • No plaintext in the credential flowNo token in a log line, no secret in an environment file the operator can read, no cleartext export of a connection’s material.

Access controls

No shared admin path. Per-tenant isolation. No staff reads.
The platform reads the operator’s row against the operator’s authenticated session — no analyst backdoor, no cross-tenant query surface, no admin password that bypasses the application’s authorization layer. The audit trail is the operator’s, and it stays on the operator’s tenant.

Per-tenant isolation: customer books, customer connections, and customer tokens live in a row-scoped data plane keyed by the operator’s authenticated session. The model layer reads every row against the session’s tenant, never against a global admin path. A revoke from the dashboard removes the credential, the loop stops reading from that source on the next scheduled pull, and the disconnect lands in the operator’s audit trail with the credential type, the source, and the timestamp.

Roles and audit: the role model separates the operator’s session from any support-side session — support action against the operator’s tenant is brokered, scoped, and recorded, not free-form. Audit-trail entries are write-once, tenant-owned, and surface in the operator’s dashboard under the connection the audit entry corresponds to. The controls matrix in the questionnaire lists the role split, the brokered-support path, and the audit-trail window the platform speaks for.

  • No shared admin pathNo analyst password, no cross-tenant query, no global backdoor — the operator’s row reads against the operator’s session, full stop.
  • Per-tenant isolationBooks, connections, and tokens live row-scoped by tenant; a revoke stops the scheduled pull and timestamps the disconnect.
  • Role-based access + brokered supportSupport-side action against an operator’s tenant is brokered, scoped to a ticket, and recorded — never a free-form staff read.
  • Session-scoped readsThe application’s authorization layer reads every row against the authenticated session’s tenant — no global query path the platform speaks for.
  • Audit trail, operator-ownedAudit entries are write-once and tenant-owned; the operator sees them in the dashboard under the connection they correspond to.

Sub-processors

The four-category partner list procurement asks for.
The platforms and vendors Stillpost runs the loop through — every partner that reads customer data or holds a credential on the operator’s behalf is on this list, grouped by category. For the per-partner detail (the loop a category unlocks, the per-partner tagline, the vendor URL), see the integrations cluster.

Identity / OAuth brokers

Plaid
Bank OAuth broker for the long tail of U.S. institutions. Visit partner →
Mercury Connect
Direct bank connector — read-only into the operator’s Mercury operating account. Visit partner →
Stripe (native)
Stripe-issued accounts and Stripe Treasury, read-only via the platform’s Stripe-native path. Visit partner →
Square OAuth
POS OAuth broker — reads Square’s per-day settlement report into the loop. Visit partner →
Brex Connect
Direct Brex connector — Brex cards and Brex banking read into the same per-account ledger. Visit partner →

Inbox OAuth

Gmail
Inbox OAuth — receipts and inbound invoices OCR’d into the costing ledger. Visit partner →
Microsoft 365
Outlook OAuth — same receipt and invoice pickup pattern as Gmail. Visit partner →

Infrastructure

Vercel
Application hosting — the deployed Next.js platform runs on Vercel’s edge. Visit partner →
Cloudflare R2
Object storage — receipts PDFs and uploaded documents behind a signed-URL boundary. Visit partner →
Polsia email proxy
Outbound transactional mail — the overdue chaser and the weekly digest route through this proxy.
Polsia AI proxy
Receipt OCR and invoice line-item extraction — model calls route through the proxy, no provider key in-repo.

Native financial partners

Mercury
Operating-account bank — wired natively. See /integrations →
Stripe Banking
Stripe Treasury and Stripe-issued accounts — wired natively. See /integrations →
Square
POS provider — per-day settlement report, wired natively. See /integrations →
Brex
Brex cards and Brex banking — wired natively. See /integrations →

Incident response

Detection → notification → post-mortem → status page.
Honest framing: the incident-response stance Stillpost runs under is the same one a procurement team reads in the questionnaire — a detection layer, a fixed notification window for affected operators, a written post-mortem, and a public status surface. The four parts below are the platform’s commitments; the questionnaire lists the playbook the team maintains.
Detection
Anomaly detection runs on the scheduled-pull layer — a vendor partner outage surfaces within minutes of the loop’s first failed pull, the credential vault surfaces auth failures at the same layer, and the platform’s own infrastructure alerts land on the same page. A failed pull does not silently retry; the loop logs the failure, holds the previous reading on the affected source, and surfaces the gap in the next operator-facing digest.
Customer notification
Affected operators hear from the team within one business day of detection — direct email to the operator’s account address, plus an in-dashboard banner on next sign-in. The note carries the affected source (bank, inbox, POS), the beat that paused, the affected time window, and the ETA. No notification goes out under the team’s brand without a written reviewer in the loop.
Post-mortem
A written post-mortem for any platform-side incident (a vendor partner outage, a vault-side issue, a deployed application regression) — what the team detected, what the timeline was, what the loop did and did not do, what the fix is, and what changes so the next incident trips earlier. Post-mortems route to the operator whose tenant was affected and ship under a non-blame framing.
Status surface
A public status page surfaces the platform’s view of both the vendor partners (Plaid, inbox brokers, POS providers) and the platform itself — incident start, mitigation, resolution. The dashboard banner reads from the same source so the operator sees the same status the team commits to publicly.

For the buyer past the page — the questionnaire bundle, the post-mortem history, and the on-call coverage map — drop a note on the contact page and the team routes the request within the one-business-day window.

Stillpost connects to a bank via read-only OAuth — the long tail of institutions runs through Plaid, and Mercury, Stripe, Square, and Brex connect natively. The token lands in the credential vault, behind the same isolation boundary the rest of the app’s tokens live behind, and the loop pulls a transaction feed without a write-back path. The source-of-truth system stays exactly the way it was before Stillpost touched it. The full four-category partner list — banks, point-of-sale, accounting, email — is on the integrations cluster.

The second question — can I run the loop without giving up control — has the same answer: a one-click revoke in the dashboard removes the credential from the scheduled pull, and nothing in the loop runs against a stale token on the next pass. The buyers’ followup questions, plus the SOC 2 posture and the questionnaire route, are below.

Read the controls, then get on the list.
One note to the team with the questionnaire attached answers the procurement-side questions — and the waitlist below is the path for the operator who is past the page and ready to wire it up.
Send the security questionnaire →

10 buyer-side questions answered · copy last refreshed alongside the Stillpost roadmap

Want the broader buyer-questions view — like how the loop actually runs and what each tier includes? See the FAQ → Want to see the partner list (banks, inbox, point-of-sale) the loop wires up? See Integrations →