Security
A browser runner built around explicit limits.
FormSentinel treats every target page as untrusted. The source plan requires layered controls before any closed-beta journey can run outside controlled acceptance tests.
Destination controls
Closed-beta journeys are limited to operator-approved public HTTP or HTTPS domains. The runner must resolve and validate initial destinations, redirects, and subrequests while rejecting private, local, metadata-service, special-use, embedded-credential, non-web, and disallowed-port targets.
Deterministic steps only
The initial journey contract accepts only:
- assert that an element is visible;
- assert bounded expected text;
- fill a synthetic non-secret value;
- click an approved selector;
- assert an expected URL rule; and
- wait for a bounded duration or selector.
Arbitrary JavaScript, browser evaluation, shell commands, uploaded scripts, custom modules, and target credentials are prohibited.
Runtime isolation
Each run must use a fresh browser context and a non-root, sandboxed, resource-bounded worker. The contract includes limits on time, steps, concurrency, CPU, memory, navigation, and evidence retention. A crashed or stale lease must be recoverable without duplicate alerts.
No irreversible completion
Checkout journeys stop before a live charge. Controlled form journeys stop before an irreversible submission unless a later verified-domain policy and separate security acceptance explicitly allow a synthetic destination. Manual runs never mutate scheduled incident counters or send production alerts.
Bounded evidence
Alerts and logs must avoid cookies, headers, request bodies, full HTML, arbitrary page text, customer identifiers, and secrets. Failure evidence uses stable classifications rather than dumping page content. Workspace isolation and server-only privileges require independent acceptance before customer use.