Aegis — Rules of Engagement
This is the operational agreement accepted per assessment, and the record of your
authorisation to test. Bracketed items [LIKE THIS] need your decision.
Version: [1.0] · Accepted per assessment, before any scan is queued.
1. Authorisation
By accepting these Rules for a given assessment you confirm:
- you own the target, or hold express written authorisation to test it;
- you are authorised to bind your organisation to this agreement;
- you have complied with the policies of your hosting, cloud and CDN providers;
- the information you supplied (target, environment, tier) is accurate.
Your acceptance is recorded with a timestamp and your account identity, together with the DNS verification result. Together these constitute your authorisation for the testing described below. Retain a copy — it is the record that the testing was authorised.
2. Scope
In scope: only the verified target host(s) named in the assessment, and only the application reachable at them.
Never in scope, under any tier: - provider infrastructure — Cloudflare, DigitalOcean, AWS, Azure, Google Cloud, and equivalents; - any host you have not verified; - third-party services, embedded widgets, payment processors or APIs you do not control; - physical security, social engineering, or your staff.
3. What each tier does
| Baseline | Authenticated | Aggressive assurance | |
|---|---|---|---|
| Authentication | None | Signs in with your test credentials | Signs in; multiple roles |
| Requests | Low rate, capped | Capped | Capped |
| Data modification | None | None | Yes, by design |
| Permitted environment | Production or staging | Production or staging | Non-production only |
| Extra approval | No | No | Yes — written, per assessment |
Testing methods used: HTTP requests to the verified target; inspection of responses, headers, cookies and content; authenticated navigation; and — for aggressive tiers only — submission of requests that create or modify test records.
Never performed: denial-of-service, load, stress or flooding; brute-force credential attacks; destructive operations (deletion of your data); exploitation beyond what is needed to evidence a finding; exfiltration of production personal data.
4. Your obligations before testing
- Backups. Confirm a current backup exists and that you have tested restoring it.
- Rollback plan. For aggressive tiers, know how you will reverse unexpected changes.
- Provider notification. Comply with your providers' policies; where a WAF or rate limiter sits in front, allow-list the testing so results are not distorted.
- Excluded paths. Tell us any endpoints that must not be touched (billing, webhooks, password reset, bulk email, anything that triggers real-world effects).
- Test credentials. For authenticated tiers, supply a dedicated low-privilege account. Never a real customer or administrator account. Rotate afterwards.
- Contact. Nominate someone reachable during the testing window.
5. Emergency stop
An emergency stop is available at all times in your dashboard, halting further requests immediately. You are expected to use it if you observe adverse effects. Requests already in flight may complete. Stopping does not reverse changes already made by an aggressive test — that is what your rollback plan is for.
6. Rate limits and safety controls
Testing runs within enforced budgets: a maximum number of requests per scan, limited concurrency, a capped request rate, and — for state-changing tests — a cap on modifications and a cleanup contract. These are enforced in code and cannot be raised by request beyond the limits of your tier.
7. Findings, evidence and handling
Findings and evidence are stored encrypted and scoped to your workspace. Evidence is redacted server-side to reduce capture of sensitive values. If testing incidentally surfaces credentials, personal data or other sensitive material, it is stored under the same protections and you may delete it at any time.
If a critical finding is identified, it is your responsibility to act on it. We do not notify third parties, regulators or affected individuals on your behalf.
8. Reporting and retention
Reports are generated automatically on completion and available in your dashboard.
Retention is [12 MONTHS] by default [CONFIRM]; you may export or delete earlier.
9. Limits of automated testing
This is automated testing. It will not find every vulnerability, and it does not replicate a skilled human attacker. A report with no findings does not mean your systems are secure — it means the checks performed did not detect an issue. Do not represent an Aegis report as a certification.
10. Acknowledgement
The confirmations you tick before a scan is queued correspond to these Rules:
- snapshot/rollback ready · provider policies acknowledged · target ownership verified · third-party infrastructure out of scope · correct tier selected · no disruptive testing · destructive/sensitive paths excluded · rate limits at defaults · emergency contact available.
All must be satisfied before testing is approved. Approval is automated; there is no human operator reviewing your assessment before it runs.