Security Essentials

These rules are absolute. You cannot negotiate them. Every line on this page is a Never. "Never" means never — in any situation, for any reason, by anyone, on any system. No deadline, no manager's instruction, no "just this once", and no "it's only internal" makes any of them acceptable.

Identity & accounts

• NeverShare an account, login, or password between people/actors. Every actor — human, AI, or service — must have its own identity.
• NeverUse a personal account (personal email, personal cloud, personal device credentials) to access, store, or process company or customer data.
• NeverDisable, bypass, or "temporarily" skip multi-factor authentication on any account with access to systems or data.
• NeverKeep a leaver's, contractor's, or unused account active. Access ends when the need ends.

Secrets & keys

• NeverCommit a secret to source control — API keys, connection strings, certificates, account keys, client secrets. Not even for a moment, and not even in a private repo.
• NeverStore secrets in plaintext — in config files, environment files, IaC state, database columns, or logs.
• NeverHard-code a secret in application code, tests, or pipeline definitions.
• NeverSend a credential, token, key, or password over email, chat, SMS, ticket, screenshot, or any messaging tool — for any reason. Share access only through the approved secret store / vault.
• NeverReuse one secret across environments (dev/test/prod) or across services.
• NeverLeave a known-exposed secret in place. A secret that was committed or shared is compromised. Rotate it at once and treat it as a breach.

Authentication & authorization

• NeverExpose an endpoint that touches PII, money, or regulated data without authentication.
• NeverTrust an identity, role, or tenant that comes from the request body, query string, or a client-set header. Take the identity from a validated token, on the server.
• NeverShip [AllowAnonymous] (or any auth bypass) on a protected route — default-deny is the baseline.
• NeverQuery, update, or delete tenant-owned data without enforcing the tenant filter on the server. Never allow access across tenants.
• NeverLet a user give themselves a role or raise their own privileges through an unguarded create or update path.
• NeverAssume a customer's own employees are all trusted equally. Staff inside one tenant hold different roles and need-to-know, so enforce a role and least-privilege check on every action, not only a tenant boundary at the edge.

Handling untrusted input & integrations

• NeverBuild SQL, shell commands, file paths, or markup by joining together unvalidated input. Use parameterised queries and safe APIs.
• NeverAct on an inbound webhook or third-party callback before you verify its signature and that it is genuine.
• NeverTrust a value just because it came from your own database or another internal service. Stored data is still input, and you must validate it.
• NeverDisable TLS/certificate validation or run RequireHttpsMetadata=false against anything outside local dev.

Sensitive data

• NeverStore passwords in a form you can recover. Use a per-user salted, memory-hard hash. Never compare or return a plaintext password.
• NeverLog secrets, credentials, tokens, full PII, or special-category data.
• NeverReturn internal details (stack traces, SQL, secrets, file paths) to an external caller.
• NeverStore special-category or cardholder data we do not need. If we must hold it, encrypt it at rest.
• NeverHard-delete regulated records (customer, KYC, AML, audit, SARs). Use a soft-delete, with a role check, tenant scope, and an audit entry.

Decisions & safety

• NeverFail open. When something is missing, unknown, or uncertain, deny it or escalate to a human. Never default to allowing it.
• NeverHide a security-relevant error or skip a check to "make it work".
• NeverPerform a destructive or risk-changing operation without an audit record that cannot be changed, showing who did it and when.
• NeverWeaken a security control to meet a deadline. Raise the trade-off. Do not decide it on your own.

AML, KYC & regulated decisions

• NeverAuto-approve a customer, transaction, or onboarding when a screening, sanctions, PEP, or KYC check is missing, errored, timed out, or returned a result you do not recognise. The safe default is to block and escalate. Never approve.
• NeverTreat an unknown or unmapped input (country, industry, document type, risk band) as low or medium risk. Unknown means escalate.
• NeverDisable, bypass, or weaken a screening or monitoring control — including the screening kill-switch — without authorisation and a permanent audit record.
• NeverHide, edit, or delete a Suspicious Activity Report, an alert, or any required AML/KYC evidence. Regulated evidence can only be added to, never changed.
• NeverShip an automated decision that controls access to financial services without the required human-oversight and explainability controls in place.

Change control & automation

• NeverDeploy to production by hand or outside the normal process. All production changes go through the pipeline, with the security and quality gates enforced, not bypassed.
• NeverMerge or release code that has not passed the automated security checks (secret scanning, dependency/vulnerability scan, SAST). A failing gate is a stop, not a warning.
• NeverMake a change directly in the production database or environment without change control, review, and an audit trail.
• NeverCopy production data — especially PII, KYC, or AML data — into a development, test, or personal environment. Use synthetic or properly masked data.
• NeverGrant standing production access "to be efficient". Access is least-privilege, time-limited, and logged.