security & data access
What we touch.
What we keep.
Telemetry is read-only. Raw events stay in your store; Perfloop keeps only derived aggregates and snapshots. On code, the only writes are case branches and the pull requests they carry. The merge is always yours.
every data-access claim here is verifiable against the access you granted and your own audit logs
The data contract.
The contract is the same for every customer. One connection is live today — the code host. The telemetry connectors are in development, so the telemetry rows below are the contract for when each ships, not a connection you can make yet. Which datasets and fields it binds to is something you configure with your telemetry source's own primitives, before any discovery runs.
| category | what crosses the boundary | what perfloop keeps | retention |
|---|---|---|---|
| metricsread-only | aggregated series with their labels: metric names, label keys and values, percentiles, rates, counts | snapshot-level summaries | life of workspace |
| tracesread-only | span structure: names, durations, status, service labels. other attributes only as keys you approve per case; default none | derived topology + timing summaries | life of workspace |
| logsread-only | aggregate query results only: counts, distributions, percentiles, and approved grouping values from views you author or datasets you sanitize. raw-row and cross-source queries are rejected before egress | aggregates | life of workspace |
| profilesread-only | stack frames and sample counts; code structure, no payloads | derived flame summaries | life of workspace |
| source coderead + pr write | code in repos you connect; the writes are case branches and the pull requests you review, never a merge | repo structure (symbols, references, packages, files, entry points) | life of connection |
never collected
- log events & message bodiesViews you author or datasets you sanitize exclude message bodies. You configure the provider credential as query-only and scoped to those resources; Perfloop validates access to each one but cannot inspect the token's complete grant. The connector also rejects raw-row and cross-source queries before egress.
- request/response payloadsNot read from spans, not extracted into metrics, not present in any category the product queries.
- trace attributes beyond approved keysThe connector reads names, durations, status, and service labels. The attribute allowlist starts empty and grows only with your approval.
- end-user pii as a categoryNothing in the contract collects it. The hygiene rules in each guide exist to keep it out of metric labels and span attributes on your side.
- credentials & secretsPerfloop doesn't harvest secrets from your code or telemetry. Upstream provider credentials stay at the proxy edge and never enter the sandbox.
- deploy eventsNothing is pushed to Perfloop. Before/after verification keys off the version dimension already in your telemetry (service.version or your equivalent). Confirming that a version carries your merged PR reads commit ancestry through the code-host access you already granted — interpretation of a label your telemetry already carries, never a second signal.
Connections and residency.
What you connect and where Perfloop runs are separate, independent choices. Each connection is its own grant and revokes on its own. Nothing is connected by default.
what you connect
code host
Read access plus PR-write on repositories you select: the only writes are case branches and the PRs they carry, never a merge. Stands alone; no telemetry required.
read-only repo grant · benchmarks run in perfloop's sandbox · writes: case branches + prs, never a merge
telemetry source
A separate grant over views you author or datasets you sanitize. Aggregates are the only mode Perfloop uses.
customer-configured dataset/view scope + query-only credential are the confidentiality boundary · aggregate validation is defense in depth
where perfloop runs
our cloud
One workspace per customer on shared infrastructure.
the default · your data stays in this deployment
your cloud
The derived model never leaves your boundary.
byoc · enterprise · same contract, your residency
soc 2 attests our controls and applies regardless of what you connect or where we run · status below
Who enforces the boundary.
Customer-authored views or sanitized datasets, together with query-only credentials you scope at the provider, are the telemetry confidentiality boundary. Perfloop validates access to each named resource; it cannot inspect the credential's complete provider grant. Connectors also reject raw event rows and cross-source queries before egress; schema reads expose field names and types only. The aggregate-query guard minimizes data movement; because grouped results can contain authorized dimension values, it is defense in depth, not isolation. Every guide lists the grants you must configure before anyone connects anything.
GitHubliveFine-grained app on repositories you select, enforced by GitHub's permission model. Writes are case branches and the PRs they carry, never a merge.
Google Cloud Platformin developmentThe planned grant surface: monitoring.viewer, cloudtrace.user, and read on log views you author — arbitrary aggregate questions over the fields you authorize.
datadog · axiom · grafana · gitlab · bitbucket: guides ship with their connectors · all connection guides
Agent containment.
The agent runs your code and reads your telemetry, so the architecture treats it as compromised and contains it.
the agent is treated as compromised
- sandboxed sessionsEvery session runs in its own hardened, ephemeral sandbox (gVisor), destroyed when the session ends. Its only credential is a short-lived token that tells the proxy which session it is; the token grants nothing by itself, and the sandbox can't reach the infrastructure it runs on.
- upstream secrets stay outsideThe sandbox holds no upstream credentials for GitHub, model providers, or your telemetry. It receives only a short-lived session proxy token; the proxy attaches upstream credentials after route and grant checks pass.
- one path outDeny-by-default networking. The only route out of the sandbox, DNS included, is the proxy.
- permissions enforced in the proxyHost, method, and path allowlists plus per-session grants, checked deterministically outside the model. GitHub writes are bound to the approved branch and PR; merge, approve, and mark-ready are denied at the proxy.
The control plane.
Containing the agent is half of it. The platform that holds your derived data is itself least-privilege.
least privilege by default
- private databaseThe product database has no public address and refuses unencrypted connections. Access is over TLS from inside the private network only.
- encrypted at restAll stored data is encrypted at rest with platform-managed keys.
- scoped credentialsThird-party credentials are held only by the service that uses them, never by the agent. The code-host key, for instance, lives in the egress proxy, which mints short-lived per-request tokens at the boundary, so no session ever holds a raw token.
- least privilege between servicesControl-plane services are deny-by-default on the network, every path explicitly allowed. The session controller can verify callers and manage sandboxes, and nothing more: no exec into workloads, no privilege escalation, no impersonation.
- managed secret storeMaster keys and credentials live in a managed secret store, fetched per service at runtime under least privilege and held only in memory, never in an image or on disk.
- audit retention floorAudit logs are retained at least 13 months, enforced by a database floor that refuses a shorter window. The cleanup job can only invoke that function, never read or alter audit rows.
The questions your security team will ask.
Answered up front, against ground truth.
- 01
Does our raw data ever reach an LLM?
Today, connected source code enters model context; telemetry connectors are in development, and when they ship only aggregates will. That context goes to OpenAI's API. OpenAI does not log or store those requests (store=false, zero data retention). Customer content is not used to train models. By design, raw log events never enter model context: the planned telemetry path reads aggregates, not rows.
- 02
What happens if your agent is prompt-injected?
Assume it happens; the architecture does. The session holds no upstream provider credentials and has one network path: the proxy, where destination allowlists, per-session permissions, and credential injection are enforced outside the model. A hijacked agent gains no provider credentials, no new destinations, and no way to merge anything, and every request it makes passes through the proxy's route checks.
- 03
Who are the subprocessors?
Google Cloud hosts the product. OpenAI runs inference over their API. They do not log or store those requests (store=false, zero data retention). WorkOS authenticates users and stores account data (name, email, IP address) for anyone who logs into Perfloop, and never receives your telemetry or source code. Axiom holds Perfloop's own operational telemetry: service logs and metrics about Perfloop itself, which exclude customer code and customer telemetry content.
- 04
Can Perfloop employees see our data?
Operating the product on your behalf can require a Perfloop engineer to run a support session against your workspace. That access is SSO-authenticated, runs over the same proxy-mediated, revocable grant your own sessions use, and uninstalling cuts it. The formal controls around it (per-incident scoping, time-boxing, and access logging) are in progress, and we'll walk your team through exactly where they stand under a security review.
- 05
What happens when we revoke?
You revoke on your side, not by asking us. Uninstall the GitHub App and access dies immediately: the proxy mints every token per request from that App, so once it's gone there is nothing left to mint. No ticket, no waiting on us.
- 06
How do you know what data you need before seeing our telemetry?
We don't need to; that is the point of the contract. The categories are fixed and customer-invariant. The mapping to your datasets and fields happens inside grants you've already scoped: Perfloop discovers within them and proposes expansions per case, with stated justification, for you to approve. Access always precedes discovery.
Status.
This page documents what Perfloop accesses and how that access is controlled, in claims you can verify today. Formal attestations are in progress; their status is below.
- architecture review
- available now
- This page, the full data-access specification, and a founder walkthrough with your security team.
- soc 2 type ii
- observation period
- Type II observation is in progress. Audit-ready as of 15 August 2026. No Type I. The report is not issued. We are not certified.
- dpa
- on request
- Including the subprocessor list above.
- byoc
- enterprise
- Your cloud: the data plane in an account you provision.
For your
security team.
full specification + security questions: security@perfloop.ai →