Client-owned accounts
Use named, least-privilege access. Avoid shared personal accounts and revoke access after delivery.
Delivery principle
Security starts with a smaller blast radius.
We design workflows around explicit access, bounded actions, observable failure, and accountable human decisions. This page describes an approach—not a certification or a claim that every reference build is production-ready.
Not in chat or code
Passwords, OTPs, tokens, private keys, payment data, and ID documents belong in approved secure channels—not reports, repositories, prompts, or tickets.
Human gates
Financial, legal, reputational, destructive, ambiguous, and customer-facing actions remain reviewable and owned.
Retries with limits
Stable identifiers, idempotency, retry budgets, terminal errors, and dead-letter handling prevent silent duplication and infinite loops.
Visible operation
Structured logs, run history, source freshness, alerts, and documented recovery replace “the automation probably ran.”
Minimise and separate
Use only authorised data needed for the outcome, separate client environments, define retention, and avoid production data in demos.
INITIAL CONTACT
Do not send a secret to request a quote.
Describe systems, volume, failure mode, desired outcome, and constraints without sharing live credentials or private datasets.
After scope and authority are confirmed, the owner and client choose the approved access path.
REPORTING A SECURITY ISSUE
Use security@pragmaticloop.com.
Do not exploit, access unrelated data, disrupt service, publish sensitive details, or demand payment. Share the minimum evidence needed to locate the issue and avoid including credentials or unrelated personal data. We will assess the report and choose a proportionate exchange channel for any sensitive follow-up.