Validation
Tests with a scenario and an outcome.
On October 17, 2026, an isolated, non-root Linux fixture exercised the real installer, launcher, agent, Node app and gateway against the live control plane. These fixture results are not a scale benchmark or validation of the October 18 release.
Recorded scenarios
Four operating checks and their observed results.
- Startup and restart. Expected: the installed runtime starts the application and carries out a manual restart. Observed: installer enrollment and Node startup completed; direct and gateway health returned HTTP 200. Restart replaced the process, and subsequent health returned 200.
- Rate limiting. Expected: the configured gateway limit allows the burst and rejects excess requests. Observed: at 10 requests per minute with burst 5, a 12-request sequence produced five HTTP 200 and seven HTTP 429 responses.
- Request policy. Expected: the configured WAF rejects the selected injection probes while allowing the normal control. Observed: two basic injection patterns returned HTTP 403; the normal control returned 200. This result covers those probes.
- Scoped MCP access. Expected: the installed bridge exposes workspace reads without giving read-only credentials write authority. Observed: it listed 32 read tools and returned workspace state and application logs; a write attempt using read-only credentials was denied.
October 17, 2026 record
Actual runtime processes
The fixture exposed no host ports or production application data; stdout, supervisor logs and request/User-Agent capture appeared in the relevant dashboard streams. Its summary names no immutable tested release, so it does not establish current-release validation.
Implementation and validation
A feature and its tested scope are different
Infraveil implements operating controls beyond these four scenarios. The recorded checks establish only the behavior exercised in that fixture. Large-fleet placement and ordering, host crash/reboot recovery, every authentication workflow, and successful MCP writes were not established by that run.
Limits of this record
Keep the untested and failed cases visible.
- These functional checks are not an independent external security audit or a sustained-load benchmark.
- The October 17 fixture reported failed honeypot auto-block persistence, a capacity estimate that did not honor its resource ceiling, and topology/analytics state inconsistencies. Those combinations are not presented as validated here.
- A successful process restart does not establish database restoration, cross-host failover, or survival of every infrastructure failure.
- Validate the release, configuration, workload, and failure cases you intend to operate, using a non-production service and explicit acceptance criteria.
Reproduce the scenario on a test service.
Use the illustrative demo to understand the operating flow, then check the relevant behavior with a non-production application you control.
