Local Security and Privacy Baseline — v1¶

Status: active Version: 1.0.0 Effective: 2026-05-04 Owners: security + compliance

This baseline applies to every local project that runs in this workspace. Each project must declare conformance and pass attestation periodically. Versioning follows SPB-15.

Purpose¶

Provide a single, versioned, auditable answer to "is this project safe to operate from this workspace?". The baseline is compact (15 controls), high-leverage, and changes only through the controlled SPB-15 process.

Scope¶

All local projects executed via Cursor agents on this workspace's laptop.
All Cursor skills, subagents, plugins, and MCP servers active in any of those projects.
All credentials and tokens used by any of those agents.

How to attest¶

Each project keeps a small security-attestation.md with:

baseline version it conforms to (e.g., v1),
date of last attestation,
per-control evaluation (pass / partial / fail / n/a),
evidence pointers,
approver.

The security-checklist skill produces the per-control evaluation portion automatically.

Audit cadence¶

Every project: at least quarterly attestation, or any time the baseline version changes.
Every credential lifecycle event: per credential-lifecycle-policy.yaml.
Every privileged orchestration action: per audit-log-spec.md.

Control catalog (v1)¶

SPB-01 — Data classification required¶

Every project must classify the data it handles (private_sensitive, internal, low_sensitive) and map controls by class. The classification is recorded in the project README, in any AnyType Project object, and respected by all routing/runtime decisions.

SPB-02 — Agent credential isolation¶

Agent-readable credentials must be unique per agent or task scope. Shared user credentials are prohibited in agent runtimes. Each agent integration carries a labeled, agent-scoped credential.

SPB-03 — User-only secret store¶

User-level credentials must be stored in a location that is inaccessible to agents. The store is excluded from all agent runtime mounts and prompt context. The agent does not know the store's path; the user provisions agent-scoped derivatives manually.

SPB-04 — Least-privilege credential scopes¶

Every credential documents its minimum allowed actions and resources, with deny-by-default boundaries. Scopes are reviewed at provisioning and at every rotation.

SPB-05 — Time-bounded credentials and token TTL¶

Long-lived credentials are discouraged. Token lifetimes are bounded and documented. Default agent-scoped credential TTL is ≤ 90 days; JIT tokens default to ≤ 1 hour.

SPB-06 — JIT access for privileged operations¶

Privileged operations (release tagging, credential rotation, governance changes) require JIT grants with explicit human approval and automatic expiry.

SPB-07 — Credential provisioning workflow¶

New agent credentials require: written request, approval by security owner, scope review, attested deployment record, and an entry in the audit log.

SPB-08 — Rotation and revocation policy¶

Credentials rotate on schedule (default 90 days) and on incident triggers. Revocation paths are tested at least annually. Rotation failures escalate to the security owner.

SPB-09 — Secret handling controls¶

No plaintext secrets in any of: repos, prompts, chat history, logs, screenshots, generated artifacts, exported data. Redaction standards are enforced by the security-checklist skill and Bugbot R2.

SPB-10 — Runtime boundary enforcement¶

Local / home-lab / cloud execution must follow the runtime policy and the data-class-to-runtime mapping. Mismatches deny by default and emit an audit event.

SPB-11 — Network egress restrictions¶

Agent and sandbox environments default to minimal outbound access. New endpoints require an explicit allowlist entry plus rationale. Sandboxes default to no outbound access.

SPB-12 — Immutable audit trails¶

All privileged actions and credential lifecycle events are logged with actor identity, scope, timestamp, and outcome, conforming to audit/audit-log-spec.md. Logs are append-only and tamper-evident.

SPB-13 — Security baseline attestation¶

Each project declares its baseline version and passes periodic attestation with evidence artifacts. Failed attestation pauses promotion and triggers remediation.

SPB-14 — Incident response readiness¶

Each project defines a secret-compromise playbook covering detect → contain → rotate → recover → postmortem. The playbook is tested at least annually in a tabletop drill.

SPB-15 — Policy change control¶

Baseline version updates require: documented impact analysis, migration guidance, re-attestation criteria for affected projects, and approval by security + compliance co-owners. Old versions remain documented for backward reference.

Project compliance attestation format¶

# security-attestation.md

- baseline_version: v1
- last_attested: <yyyy-mm-dd>
- approver: <owner>

## Evaluations

| Control | Result | Evidence |
| ------- | ------ | -------- |
| SPB-01  | pass   | data_classification recorded in README |
| SPB-02  | pass   | agent-scoped key in env-var only |
| SPB-03  | pass   | user secret store path not in any allowlisted mount |
| SPB-04  | pass   | scopes documented in credential-lifecycle-policy entry |
| SPB-05  | pass   | TTL 90d configured |
| SPB-06  | n/a    | no privileged operations in scope |
| SPB-07  | pass   | provisioning runbook followed |
| SPB-08  | pass   | last rotation <date>; next due <date> |
| SPB-09  | pass   | bugbot R2 + security-checklist clean |
| SPB-10  | pass   | runtime policy applied |
| SPB-11  | pass   | egress allowlist matches deps |
| SPB-12  | pass   | audit log present and conforming |
| SPB-13  | pass   | this attestation |
| SPB-14  | partial| playbook present, tabletop pending |
| SPB-15  | n/a    | no baseline change applied |

## Open items
- SPB-14 tabletop drill scheduled for <date>.

Versioning¶

Patch (v1.0.x): clarifications, no behavior change.
Minor (v1.x.0): new advisory controls, or stricter evidence.
Major (v2): breaking changes; requires SPB-15 process.