Security you can verify, not just trust.
Promptster for Teams runs continuously against your engineers' real work, so the first question you should ask is what we can see. Our answer is architectural, not a promise: the Teams capture path has no place in its data model to store your source code. Below is exactly what we collect, how each control is enforced, and how your security team can check every claim for itself.
We never store your source
Source-exclusion is a property of the data model, not a policy toggle. Three independent layers — client-side redaction, a default-deny ingest allowlist, and database constraints — mean no column in the Teams database can hold your code.
90-day retention, enforced
Granular capture is kept for at most 90 days, capped by a database constraint rather than a settings screen. Deletion on request, any time — scoped to your org and logged.
Anti-surveillance by design
Managers see team-level aggregates; engineers see only themselves. There is no per-person leaderboard, and the split is enforced in code at the API layer — not promised in a policy.
Tamper-evident audit log
Every access, export, and deletion of Teams data lands in an append-only log that even our own code cannot alter or wipe — enforced by database triggers against update, delete, and truncate.
Encrypted end to end
TLS on every external connection, terminated at our edge; platform-managed encryption at rest through our infrastructure providers. There are no plaintext external endpoints.
Honest about certification
We are not SOC 2 or ISO 27001 certified, and no audit is in progress. We build to that bar and evidence every control directly in source you can read under NDA — we won't imply an attestation we don't hold.
We never store your source code
This is the claim that matters most for an always-on analytics tool, so we don't ask you to take it on faith. We capture how your engineers work with AI — their prompts, decisions, and interaction metadata — and never the code itself. It isn't a promise layered over a system that could store source; it's enforced by three independent layers, each a complete defense on its own.
Redacted on the machine, before anything is sent
Source embedded in conversational text is stripped locally by our capture client, on the engineer's own machine, before it is transmitted. For the free text we keep, source never leaves the developer's laptop in the first place — and the client is independently reviewable, so you can confirm exactly what it collects rather than take our word for it.
Default-deny at the ingest boundary
Every captured event passes through a per-kind field allowlist at the write boundary. Anything definitionally source or machine output — diffs and patch hunks, file contents, command stdout/stderr, tool arguments and results — is on the allowlist for no event kind, so it can never be written. A new field defaults to excluded until someone explicitly and safely adds it. The safe default is exclusion.
The database itself refuses source
The Teams database is physically narrowed away from source: the columns that once held raw payloads are dropped, and constraints reject any row that still carries a diff, file content, or command output. This layer holds even if application code somewhere had a bug — the store has nowhere to put your code.
Each layer would hold if the other two failed. The result is a structural guarantee rather than a policy commitment: the data model simply has no place to put your source. Because both our capture client and our schema are available for review under NDA, this is something you can confirm rather than believe.
What we collect, and how long we keep it
For each participating engineer, Teams captures prompt-context and interaction telemetry from their AI coding tools: conversational text (client-redacted), engineer-authored rationale, and interaction metadata — file paths with line and byte counts, command invocations and exit codes, test/build/lint outcomes, tool and MCP call identity and status, and session lifecycle. It does not collect file diffs, file contents, or command output.
Granular per-session capture is retained for at most 90 days, capped by a database constraint and clamped again in code — no organization can be configured to retain it longer. A scheduled job prunes capture past each org's window; only the source-free aggregate trend lines are kept beyond it, so managers keep their history without any prompt-level data being retained. Customer- or engineer-initiated deletion runs through the same machinery, scoped to a single org, and every purge is written to the audit log.
Access control & authentication
The guardrail that matters most for an always-on tool is that it can't become a per-person surveillance panel — and that guardrail is enforced in code, not in a policy. Managers (organization admins) see team-level and cohort aggregates only; there is no per-engineer ranking. Engineers see only their own sessions and their own metrics. The product deliberately does not hand a manager a leaderboard of their reports.
Authentication runs through Clerk, which provides enterprise SSO (SAML / OIDC) and MFA, configurable per organization. Every route sits behind the narrowest credential that fits the caller, and access defaults to fail-closed. Administrative access to Teams data at Promptster is limited to a small number of authorized personnel through our providers' authenticated, MFA-protected consoles — and it is inherently bounded, because there is no customer source code to access: the database cannot hold it.
Tamper-evident audit logging
Teams maintains an append-only audit trail of who accessed, exported, or deleted Teams data. A manager reading the team dashboard, an engineer reading their own rollups, a key being minted or revoked, and each scheduled retention purge all land a row. Tamper-evidence is enforced at the database, not trusted in the application: triggers reject any attempt to update, delete, or truncate the log — so even our own code cannot alter or wipe the trail. A missing entry is itself the red flag.
Encryption
All external traffic is TLS-encrypted, terminated at our edge in front of our API, worker, and dashboard; there are no plaintext external endpoints. Data at rest is encrypted through our infrastructure providers' platform-managed encryption on managed PostgreSQL — we rely on and inherit that control rather than overstate internals of a system we do not operate, and we can share the provider documentation on request. Runtime secrets are injected by our hosting platforms, validated at boot, and never committed to source; programmatic organization API keys are stored hashed.
Sub-processors
These services may process Promptster for Teams data, as scoped by the source-excluded capture path above.
| Sub-processor | Purpose | Teams data processed |
|---|---|---|
| Clerk | Authentication & role-based access | Organization identity and roles used for auth and RBAC. No capture content. |
| Supabase | Teams capture database | The source-excluded capture record: prompt-context metadata, file paths, command metadata, and engineer-authored prose. No source code, diffs, file contents, or command output. |
| QStash / Upstash | Background job queue | Job-routing envelopes only — the signals that trigger worker processing. Not a store of capture content. |
| Anthropic | LLM analysis over Teams aggregates | Source-excluded aggregates and prose only. Never raw payloads or source code — there is none in the Teams store to send. We do not train models on customer data. |
| PostHog | Server-side telemetry & error tracking | Operational and error telemetry from our API and worker. Not capture content. Optional, and a no-op when unconfigured. |
Infrastructure providers (Vercel, Railway, Cloudflare, PagerDuty, HetrixTools, and Google Cloud KMS) host or operate our systems and process data incidental to running the service — network traffic, host metrics, encrypted material, and alerting signals — but do not receive Teams capture content as application data.
Our separate hiring product uses additional sub-processors that never touch Teams data; they're listed on our sub-processors page. We provide advance notice before a new sub-processor begins processing Teams data or a material change to an existing one.
Our certification posture, stated plainly
Promptster is not SOC 2 or ISO 27001 certified, and no audit is in progress. We will not imply, hint at, or manufacture an attestation we do not hold. Formal certification is deferred until enterprise demand justifies the audit cost; if it's a gate for your procurement, tell us early and we'll scope a timeline honestly as a contract term.
What we offer instead is a set of controls built to the SOC 2 / ISO 27001 bar and evidenced directly in the source and schema you can read — which, for a team willing to inspect it, is a stronger primitive than a certificate you can't. We're happy to walk your security team through any control live, or grant read access under NDA.
Verify it, don't just trust it
We designed Promptster for Teams so your security team can check our claims rather than accept them. Request the full security whitepaper, our sub-processor list, and answers to your security questionnaire — or ask for read access to the schema and code that back each control, under NDA.
Or email us directly at security@promptster.ai.