PRACTICAL CONTROLS

The client should own the keys—and the off switch.

Custom automation touches real systems. The security model starts with narrow access, explicit boundaries, realistic testing, and a production setup the client can understand and control.

This page describes operating principles, not a certification or a guarantee that risk can be eliminated.

ACCOUNT OWNERSHIP

Avoid a hidden dependency.

Production subscriptions, domains, phone numbers, sending identities, databases, payment accounts, and API credentials should be created in the client’s name or transferred to client control at handoff.

Temporary development accounts may be used during a build, but the final architecture and ownership map should identify every production dependency, owner, billing relationship, and access path.

ACCESS

Minimum access for the shortest useful time.

Prefer delegated access or OAuth over sharing a primary password.
Use separate development, test, and production environments where practical.
Limit credentials to the systems, actions, and records required by the scope.
Rotate or revoke temporary access after handoff.
Never paste long-lived production keys into ordinary email or public forms.

AI BOUNDARIES

Automation should know when to stop.

A production workflow should define what AI may read, draft, change, or send; which actions always need approval; which situations require a person; what must never be sent to a model; and how output and errors are logged.

Pricing promises, unusual commitments, emergencies, disputes, regulated decisions, and low-confidence cases should have explicit human-control rules before launch.

TESTING + LAUNCH

Prove the failure paths too.

Acceptance testing should cover the happy path, missing information, duplicate events, ambiguous input, provider outages, customer requests for a person, and the pause or rollback path.

Before real use, the client should approve success criteria, monitoring recipients, spending limits, data-retention rules, escalation routes, and the manual fallback.

PUBLIC WEBSITE

Server-side secrets and abuse controls.

Website credentials are kept in server environment variables rather than shipped to browsers. Public forms and AI demos use origin checks, input limits, throttling, and no-store responses. Inquiry records are available only through an authenticated server endpoint.

Security headers restrict framing, content types, browser capabilities, and unapproved resource origins. The public demos are separated from client production systems and do not perform live customer actions.

REPORTING

Found something? Report it responsibly.

Send a clear description, affected URL, reproduction steps, and impact to apreda31@gmail.com. Please do not access, alter, retain, or publish another person’s data; disrupt service; use automated high-volume testing; or demand payment as a condition of disclosure.

Good-faith reports will be reviewed and acknowledged as soon as practical. Testing beyond ordinary use requires written permission in advance.