Entire's Data Management

Entire stores AI session transcripts as Git data alongside your code. Secret detection is built on Betterleaks, with additional Entire-specific layers for high-entropy strings, credentialed URIs, database connection strings, user-defined regex rules, and opt-in PII. This page explains what’s stored, how secrets and PII are redacted before storage, how to add your own redaction rules, when data leaves your machine, how commits are signed, and how to report security issues.

Where your data lives

Transcripts and checkpoint metadata go to a dedicated branch in your Git repository (entire/checkpoints/v1), not to a service Entire controls. The web app at entire.io reads from that branch — what users see in the web app is the already-redacted content from the branch. Anyone with access to your repository can view the transcript branch. If your repository is public, that branch is public.

Redaction is best-effort, not a guarantee. For sensitive workloads — customer data, internal credentials, regulated material — use a private repository.

Starting in v0.6.2, Entire supports user-defined redaction: inline regex rules in settings and reusable rule packs under .entire/redactors/. See User-defined redaction below.

Reporting a vulnerability

Please do not open a public GitHub issue for a security vulnerability.

Email security@entire.io
Report security vulnerabilities directly. We acknowledge within 48 hours and aim to resolve criticals within 90 days. Full disclosure policy below.

Data storage details

The entire/checkpoints/v1 branch is the permanent home for redacted transcripts and checkpoint metadata. It’s pushed alongside your code with normal git push. Anyone with access to your repository can read it. Shadow branches (entire/<short-hash>) hold working snapshots during a live session. Metadata (transcripts, prompts, incremental checkpoint data, subagent transcripts) is redacted on write. Code-file snapshots, however, are raw blobs of your working tree without redaction — so any hardcoded secrets in your source files appear unredacted on the shadow branch. Gitignored files (e.g. .env) are filtered out of those snapshots as a partial defense. Shadow branches are local-only and are not pushed by Entire; do not push them manually, because unredacted source content would land on the remote.
Two redaction passes for metadata. Metadata is redacted on shadow-branch writes and again at condensation time when data is rolled into entire/checkpoints/v1. The metadata that lands in checkpoint storage — local or pushed — has been through redaction; the entire/checkpoints/v1 branch contains only metadata, no source code.

RedactedBytes type guarantee. Internally, the redact package exposes a typed wrapper that compile-time enforces redaction has happened before checkpoint writes — accidental writes of un-redacted data are caught at the type level rather than at runtime.

Commit trailers. Commits on your normal branches gain Entire-Checkpoint: <12-char-hex> and Entire-Attribution: <percent> agent (<n>/<m> lines) trailers. The trailers are public on push and live forever in commit messages. The hex is a random ID with no embedded PII; the attribution counts are aggregate numbers (no per-line content).

Remote URL redaction in logs. When a fetch or push fails, error messages and .entire/logs/ entries strip passwords from URLs (e.g. https://user:****@github.com) so credentials don’t end up in local log files.

Secret redaction (always on)

Five built-in detection passes run during condensation. Anything matched by any built-in layer is replaced with the literal token REDACTED. The built-in secret pipeline cannot be disabled; user-defined rules and PII add configurable layers on top.

1. Entropy scoring. Strings of 10+ alphanumeric characters with Shannon entropy above 4.5 are flagged. Catches API keys and tokens that don’t match any known vendor pattern.
2. Pattern matching via Betterleaks. The CLI embeds the Betterleaks detector, which ships ~260+ rules covering cloud providers (AWS, GCP, Azure), version-control platforms (GitHub, GitLab, Bitbucket), payment processors (Stripe, Square), communication tools (Slack, Discord, Twilio), private-key blocks (RSA, DSA, EC, PGP, OpenSSH), and generic credentials (bearer tokens, basic auth, JWTs).
3. Credentialed URI detection. URLs that embed user:password@host — for example postgres://user:pass@host/db or redis://:pass@host/0 — are redacted as a unit. These often have moderate entropy and aren’t reliably caught by vendor-specific patterns.
4. Database connection-string detection. Four sub-patterns: JDBC URIs (jdbc:...), database URLs (Postgres, MySQL, MariaDB, MongoDB, Redis), Postgres-style keyword DSNs (host=... user=... password=...), and SQL-Server-style semicolon connection strings (Server=...;User Id=...;Password=...). When a real (non-placeholder) password is present, the entire connection string is redacted because partial fragments can still expose sensitive material.
5. Bounded credential value detection. Variable assignments where the key matches a known credential name (DB_PASSWORD, PGPASSWORD, MYSQL_PWD, REDIS_PASSWORD, MONGO_PASSWORD, MONGODB_PASSWORD). Inside JSON, generic password/passwd/pwd keys are also redacted when the surrounding object looks like a connection descriptor — i.e. it contains both a host-like field (host/hostname/server/addr/address/datasource) and a user-like field (user/username/userid/uid). Only the value is redacted; the key is preserved.

User-defined redaction

User-defined redaction lets teams add regex-based rules on top of Entire’s built-in secret detection. Use it for internal token formats, project-specific identifiers, codenames, customer names, or other string patterns you do not want stored in session transcripts or checkpoint metadata. Custom rules use Go/RE2 regular expressions, so lookarounds and backreferences are not supported. Matches are replaced with the plain REDACTED token. Rule labels are for diagnostics only.
Inline rules. For simple project-level rules, add redaction.custom_redactions to .entire/settings.json:

{
  "redaction": {
    "custom_redactions": {
      "acme_token": "ACME_TOKEN_[A-Za-z0-9]{20,}",
      "internal_id": "INTERNAL_[a-z]{6}_[0-9]{4}"
    }
  }
}

For personal-only rules, put the same config in .entire/settings.local.json. Local settings merge with shared settings, so users can add private rules without changing team configuration.

Rule packs. For reusable rules, place YAML or JSON packs under .entire/redactors/:

# .entire/redactors/acme-internal.yaml
name: acme-internal
version: 1.0.0
description: Internal ACME service tokens
rules:
  - id: acme-token
    description: Long-lived ACME service tokens
    regex: 'ACME_TOKEN_[A-Za-z0-9]{20,}'
    samples:
      - { input: "key=ACME_TOKEN_abc123def456ghi789jkl", redacted: true }
      - { input: "ACME_TOKEN_short", redacted: false }

- id: acme-session
    regex: 'asess_[a-f0-9]{32}'

Required fields: name (must match the filename stem), version, and one or more rules, each with a unique id and a regex. Pack names and rule IDs may contain letters, numbers, ., _, and -. Supported extensions are .yaml, .yml, and .json.

Personal rule packs. Put uncommitted packs under .entire/redactors/local/. entire enable keeps that path ignored so personal codenames, customer references, or local-only patterns do not become shared repo configuration.

Self-tests. Rules can include samples with { input, redacted } expectations. Entire checks samples when it loads the pack. A failing sample logs a warning but does not disable the rule.

When rules take effect. No separate command is required. Entire loads inline rules and rule packs on the next CLI or hook invocation. Invalid regexes or malformed packs are skipped and logged instead of crashing the CLI.

PII redaction (optional)

PII redaction is a separate, opt-in layer that runs in addition to secret redaction. Disabled by default. Configured under redaction.pii in .entire/settings.json (team-shared) or .entire/settings.local.json (personal, gitignored).

Built-in categories:

Email allowlist. These addresses are not redacted as PII because they’re public bot/CI metadata that appear in nearly every git transcript: noreply@*, actions@*, *@users.noreply.github.com, *@noreply.github.com.

Custom patterns. Teams can add their own regex patterns via custom_patterns. The label becomes part of the replacement token (uppercased). For example, {"employee_id": "EMP-\\d{6}"} produces [REDACTED_EMPLOYEE_ID].

Settings example:

{
  "redaction": {
    "pii": {
      "enabled": true,
      "email": true,
      "phone": true,
      "address": false,
      "custom_patterns": {
        "employee_id": "EMP-\\d{6}"
      }
    }
  }
}

Where to put custom patterns. Patterns added under redaction.pii.custom_patterns in .entire/settings.json are committed to the repo and shared with the team — useful for org-wide rules, but the regex itself becomes public if the repo is public. For patterns that themselves shouldn’t leak (e.g. a regex that reveals an internal ID format), add them to .entire/settings.local.json (gitignored, personal) instead.

Limitations of redaction

• Best-effort. Novel or low-entropy secrets (short passwords, predictable tokens) may not be caught.
• Filenames and binary data. Secrets in filenames, binary files, or deeply nested structures may not be detected.
• Skip rules can hide secrets. The structural-field and image/base64 skip rules trade detection coverage for false-positive avoidance — a secret embedded in a path field or a base64 blob will not be redacted.
• Custom rules are user-authored. Teams own the correctness of their custom_redactions, rule packs, and PII custom_patterns. Invalid regexes are logged and skipped, not enforced.
• Custom redaction does not scrub source snapshots. It applies to transcript, prompt, and checkpoint metadata content written by Entire. Temporary checkpoint branches can still contain raw source-file snapshots, so hardcoded secrets should be avoided entirely.
• Users are ultimately responsible for reviewing what they push. Redaction is a safety net, not a guarantee.

Recommendations

• Use a private repository for sensitive workloads. Simplest and most complete protection.
• Avoid passing sensitive files into agent context. Content that never enters a transcript can never be exposed by transcript redaction failure.
• Review the entire/checkpoints/v1 branch locally before the first push. Same review you’d do for any other branch going public.
• Enable PII redaction if your team works with customer data. It’s off by default; turn it on per-repo or globally with the settings example above.

Telemetry and analytics

The CLI captures anonymous usage analytics by default. Sent to PostHog at eu.i.posthog.com. Event name: cli_command_executed.

What’s captured per command:

• Command name (e.g. entire enable, entire checkpoint rewind)
• Selected agent name (or auto)
• Whether Entire is enabled in the current repo
• CLI version
• OS and architecture (e.g. darwin/arm64)
• Names of flags passed ( not their values)

What’s not captured: flag values, prompt text, transcripts, file paths, repository identifiers, GitHub usernames, source code, IP-derived location (the PostHog client is configured with DisableGeoIP: true). DistinctID is a hashed machine identifier derived from machineid.ProtectedID — stable per machine, not directly mappable to a person.

Opt out (any one of):

• Pass --telemetry=false on commands that accept it.
• Set "telemetry": false in .entire/settings.json or .entire/settings.local.json.
• Set the env var ENTIRE_TELEMETRY_OPTOUT=1.

The first run of entire enable or entire configure asks for telemetry consent interactively; declining there sets the setting to false.

External services and data egress

The CLI runs locally and talks to external services in only a few specific cases:

Checkpoint commit signing

Checkpoint commits (on the shadow branch and the metadata branch) can be GPG- or SSH-signed using the same key already configured for your regular Git commits.Requirements (all of these must be true):

1. commit.gpgsign = true is set in your global or system Git config.
2. A supported signer is available — GPG (default) or SSH (set gpg.format = ssh and run ssh-agent).
3. The Entire setting sign_checkpoint_commits is true (the default; defaults to true when unset).

Best-effort behavior. Signing never blocks a commit. If the signer is unavailable, fails, or your hardware token requires a touch you didn’t give, the commit is created unsigned and a warning is logged to .entire/logs/. This avoids data loss in CI environments and during automated checkpoint saves. Opt out by setting "sign_checkpoint_commits": false in .entire/settings.json (team-shared) or .entire/settings.local.json (personal). Opting out does not affect signing of your regular commits.

Vulnerability disclosure (full policy)

Reporting. Email security@entire.io. Do not open a public GitHub issue for a security vulnerability.Include in your report:

• A clear description of the vulnerability.
• The impact (what an attacker could achieve).
• Detailed steps to reproduce.
• Affected CLI versions if known.
• A suggested fix if you have one (optional).

What to expect:

• Acknowledgment of receipt within 48 hours.
• Progress updates as we investigate.
• Resolution within 90 days for critical vulnerabilities.

Confidentiality. All reports are kept confidential. We will not share your information with third parties without your consent except as required by law.