Security Architecture and Threat Model¶

A formal security architecture, trust boundary analysis, and threat model for Chief Information Security Officers (CISOs), enterprise security architects, and compliance auditors evaluating bb (Bitbucket Data Center CLI).

Document Metadata¶

Field	Value
Document Version	1.2.0
Target System	`bb` (Bitbucket Data Center CLI)
Classification	Public Security & Threat Analysis Whitepaper
Methodology	STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
Effective Date	September 2026
Review Cadence	Annual, or upon major architectural revision

Scope & System Boundaries¶

In-Scope: The bb compiled binary runtime, local process execution, operating system keyring integration, Git credential helper protocol, local repository manipulation, network transport (TLS 1.2+, proxy traversal, custom CA handling), built-in MCP server (bb ai mcp serve), and release artifact distribution.
Out-of-Scope: Bitbucket Data Center server-side zero-day vulnerabilities, host operating system kernel compromise / rootkit, and the external data handling / privacy practices of third-party cloud LLM providers connected to developer IDEs.

1. Asset Inventory & Adversary Model¶

Assets to Protect¶

Asset ID	Asset Name	Description	Sensitivity
A-1	Authentication Credentials	Personal Access Tokens (PATs) and HTTP Basic credentials used to authenticate API and Git operations.	Critical (Confidentiality & Integrity)
A-2	Source Code & Working Trees	Proprietary source code in cloned repositories, working tree diffs, pull request comments, and file contents.	High (Confidentiality & Integrity)
A-3	Repository Gate Integrity	Pull request review approvals, branch merge gates, and commit history on the Bitbucket server.	High (Integrity)
A-4	Executable Integrity	Authenticity and provenance of the compiled `bb` binary running on developer workstations.	Critical (Integrity)

Adversary Profiles¶

Adversary	Description	Access Level & Capabilities
ADV-1: Local Unprivileged User	Multi-user jump host user, malicious developer, or unprivileged local background process.	Can read `/proc/<pid>/cmdline`, process table (`ps aux`), unencrypted filesystem paths, and user environment variables.
ADV-2: Network Interceptor	Man-in-the-Middle (MitM) attacker on local network, untrusted forward proxy, or compromised DNS.	Can intercept, inspect, or tamper with outbound network traffic if TLS validation is absent or compromised.
ADV-3: Prompt-Injected AI Agent	Autonomous AI developer tool (Cursor, VS Code Agent) manipulated via indirect prompt injection in pull request diffs or comments.	Can invoke exposed Model Context Protocol (MCP) tools over stdio to read data or trigger mutations.
ADV-4: Upstream Supply Chain Attacker	Adversary targeting upstream dependencies, build runners, or release distribution channels.	Can attempt to inject malicious code into dependencies or tamper with published release archives.

2. System Architecture & Trust Boundaries¶

The following architecture diagram models all six trust boundaries across the workstation, local repositories, corporate network, IDE AI integration, and build pipeline:

flowchart TB
    subgraph TB1["TB-1: Process & Terminal Environment"]
        User["Developer / Shell"]
        CLI["bb Process (Cobra / Transport)"]
        User -- "stdin pipe (--token-stdin)" --> CLI
    end

    subgraph TB2["TB-2: OS Keyring Store"]
        Vault[("OS Keyring: DPAPI / Keychain / Secret Service")]
        CLI -- "Store / Retrieve Secret" --> Vault
    end

    subgraph TB3["TB-3: Git Working Tree"]
        GitEngine["Git Engine (child process)"]
        RepoConfig[".git/config (Local Clone)"]
        CLI -- "Dynamic Credential" --> GitEngine
        GitEngine --> RepoConfig
    end

    subgraph TB4["TB-4: Network Perimeter"]
        Proxy["Corporate Forward Proxy"]
        BBServer["Bitbucket Data Center Instance"]
        CLI -- "REST API (TLS 1.2+ / Internal CA)" --> Proxy --> BBServer
        GitEngine -- "Git-over-HTTP" --> Proxy --> BBServer
    end

    subgraph TB5["TB-5: IDE & AI Agent Surface"]
        IDE["IDE / Agent (VS Code, Cursor)"]
        LLMProvider["LLM Cloud API (External)"]
        CLI -- "MCP stdio pipe (bb ai mcp serve)" --> IDE
        IDE -. "Everyday Flow: Diff & Code Snippets" .-> LLMProvider
    end

    subgraph TB6["TB-6: Software Supply Chain"]
        GHA["GitHub Actions Release Workflow"]
        Sigstore[("Sigstore / Cosign OIDC")]
        GHA -- "Keyless Sign & Attest" --> Sigstore
        Sigstore -. "Verify Binary Provenance" .-> CLI
    end

Trust Boundary Definitions¶

Boundary	Components	Trust Level	Security Invariants
TB-1: Process & Terminal	`bb` runtime process, memory, arguments, stdout/stderr	Trusted Local User	Zero secret leakage in process argument table (`/proc/<pid>/cmdline`). Zero telemetry.
TB-2: OS Keyring Store	Windows Credential Manager, macOS Keychain, Linux Secret Service	System Security Enclave	Secrets held encrypted at rest. Immediate failure if plaintext fallback is needed when `BB_REQUIRE_KEYRING=1` is set.
TB-3: Git Working Tree	Local git clone, `.git/config`, `git` CLI child processes	Semi-Trusted Filesystem	Zero credentials persisted into repository `.git/config`. Host-scoped credential querying.
TB-4: Network Perimeter	Corporate forward proxies, internal enterprise PKI, Bitbucket DC	Untrusted / Inspected Network	Minimum TLS 1.2. Additive corporate CA trust pool. Strict non-interactive timeout enforcement.
TB-5: AI / MCP Surface	IDE agent (Cursor, VS Code, Claude Desktop), stdio RPC pipe	Constrained Automation	Safe-by-default tool gating. Unsafe tools withheld without explicit `--yolo`. Dedicated read-only tokens.
TB-6: Supply Chain	GitHub Actions builder, release packaging, Sigstore/Cosign	Cryptographic Verification	Keyless OIDC signatures, SLSA build provenance attestations, attested SPDX 2.3 SBOM.

3. The Everyday Source-Code-to-LLM Data Flow¶

A primary question in enterprise security evaluations of AI-enabled developer tooling is: what proprietary data leaves the workstation, and to whom is it transmitted?

The MCP Channel Architecture¶

When bb ai mcp serve runs, it communicates strictly over standard input/output (stdio) with the local IDE process (e.g. VS Code, Cursor).

[Bitbucket DC] ──(HTTPS/Internal CA)──> [bb CLI (Local)] ──(stdio RPC)──> [Local IDE] ──(HTTPS/IDE Config)──> [Cloud LLM]

Local CLI Boundary: bb sends zero external telemetry and initiates no network requests to AI providers. It has three possible destinations and no others: the Bitbucket server you configure, and — only when someone runs bb update — the release host, api.github.com by default or an internal mirror via update_base_url, and Sigstore's tuf-repo-cdn.sigstore.dev for the trust material the signature check needs, unless update_trusted_root supplies it from disk. There is no background, start-up or periodic check, so nothing leaves the workstation unless a command asks it to. A binary built with -tags no_self_update, or one where policy sets disable_update: true, refuses before any request is made and leaves Bitbucket as the only destination (ADR-059).
The Stdio Pipe: When an AI agent executes tools like get_pr_diff, get_pull_request, or list_pr_comments, bb fetches the data from Bitbucket and prints structured JSON to stdout.
The IDE & Cloud LLM Transmission: The IDE consumes this output and includes the source code diffs in prompt contexts sent to the developer's configured LLM provider (e.g. OpenAI, Anthropic, or internal corporate Ollama/vLLM endpoints).

Hardening the By-Design Flow¶

To govern this everyday flow: - Dedicated Read-Only Token: Bind bb ai mcp serve to a service token with read-only rights (BITBUCKET_TOKEN in the client's env block), ensuring the agent cannot execute mutations on the Bitbucket server even if prompted. - Explicit Tool Allowlists: Constrain exposed tools using --tools get_pull_request,list_pull_requests,get_pr_diff,list_pr_comments,add_pr_comment. - Egress Governance: Outbound LLM network traffic is managed at the IDE layer (via corporate proxy, DLP filtering, or private Azure OpenAI / AWS Bedrock VPC endpoints).

4. Multi-OS Policy Enforcement Realities¶

Enterprise policy enforcement mechanisms differ across operating systems, unified under the multi-tier hierarchy (ADR-058):

Operating System	Fleet Tooling	Primary Policy Channel	Fallback Policy Channel	Enforcement Posture
Windows	Microsoft Intune / SCCM / Active Directory GPO	Windows Registry (`HKLM\Software\Policies\bb`)	System Config (`%ProgramData%\bb\config.yaml`)	High. Unprivileged users cannot modify `HKLM\Software\Policies`. Registry policy takes immutable precedence over user environment variables and user configuration files.
macOS	Jamf Pro, Kandji, Apple MDM	System Config (`/etc/bb/config.yaml`, `chmod 644 root:wheel`)	System Shell Profiles (`/etc/zshenv`)	High. Read directly by the `bb` binary across both terminal shells and GUI parent processes (such as IDE-launched MCP servers).
Linux (Workstations)	Ansible, Puppet, SaltStack, Red Hat Satellite	System Config (`/etc/bb/config.yaml`, `chmod 644 root:root`)	Shell Environment (`/etc/profile.d/bb.sh`)	High. Standard root-owned system configuration. Immutable by non-root users on developer workstations and multi-user jump hosts.
Linux (CI Runners)	Kubernetes, Docker, Runner Daemons	Ephemeral Environment Variables (`BITBUCKET_TOKEN`, `BB_DISABLE_STORED_CONFIG=1`, `BB_DISABLE_UPDATE=1`)	Baked Container Image `/etc/bb/config.yaml`	High. Containers lack desktop keyrings; `BB_DISABLE_STORED_CONFIG=1` guarantees zero stored credential reads and zero keyring daemon access.

5. STRIDE Threat Domain Analysis¶

Each domain is analyzed using the Threat (STRIDE) ↔ Architectural Mitigation ↔ Audit Test Procedure ↔ Residual Gap triad.

Domain 1: Secret Hygiene & Storage at Rest (TB-1 & TB-2)¶

1. Threat Analysis (STRIDE: Information Disclosure)¶

Attacker Vector (ADV-1): Unprivileged local users, compromised background processes, or EDR agents scrape secrets passed via CLI flags through ps aux or /proc/<pid>/cmdline.
Plaintext Fallback Risk: If an OS keyring is unavailable, CLI tools may silently fall back to unencrypted disk files:
Linux: ~/.config/bb/config.yaml
macOS: ~/Library/Application Support/bb/config.yaml
Windows: %AppData%\bb\config.yaml

2. Architectural Mitigations¶

Mandatory Stdin Ingestion: bb auth login supports --token-stdin and --password-stdin, reading secrets strictly over standard input.
No Secret-Bearing Flags: No flag accepts a credential value. A token or password reaches bb over stdin or through the environment, so process-table exposure has no supported path rather than a warned-about one (ADR-047).
Enforced Keyring Storage: Setting require_keyring: true in system configuration or Windows Registry HKLM\Software\Policies\bb hard-refuses plaintext fallback machine-wide and cannot be bypassed by unprivileged users unsetting environment variables (ADR-058). Advisory BB_REQUIRE_KEYRING=1 remains supported for ad-hoc user environments.
Headless Disabling: Setting BB_DISABLE_STORED_CONFIG=1 in CI/CD completely skips stored config reads and keyring access, reading solely from BITBUCKET_TOKEN.

3. Audit Test Procedure¶

bb auth status --json

Audit Assertion: Verify that .data.credentialStorage equals keyring (on workstations) or environment (in CI runners), and never config-file-plaintext.

4. Residual Gap & Tracking¶

Resolution: Fully resolved via system-wide configuration (/etc/bb/config.yaml, %ProgramData%\bb\config.yaml) and Windows Registry policy (HKLM\Software\Policies\bb) with require_keyring: true (ADR-058, Issue #420). Plaintext fallback cannot occur when mandated by machine policy.

Domain 2: Git Transport & Repository Boundaries (TB-3)¶

1. Threat Analysis (STRIDE: Information Disclosure, Elevation of Privilege)¶

Attacker Vector (ADV-1, ADV-2): Persisting tokens into .git/config (via legacy http.extraHeader) leaks credentials whenever repositories are archived, copied, or pushed. Furthermore, an unscoped http.extraHeader is transmitted to any HTTP remote, leaking internal Bitbucket tokens to external remotes.
Attacker Vector (ADV-1, ADV-3): A cloned repository carries configuration with it. A .bb/config.yaml in the repository, or a .env in it or any parent directory, can name the host bb talks to; so can --host and a URL passed to bb api, which is what a prompt-injected agent controls.

2. Architectural Mitigations¶

Host-Scoped Credential Helper: bb auth setup-git writes a credential helper rule scoped strictly to the Bitbucket hostname into the global ~/.gitconfig (ADR-044):
```
[credential "https://bitbucket.example.com"]
  helper = !"/usr/local/bin/bb" auth git-credential
```
Zero Repository Footprint: Cloned repositories contain zero credentials or tokens in their local .git/config.
A Credential Is Bound To Its Host: a stored credential is released only for the host it was stored for. A host named by repository configuration, by --host, or by a URL passed to bb api therefore gets no credential unless one is stored for that exact host, whatever the default host is.
Nothing Sensitive On The Command Line: the header a clone needs is passed to git in its environment, which only the owner of the process can read, rather than in its arguments, which any local account can read while the clone runs.
Instant Revocation: If a token is revoked in Bitbucket or removed via bb auth logout, all local clones immediately lose access without requiring manual git cleanup.

3. Audit Test Procedure¶

git config --local --get http.extraHeader

Audit Assertion: Command exits with non-zero status (no extra headers found).

Domain 3: Network Perimeter, Proxies & Internal PKI (TB-4)¶

1. Threat Analysis (STRIDE: Information Disclosure, Tampering)¶

Attacker Vector (ADV-2): Interception proxies re-signing traffic using internal enterprise root CAs cause certificate trust failures. Developers may attempt to bypass errors using --insecure-skip-verify.

2. Architectural Mitigations¶

Mutual TLS (mTLS) Client Authentication: Transport layer natively supports client certificates and private keys (--client-cert, --client-key, BB_CLIENT_CERT, BB_CLIENT_KEY, or stored profile client_cert/client_key in ~/.config/bb/config.yaml) to authenticate endpoints to ingress reverse proxies (ADR-060).
Additive Corporate CA Trust Pool: BB_CA_FILE appends the internal CA bundle to x509.SystemCertPool(), preserving public root verification while trusting the internal Bitbucket host.
Proxy Traversal: Inherits HTTPS_PROXY, HTTP_PROXY, and NO_PROXY directly from Go's http.DefaultTransport.
TLS 1.2+ Enforced: Pinned minimum version tlsConfig.MinVersion = tls.VersionTLS12.
Insecure Verification Is Refusable by Policy: allow_insecure_skip_verify: false in system configuration or Windows registry policy makes --insecure-skip-verify and BB_INSECURE_SKIP_VERIFY=true fail with an authorization error rather than downgrading the connection. This is the control that answers the bypass in the threat above, and it is off unless an administrator deploys it (ADR-058).
Zero Telemetry: Guaranteed zero external analytics or metrics calls (SECURITY.md).

3. Audit Test Procedure¶

bb --client-cert /etc/ssl/certs/client.pem --client-key /etc/ssl/private/client.key repo list --limit 1

Audit Assertion: Verify that the connection succeeds over TLS 1.2+ with client certificate authentication and routes through the designated HTTPS_PROXY.

4. Residual Gap & Tracking¶

mTLS: resolved. Client certificate support is native to the transport layer (--client-cert, --client-key, BB_CLIENT_CERT, BB_CLIENT_KEY, and per-host stored profiles), so authenticating to an ingress reverse proxy needs no wrapper (ADR-060).
The verification bypass is closable, not closed by default. --insecure-skip-verify exists and works until an administrator sets allow_insecure_skip_verify: false. On a fleet where that policy has not been deployed, a developer who hits a certificate error can still turn verification off for themselves, and nothing outside the local machine records that they did. Deploying the policy is the control; treat an undeployed fleet as carrying this gap rather than as covered by the paragraph above.

Domain 4: Autonomous AI & MCP Server Governance (TB-5)¶

1. Threat Analysis (STRIDE: Tampering, Elevation of Privilege, Information Disclosure)¶

Attacker Vector (ADV-3): Prompt injection in pull request diffs or comments manipulates an AI agent into performing destructive mutations (approving unauthorized PRs, merging unvetted code, modifying build status) or querying sensitive repositories across unrelated projects.

2. Architectural Mitigations¶

Safe vs. Unsafe Tool Isolation: High-impact mutating operations (submit_pr_review, merge_pull_request, enable_auto_merge, set_build_status) are withheld by default (ADR-039). Crucially, withholding submit_pr_review prevents an agent from self-approving its own pull requests.
Dedicated Read-Only Token Scoping: Running bb ai mcp serve with BITBUCKET_TOKEN set to a read-only PAT in the MCP client's env block forces the MCP server to execute under a service token with read-only server rights.
Explicit Capability Allowlists: Constraining exposed tools via --tools or --exclude.
Workspace Scoping: --project and --repo confine every tool call to one project or repository (ADR-062). Enforcement is a single choke point over tools/call, not a per-tool check: arguments that are omitted are bound to the scope, arguments that name something else are refused, and tools that address a resource Bitbucket does not scope to a project — build statuses, which hang off a commit SHA — are withheld while a scope is set.
Agent Audit Trail: --audit-file records every tool invocation as JSON Lines for SIEM ingestion, with secrets redacted. Its distinct value over Bitbucket's own audit log is attribution (every MCP call reaches Bitbucket as the same user with the same PAT) and denied attempts (a refused call never reaches Bitbucket, so no server-side record of it can exist). The destination is mandatable machine-wide via policy.mcp_audit_file, which holds only where an administrator owns the policy file: bb never creates the system configuration directory, so on Windows C:\ProgramData\bb must be created by an administrator first (ADR-058, point 5). It is also the one policy setting with no HKLM\Software\Policies\bb value, so GPO is not an alternative for it.

3. Audit Test Procedure¶

bb ai mcp tools

Audit Assertion: Confirm that unsafe tools are marked as withheld unless explicitly authorized.

bb ai mcp serve --project PAYMENTS --audit-file /var/log/bb/mcp-audit.jsonl

Audit Assertion: A tool call naming a project other than PAYMENTS returns an error result and appears in the audit log with "status":"denied".

4. Residual Gap & Tracking¶

The audit trail is not tamper-evident. It is written on the developer's workstation, as the developer, to a path they can modify. It is evidence against a prompt-injected agent confined to MCP tools (ADV-3), which has no shell; it is not evidence against a determined insider.
The CLI beside it is ungated. An agent with shell access can invoke bb directly and reach every command in the CLI with none of the safety gating, workspace scoping or auditing described here. bb api is the sharpest of them: it forwards an arbitrary authenticated request to Bitbucket, so it reaches endpoints no tool wraps and makes per-tool classification irrelevant to anything holding a shell. It is deliberately not exposed as an MCP tool — the server exposes a fixed catalogue of named operations, with no raw-request passthrough among them (ADR-053) — so this is a statement about the shell beside the server, not a gap in the tool surface. None of it is closable at this layer: an agent that can run shell commands can also edit the audit file. The mitigation that survives is the dedicated read-only PAT the server runs under (BITBUCKET_TOKEN in the MCP client's env block), which binds at the Bitbucket server and is indifferent to which local process issued the call — and which bounds bb api exactly as it bounds every tool. MCP-layer controls are defence in depth over a correctly scoped token, not a replacement for one.

Domain 5: Supply Chain & Software Distribution (TB-6)¶

1. Threat Analysis (STRIDE: Tampering)¶

Attacker Vector (ADV-4): Compromised build runners, malicious upstream dependencies, or tampered release packages could introduce backdoors into developer environments. Additionally, running bb update on managed machines bypasses package managers and change approval boards.

2. Architectural Mitigations¶

Sigstore / Cosign Keyless Signing: Releases are signed via OIDC identity bound to .github/workflows/release.yml@refs/heads/main.
GitHub Build Provenance: Provenance attestations verifiable via gh attestation verify.
Attested SPDX 2.3 SBOM: Every release archive has its own SBOM, generated from the binary it contains, checked against that binary's build information, and attested against every artifact it describes.
https-Only Update URLs: bb update refuses a plain-HTTP mirror, download or redirect unless a user opts in with --allow-http or BB_ALLOW_HTTP_UPDATE; allow_http_update: false in system policy removes that option.

3. Audit Test Procedure¶

The signature, provenance and SBOM checks are one procedure, written once in Release Verification. Run it against the artifact under audit.

4. Residual Gap & Tracking¶

Update bypass: resolved. Administrative killswitches (BB_DISABLE_UPDATE=1, disable_update: true in system configuration), compile-time removal (-tags no_self_update), and custom release mirrors (--base-url, BB_UPDATE_BASE_URL, update_base_url) each stop bb update from going around a package manager (ADR-059). On a host with no internet access a mirror also needs an offline Sigstore trust root (update_trusted_root), without which signature verification cannot complete (ADR-063).
Signature verification can be switched off by policy. allow_unverified_update: true skips it entirely; the SHA256 checksum is still enforced, so the release is protected against corruption but not against tampering by whoever controls the mirror. It is deliberately policy-only — no flag, no environment variable — and every run warns on stderr and reports signature_skipped: true under --json. An estate that has set it has traded this domain's main guarantee for reachability, and should treat the mirror as part of its trusted computing base. An offline trust root is the option that does not make that trade.

Domain 6: Enterprise Identity & Federation (SSO)¶

1. Threat Analysis (STRIDE: Spoofing, Elevation of Privilege)¶

Attacker Vector (ADV-1): Static personal access tokens with infinite lifespans escape centralized IdP lifecycle de-provisioning.

2. Architectural Mitigations¶

Scoped TTL Tokens: bb auth token create --expiry-days <N> supports time-bound tokens.
Immediate Invalidation: Tokens revoked in Bitbucket Server immediately invalidate all CLI and git operations.

3. Audit Test Procedure¶

bb auth token list

4. Residual Gap & Tracking¶

Limitation: Bitbucket Data Center ships with zero configured OAuth clients, and non-admin users cannot create them. Enabling a browser OAuth flow requires extensive server-administrator changes.
Tracked Issue: Issue #424: feat: opt-in OAuth 2.0 browser login for enterprise SSO.

6. Compliance Matrix & Risk Treatment Plan¶

Threat ID	Threat Description	Regulatory Mapping	Residual Risk	Risk Treatment	Test Procedure	Tracked Issue
T-1	Process table secret sniffing & plaintext disk fallback	SOC 2 CC6.1, ISO 27001:2022 A.8.24, NIST SP 800-53 AC-3	Low	Fully mitigated via mandatory Keyring policy enforcement (`require_keyring: true`), system configuration tier, and stdin ingestion (ADR-058).	`bb auth status --json`	—
T-2	Repository secret bleed & cross-remote credential leakage	SOC 2 CC6.6, ISO 27001:2022 A.8.12	Low	Mitigated via host-scoped Git credential helper (`bb auth setup-git`).	`git config --local --get http.extraHeader`	—
T-3	Inability to traverse mutual TLS (mTLS) ingress	NIST SP 800-207 (Zero Trust Architecture), SC-8	Low	Fully mitigated via mTLS client cert/key support (`--client-cert`, `--client-key`, `BB_CLIENT_CERT`, `BB_CLIENT_KEY`, and stored profiles; ADR-060).	`bb --client-cert ... --client-key ... repo list`	—
T-4	Prompt-injected AI agent executing unauthorized mutations	OWASP Top 10 LLM (2025 LLM01, LLM06), SOC 2 CC6.8	Low	Mitigated via safe/unsafe tool withholding, workspace scoping (`--project`, `--repo`), and a redacted JSONL audit trail recording allowed and denied invocations (ADR-062). Residual: the trail is not tamper-evident, and an agent with shell access can bypass the MCP layer entirely — a read-only PAT supplied through the client's `env` block is the control that survives that.	`bb ai mcp serve --project PAYMENTS --audit-file <path>`	—
T-5	Unmanaged binary updates breaking package manager state	ISO 27001:2022 A.8.19, NIST SP 800-53 SI-2	Low	Fully mitigated via `BB_DISABLE_UPDATE=1`, system config `disable_update: true`, build tag `no_self_update`, and internal release mirror resolution (ADR-059). Air-gapped mirrors additionally require an offline Sigstore trust root (ADR-063).	`bb update` on managed machine	—
T-6	Unfederated static token lifecycle management	CIS Controls v8 5.4 / 6.1, NIST SP 800-63B	Medium	Mitigate via scoped TTL PATs; browser flow requires Bitbucket DC admin configuration.	`bb auth token list`	#424

7. Security Invariants Summary¶

Prompts only where a person can answer (ADR-073): with no terminal, or under --json, bb never blocks on stdin; it fails fast naming what it needed, so automation and CI/CD pipelines cannot hang.
Zero External Telemetry (SECURITY.md): bb sends no telemetry, metrics, or usage statistics to any third-party server.
Structured Error Taxonomy (ADR-011, ADR-046): Fatal failures emit a predictable JSON error envelope with categorized error taxonomy (validation, authentication, authorization, not_found, conflict, transient, permanent, cancelled, unknown_outcome, not_implemented, internal).