Client-owned accounts
Use named, least-privilege access. Avoid shared personal accounts and revoke access after delivery.
Delivery principle
We design workflows around explicit access, bounded actions, observable failure, and accountable human decisions. This page describes our approach. It is not a certification, and it does not claim that every reference build is production-ready.
Use named, least-privilege access. Avoid shared personal accounts and revoke access after delivery.
Passwords, OTPs, tokens, private keys, payment data, and ID documents belong in approved secure channels. Never place them in reports, repositories, prompts, or tickets.
Financial, legal, reputational, destructive, ambiguous, and customer-facing actions remain reviewable and owned.
Stable identifiers, idempotency, retry budgets, terminal errors, and dead-letter handling prevent silent duplication and infinite loops.
Structured logs, run history, source freshness, alerts, and documented recovery replace “the automation probably ran.”
Use only authorised data needed for the outcome, separate client environments, define retention, and avoid production data in demos.
INITIAL CONTACT
Describe systems, volume, failure mode, desired outcome, and constraints without sharing live credentials or private datasets.
The first-party form uses a same-origin CSRF token, a hidden bot field, a three-second minimum completion time, a ten-minute browser resend limit, a 16 KiB request cap, fixed field limits, and basic secret-pattern rejection. It accepts no files and sends no visitor IP address or browser identifier in the inquiry email.
There is no form database, client-side script, third-party CAPTCHA, visitor-side analytics call, or automatic reply. Hosting may still retain ordinary access and security logs. A private process reduces the host's existing AWStats file to fixed aggregate counters without retaining detailed visitor, referrer, query, user-agent, or error records locally, as described in the privacy notice.
After scope and authority are confirmed, the owner and client choose the approved access path.
REPORTING A SECURITY ISSUE
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.