| name | core-foundations-security-mindset |
| description | Always-on security mindset for every project and phase: hostile inputs, explicit trust boundaries, least privilege, secret hygiene, sensitive-data defaults, abuse cases, and escalation triggers before secure-coding or platform-specific security skills add controls. |
Security Mindset
Security is a default posture, not a review phase. Every project starts by assuming outside input,
clients, networks, dependencies, generated content, and integrations can behave maliciously or
incorrectly.
Baseline assumptions
- Treat all external input as hostile until validated at the boundary: requests, forms, files,
URLs, webhooks, queues, model output, third-party API responses, browser storage, and imported
data.
- Treat clients as untrusted. Authorization happens on the trusted side of the boundary, never
only in UI or client logic.
- Treat secrets as live credentials. They never belong in source, logs, screenshots, generated
artifacts, prompts, examples with real values, or analytics.
- Treat dependencies as code you run. New packages, plugins, actions, skills, and install scripts
are supply-chain surface.
- Treat internal tools as reachable. "Only internal" reduces exposure; it does not remove the
need for auth, logging, least privilege, and safe defaults.
Trust-boundary sketch
Before implementing a feature that touches data, auth, external systems, or generated content,
name:
- Where untrusted input enters.
- Which assets matter: credentials, PII, payments, admin actions, private content, availability,
model/tool permissions, or business records.
- Who can act: anonymous users, authenticated users, owners, admins, services, background jobs,
vendors, or agents.
- What abuse case would hurt: spoofing, tampering, repudiation, information disclosure, denial of
service, privilege escalation, prompt/tool injection, or supply-chain compromise.
- Which skill owns the control:
core-build-secure-coding, ai-ml-build-ai-security,
backend-build-backend-security, or a platform-specific overlay.
Non-negotiables
- Least privilege by default: tokens, service accounts, scopes, file access, agent tools, and
admin roles start narrow and expand only with a reason.
- Sensitive data has an owner, storage location, retention rule, logging rule, and access rule.
- Authentication proves identity; authorization proves permission for the specific resource and
action.
- Errors shown to users do not expose internals, secrets, stack traces, SQL, provider responses, or
security policy details.
- Security-sensitive decisions are explicit in code, contracts, or documentation; do not bury them
in conventions only one framework understands.
Escalate before building
Pause for a focused security pass when a change introduces or modifies auth, roles, sensitive data,
payments, file upload, SSRF-capable fetching, webhooks, external integrations, CORS, agent/tool
permissions, dependency installation, encryption, audit logging, tenancy boundaries, or production
secrets.
Use core-build-secure-coding for implementation controls and core-ship-launch-checklist for
the final release gate.
